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
Seems like a bug in Kamailio.
Contact: .... Contact: ....
must be handled identically as
Contact: ...., .....
regards Klaus
Am 09.09.2011 13:27, schrieb 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@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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On Friday 09 September 2011, Francesco Castellano wrote:
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:
Hi Francesco,
recently there were a bug fix done in the 3.1 stable branch:
Commit: 16183d4553aca270da1284255f3f6862132a3aeb registrar(k): reset local interator to contacts headers
- when the REGISTER request had more than one Contact header and max_contacts parameter was set, there were two iterations through the list fo Contacts header without reseting the iterator, resulting in not processing all Contact headers in save() - reported by Andreas Granig [..]
At least with regards to the multiple contact headers it sounds similar to your issue. It would be great if you could test if this is the case.
You can try to apply this patch locally, wait until next week for 3.1.4 or check out the 3.1 master branch from the repository.
Best regards,
Henning
-
Francesco Castellano -
Henning Westerholt -
Klaus Darilion