[sr-dev] registrar save() with multiple Contact headers

Francesco Castellano francesco.castellano at gmail.com
Fri Sep 9 13:27:55 CEST 2011


Dear Sirs,

I was wondering if an unexpected behaviour I'm experiencing on our SIP
proxy is caused by a faulty client (i.e., faulty expectation of mine),
or, this is the reason I'm writing you, by a possible bug.

I'm running SIP router version 3.1.3, Kamailio flavour (so the actual
module loaded is from modules_k/). The client, after a successful
REGISTER parses the contacts in the 200 OK reply, and then, if found,
de-register previous registrations by itself no more relevant
(essentially we're speaking of a mobile application, so changes of
connectivity can lead to these broken locations).

The second REGISTER, with re-register of the current good location,
and de-register of previous, broken locations looked like:

REGISTER sip:sip.domain.com SIP/2.0.
Via: SIP/2.0/TCP 192.168.130.21:5060;rport;branch=z9hG4bK-864-1-17.
Route: <sip:213.98.57.102:5060;transport=TCP;lr>.
Max-Forwards: 70.
From: "cippa" <sip:1234 at sip.domain.com>;tag=l0p3Kw9T0iksJso7bfbajNx8zFbTLMdv-1.
To: "cippa" <sip:1234 at sip.domain.com>.
Call-ID: 5300432-enOD-gYijrKAsugiWFZ8iYVublP98xvS///1-864 at 192.168.130.21.
CSeq: 6 REGISTER.
Contact: <sip:1234 at 192.168.130.21:5060;transport=TCP;uniq=MultiReg>.
Contact: <sip:1234 at 192.168.130.21:5060;transport=TCP;uniq=MultiRog>;expires=0.
Expires: 600.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS.
Authorization: [...]
Content-Length:  0.

And the proxy reacted to this request updating the first location
(sip:1234 at 192.168.130.21:5060;transport=TCP;uniq=MultiReg) expire
time, but ignoring the second one
(sip:1234 at 192.168.130.21:5060;transport=TCP;uniq=MultiRog)..

No better results, if the expire value was always specified as an
header parameter as opposed to an header ad hoc:

REGISTER sip:sip.domain.com SIP/2.0.
Via: SIP/2.0/TCP 192.168.130.21:5060;rport;branch=z9hG4bK-864-1-17.
Route: <sip:213.98.57.102:5060;transport=TCP;lr>.
Max-Forwards: 70.
From: "cippa" <sip:1234 at sip.domain.com>;tag=l0p3Kw9T0iksJso7bfbajNx8zFbTLMdv-1.
To: "cippa" <sip:1234 at sip.domain.com>.
Call-ID: 5300432-enOD-gYijrKAsugiWFZ8iYVublP98xvS///1-864 at 192.168.130.21.
CSeq: 6 REGISTER.
Contact: <sip:1234 at 192.168.130.21:5060;transport=TCP;uniq=MultiReg>;expires=600.
Contact: <sip:1234 at 192.168.130.21:5060;transport=TCP;uniq=MultiRog>;expires=0.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS.
Authorization: [...]
Content-Length:  0.

Compacting instead the Contact headers worked fine:

REGISTER sip:sip.domain.com SIP/2.0.
Via: SIP/2.0/TCP 192.168.130.21:5060;rport;branch=z9hG4bK-864-1-17.
Route: <sip:213.98.57.102:5060;transport=TCP;lr>.
Max-Forwards: 70.
From: "cippa" <sip:1234 at sip.domain.com>;tag=l0p3Kw9T0iksJso7bfbajNx8zFbTLMdv-1.
To: "cippa" <sip:1234 at sip.domain.com>.
Call-ID: 5300432-enOD-gYijrKAsugiWFZ8iYVublP98xvS///1-864 at 192.168.130.21.
CSeq: 6 REGISTER.
Contact: <sip:1234 at 192.168.130.21:5060;transport=TCP;uniq=MultiReg>;expires=600,
<sip:1234 at 192.168.130.21:5060;transport=TCP;uniq=MultiRog>;expires=0.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS.
Authorization: [...]
Content-Length:  0.

even with a global Expires headers:

REGISTER sip:sip.domain.com SIP/2.0.
Via: SIP/2.0/TCP 192.168.130.21:5060;rport;branch=z9hG4bK-864-1-17.
Route: <sip:213.98.57.102:5060;transport=TCP;lr>.
Max-Forwards: 70.
From: "cippa" <sip:1234 at sip.domain.com>;tag=l0p3Kw9T0iksJso7bfbajNx8zFbTLMdv-1.
To: "cippa" <sip:1234 at sip.domain.com>.
Call-ID: 5300432-enOD-gYijrKAsugiWFZ8iYVublP98xvS///1-864 at 192.168.130.21.
CSeq: 6 REGISTER.
Contact: <sip:1234 at 192.168.130.21:5060;transport=TCP;uniq=MultiReg>,
<sip:1234 at 192.168.130.21:5060;transport=TCP;uniq=MultiRog>;expires=0.
Expires: 600
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS.
Authorization: [...]
Content-Length:  0.

Who is doing wrong? The client with multiple Contact headers, or the
server not treating as semantically equals the requests?

Thank you for your attention,
Best regards,
Francesco Castellano



More information about the sr-dev mailing list