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@sip.domain.com;tag=l0p3Kw9T0iksJso7bfbajNx8zFbTLMdv-1. To: "cippa" sip:1234@sip.domain.com. Call-ID: 5300432-enOD-gYijrKAsugiWFZ8iYVublP98xvS///1-864@192.168.130.21. CSeq: 6 REGISTER. Contact: sip:1234@192.168.130.21:5060;transport=TCP;uniq=MultiReg. Contact: sip:1234@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@192.168.130.21:5060;transport=TCP;uniq=MultiReg) expire time, but ignoring the second one (sip:1234@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@sip.domain.com;tag=l0p3Kw9T0iksJso7bfbajNx8zFbTLMdv-1. To: "cippa" sip:1234@sip.domain.com. Call-ID: 5300432-enOD-gYijrKAsugiWFZ8iYVublP98xvS///1-864@192.168.130.21. CSeq: 6 REGISTER. Contact: sip:1234@192.168.130.21:5060;transport=TCP;uniq=MultiReg;expires=600. Contact: sip:1234@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@sip.domain.com;tag=l0p3Kw9T0iksJso7bfbajNx8zFbTLMdv-1. To: "cippa" sip:1234@sip.domain.com. Call-ID: 5300432-enOD-gYijrKAsugiWFZ8iYVublP98xvS///1-864@192.168.130.21. CSeq: 6 REGISTER. Contact: sip:1234@192.168.130.21:5060;transport=TCP;uniq=MultiReg;expires=600, sip:1234@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@sip.domain.com;tag=l0p3Kw9T0iksJso7bfbajNx8zFbTLMdv-1. To: "cippa" sip:1234@sip.domain.com. Call-ID: 5300432-enOD-gYijrKAsugiWFZ8iYVublP98xvS///1-864@192.168.130.21. CSeq: 6 REGISTER. Contact: sip:1234@192.168.130.21:5060;transport=TCP;uniq=MultiReg, sip:1234@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