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

[Francesco Castellano]

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