Klaus,
Klaus Darilion wrote:
Of course, lookup() doesn't care what those contacts actually are. If
it sees multiple contacts for one username, t_relay() will simply
create branches for all of them and and ring them all. I can't
actually have that happen.
Sorry - but I do not see the problem. If somebody registers multiple
contacts for the same AoR this means it really wants to receive multiple
INVITEs. If this is not wanted, then it should not register multiple times.
I agree. The problem here is related to the provisioning systems of
which the OpenSER-based registrar is a part.
Basically, every registering user has a username - this is just a
username used for authentication, not related to contact. When a call
comes in for a DID, I do a database dip and associate the DID with a
user, and rewrite the RURI to have the username as the user part, since
that is what the lookup() is keyed on in the location table.
Then, lookup() is called and it (under the hood) rewrites the RURI to
contain the Contact URI provided by the end-user UA.
The problem here is that the Contact header can be many things. In the
case of Asterisk, the default contact user part is 's', which is just a
generic catch-all extension for the inbound context associated with that
SIP peer. But what if I want -- in Asterisk, say -- to be able to apply
different logic in my dial plan depending on what 'extension' the call
came in on (AKA the user part of request URI of the INVITE)? I have to
send the DID as the user part, but I can't do that if the contact it
provided isn't the DID.
Asterisk lets you register like this:
register => user:password@registrar.ip.address:port/contact
So, I can override 's' with a DID for 'contact.' But if I do that, then
I need to arrest call branches going to that user whose contact is not
DID@their_IP.
I do that by comparing $tU and $rU in the BRANCH-ROUTE. But this leads
to a whole lot of other headaches; one, I mentioned in my reply to
Daniel-Constantin, is revising my call statekeeping logic to handle
various things that can happen on one branch and not another (if the
Contacts match up). The other is, what if the user doesn't actually
want to register multiple times with multiple contacts?
The really best way to handle this is to stick with one contact and
count on the UAC to use the To: header to determine how to handle the
call, just like a traditional DNIS/CPN facility. But all of Asterisk's
DNIS/DNID/RDNIS stuff seems to be broken right now, so there's no way to
do this. And as for other UACs users might be using, forget it.
So, I need to come up with some logic where users that want all calls on
all DIDs they have (which can potentially be a large number) can get
them by specifying one magic "catch-all" contact user part, or register
with DIDs as contacts specifically so the branch manipulation can do its
work. It isn't easy for non-Asterisk clients; while I assume that most
ATAs, IADs and VoIP PBXs that have a concept of a trunk "line" will
provide the DID as the contact, others, like some soft phones, can put
in the contact whatever they want, and it may have no imaginable
correlation to the authentication username or the line name or whatever.
That's where the mess comes in.
-- Alex
--
Alex Balashov
Evariste Systems
Web :
http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599