[SR-Users] Contacts replacing each other when registering

Daniel-Constantin Mierla miconda at gmail.com
Thu Oct 6 12:49:02 CEST 2016


Hello,

what is the matching mode for usrloc module:

https://www.kamailio.org/docs/modules/stable/modules/usrloc.html#usrloc.p.matching_mode

Cheers,
Daniel


On 27/09/16 15:42, Sebastian Damm wrote:
> Hi,
>
> we are running a Registrar server with 4.4.3, the registrar module is
> configured with the following parameters:
>
> modparam("registrar", "max_contacts", 50)
> modparam("registrar", "use_path", 1)
> modparam("registrar", "path_mode", 0)
> modparam("registrar", "path_use_received", 1)
> modparam("registrar", "received_avp", "$(avp(i:801))")
> modparam("registrar", "default_expires", 600)
> modparam("registrar", "min_expires", 60)
> modparam("registrar", "max_expires", 600)
> modparam("registrar", "gruu_enabled", 0)
>
> A customer has configured 4 phones with the same username. Normally,
> all 4 phones would be visible in the location database, and incoming
> calls would fork out to all 4 phones. However, only one of the devices
> is always online, the others always replace each other on each
> registration.
>
> Client details:
> * All phones are snom 715 devices with the same firmware version.
> * All phones sit behind the same router.
>
> Registrations:
> client 1:
> * Via: SIP/2.0/UDP 192.168.208.91:35812;branch=z9hG4bK-4q0mmxgu6gm7;rport
> * Contact: <sip:1794388e3 at 192.168.208.91:35812;line=gicode6v>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:0a14174a-77be-424c-864e-0004137F1C9D>"
>
> client 2:
> * Via: SIP/2.0/UDP 192.168.208.90:41331;branch=z9hG4bK-3cbxdvbmk0di;rport
> * Contact: <sip:1794388e3 at 192.168.208.90:41331;line=0j6veso8>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:0a14174a-77be-424c-864e-0004137F1C9D>"
>
> client 3:
> * Via: SIP/2.0/UDP 192.168.208.92:5360;branch=z9hG4bK-4drsogakez94;rport
> * Contact: <sip:1794388e3 at 192.168.208.92:5360;line=0n7jfzih>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:0a14174a-77be-424c-864e-0004137F1C9D>"
>
> client 4:
> * Via: SIP/2.0/UDP 192.168.208.93:5260;branch=z9hG4bK-1ci0qia3yxyl;rport
> * Contact: <sip:1794388e3 at 192.168.208.93:5260;line=mh9sgxa1>;reg-id=1;q=1.0
>
> Only client 4 is reachable all the time. The other 3 clients replace
> other registrations.
>
> So after client 1 registers, the contacts returned in the 200 OK looks
> like this:
>
> Contact: <sip:1794388e3 at 192.168.208.91:35812;line=gicode6v>;q=1;expires=600;received="sip:1.2.3.4:6411";+sip.instance="<urn:uuid:0a14174a-77be-424c-864e-0004137F1C9D>";reg-id=1,
> <sip:1794388e3 at 192.168.208.93:5260;line=mh9sgxa1>;q=1;expires=303;received="sip:1.2.3.4:8923"
>
> And after client 2 registers, the contacts returned in the 200 OK
> looks like this:
>
> Contact: <sip:1794388e3 at 192.168.208.90:41331;line=0j6veso8>;q=1;expires=600;received="sip:1.2.3.4:49061";+sip.instance="<urn:uuid:0a14174a-77be-424c-864e-0004137F1C9D>";reg-id=1,
> <sip:1794388e3 at 192.168.208.93:5260;line=mh9sgxa1>;q=1;expires=301;received="sip:1.2.3.4:8923"
>
> So you see, one contact stays the same, the other one gets replaced.
>
>
> Does anybody know what could cause this kind of behavior? I think, it
> could be GRUU. I see that those three clients all send the same GRUU
> parameter. From my understanding, this UUID should be different from
> client to client. I don't know whether this is a bug in the snom
> firmware always sending the same GRUU UUID or whether som
> "intelligent" SIP aware router is putting this in the Contact header.
> However, since we have disabled gruu for the registrar module (see
> above), I think, Kamailio should ignore it.
>
> Ideas? Thanks in advance.
>
> Best Regards,
> Sebastian
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com




More information about the sr-users mailing list