Daniel-Constantin, Good morning. Thanks for the early morning opinion. How about some really late night followup? :) Daniel-Constantin Mierla wrote: That was the idea. I already have extensive call logic outboarded to a Perl script, so I would just replace lookup() with my own intelligent, contact header-aware database dip. I ultimately elected to go with the second option, not the first. [ BTW, slightly unrelated: Whatever the cause of script methods being largely inaccessible from the Perl module API (i.e. OpenSER::rewrite_uri()) is (I was told a memory leak) it is a source of vexation and disappointment. It means that I really can't do anything with my Perl scripts--of which there is a plethora--other than get and set AVPs and read custom pseudovariables and parse messages and URIs. I can't really move any of the logic I have from script to Perl at all, so instead I have to use countless AVPs as a message-passing mechanism and end up with big, nasty, ugly chunks of script that look like: if($avp(S:translation_status) == "1") { # do a bunch of things avp_delete("$avp(S:translation_status)"); } My number one wish for the project is that someone would give some attention to the neglected Perl module and get it all fixed up so I can get a lot of logic out of the route plan. ] The route I decided to go is to check all the conditions in the branch route; it keeps things simple and prevents me from having to iterate over any AVP arrays. The real headache I'm facing now has to do with call statekeeping. I keep call state in a database using custom logic in order to try -- as much as the reliability of SIP signaling can allow -- to enforce simultaneous session limits. The problem is that none of this stuff is branch-aware, but now I'm getting into a situation where a branch that is cancelled triggers a reply (and therefore, for that call leg, an ONREPLY-ROUTE) like 487 Transaction Terminated that has to be handled in a branch-aware way. Previously, in unitary branch mode, I would just delete the call from the state table upon encountering a >= 300 cause code in the reply. Now I have to make sure I only delete that branch, and handle a bunch of other contingencies that come with that. Oof. -- 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

Klaus, Klaus Darilion wrote: 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

Klaus Darilion wrote: It's not how the provider's provisioning is set up to handle it; they do not use DIDs as usernames. And in any case, many of the UAs are not going to be Asterisk. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599

Alex Balashov schrieb: I wonder how you manage to do this without Asterisk. AFAIK Asterisk is the only SIP client which allows you to specify the userpart of the contact. I think this is the design problem. If you do not want branching then you should not have multiple contacts for the same AoR. IIRC there was an extension to SIP registration in the SIPConnect specification of the SIP forum how to register multiple DIDs. Maybe this can give you some more ideas how to solve the problem. http://www.sipforum.org/component/option,com_docman/task,cat_view/gid,43/It… regards klaus