Hi Henning
just to double check, you are aware that lookup() will also work with multiple contacts, e.g. will create additional branches that can be used to fork additional calls to the other contacts? And there is also a lookup_branches() function that will lookup for main branch and additional branches?
No, I wasn't. But I guess I had to do it manually because we have two registrars and DMQ sync.
I did not test it right now, but I would expect that the lookup and lookup branches also set the $du correctly when there is a proper path entry in the location table.
I probably did not understood your requirements, but wouldn’t work this two function for you?
At the moment: No. Later on, when we find any way to get a B2BUA SBC in front of the registrar, this problem will also be solved (hint: I'm still looking for a B2BUA, we have been burning through OpenSIPS, FreeSwitch, LibreSBC, Sippy and found breaking issues with all of them unfortunately).
We now use a commercial SBC, but it is soon end of life, end of support by the vendor and we have several issues with this SBC which the vendor is not willing to address. So working to find a way to replace this commercial SBC. This is LAB environment, not production.
Biggest problem seems to be branching (observed with parallel and serial branching) with 100rel enabled where we get multiple replies with same rseq (but different to_tag) which are dropped as duplicates. Also an issue are looping calls with same CallID (in case of call forwarding to another customer on same registrar) which seem to greatly confuse those B2BUA we tested.
The Problem consists of several parts:
Part 1: Customer behind NAT or using TCP/TLS requiring an invite to the UA to be sent either via existing persistent TCP registration connection, or in case of UDP from the registrar IP address to the source port of the registration to get though NAT.
Basically, the UA needs to be contacted from exactly the registrar it has registered to.
Part 2: For load-balance, reliability and to be able to take one machine offline to perform maintenance, we have two registrars nodes sharing their location information via DMQ.
Picture a customer registering more than one device to one contact or having multiple usernames and assigning the same phone number to them.
As example, we have registrar one holding two contacts and registrar two holding one contact.
Core is sending call via dispatcher to registrar one (could also be registrar two).
If I use lookup() on registrar one, thanks to DMQ synced locations, I will get all 3 contacts!
If I then branch the call to all three contacts, the one that is local on that registrar will make it through nat, the call sent to the other two contacts registered on the other registrar will not get though.
So, what I do is (quick and dirty pseudo code)
while reg_fetch_contacts { if socket local append_branch() $count++ endif } if ($count < number_of_registered_contacts) && ($hdr(X-Reg) != "Done") append_hf("X-Reg: Done") append_branch($du of other registrar) endif
So I end up, by making sure, I only add branches for contacts which have a local socket and by sending the call to the other registrar if there are more contacts, the remaining branches will be created on the other registrar where they have their local socket.
At the moment, we are re-visiting opensips and try to use it (also two instances) as proxy for REGISTER and B2BUA for calls in front of our two existing kamailio registrars.
And yes, I guess, if we get this working, we don't have to care about the local socket any more if this is handled by two opensips instances in front of our two registrars and the path information in the location database takes care the call is routed via the opensips instance where that UA is registered.