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.

Hello Benoit,

ok, thanks for the additional information.

I would probably solve it the classical way, by adding one layer of indirection.

Have a mapping table for the real number +49XXX for lookup the two user77 and user88 records which you then lookup from the normal location table. Maybe by just looping the call one time to the proxy, or by some additional logic. But of course, the way discussed on the mailing list with the branch_set_uri(..) is also possible.

Cheers,

Henning

-----Original Message----- From: Benoît Panizzon benoit.panizzon@imp.ch Sent: Freitag, 20. September 2024 15:02 To: Henning Westerholt hw@gilawa.com Cc: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] Pseudo Variable containing 'path' of main branch? / How to compose $du manually with path?

Hi Henning + All

...

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?

I have just checked in the documentation. No, there does not seem to be a way to specify multiple URI with lookup() or how do you do this?

Maybe we don't tank about the same situation.

It's not about multiple contacts registered to one 'username' but multiple 'username'.

Example:

location database:

user77: contact: sip:user77@1.2.3.4:5060 contact: sip:user77@5.6.7.8:5060

user88: contact: sip:user88@4.3.2.1:5060

From my call logic, I assign +41661234567 to both usernames

So when +41661234567 is called, I would like to parallel branch to all contacts of user77 and user88.

Is this possible with lookup()?

For those who will ask: Why are doing this crazy complicated stuff!?! (I have open ears for suggestions how to do it differently btw)

We have several use cases, besides customers with multiple offices and multiple redundant PBX the main one is residential customers:

Simultaneous Ring on Mobile and CPE.

Landline CPE are automatically provisioned. The credentials are not know to the customer (in this example, user77) the connection is not nomadic and has a fixed geolocation for emergency calls. Contractual, the CPE is on our responsibility as VSP.

The customer can get a different set of credentials to use his landline phone number on any devices of his choice, mostly with a mobile app. By doing so, he takes full responsibility for the usage of those credentials.

So this makes sense to create a separate credentials set for this for marking calls to emergency number as nomadic, apply more strict fraud detection measures in case his credentials are stolen, etc...

-- 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 ______________________________________________________

Hi Daniel

https://www.kamailio.org/docs/modules/stable/modules/pv.html#pv.f.sbranch_se...

This looks like what I was looking for. Thank you!