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.
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web
http://www.imp.ch
______________________________________________________