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