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:[email protected]>;tag=l0p3Kw9T0iksJso7bfbajNx8zFbTLMdv-1. To: "cippa" <sip:[email protected]>. Call-ID: 5300432-enOD-gYijrKAsugiWFZ8iYVublP98xvS///[email protected]. CSeq: 6 REGISTER. Contact: <sip:[email protected]:5060;transport=TCP;uniq=MultiReg>. Contact: <sip:[email protected]: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:[email protected]:5060;transport=TCP;uniq=MultiReg) expire time, but ignoring the second one (sip:[email protected]: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:[email protected]>;tag=l0p3Kw9T0iksJso7bfbajNx8zFbTLMdv-1. To: "cippa" <sip:[email protected]>. Call-ID: 5300432-enOD-gYijrKAsugiWFZ8iYVublP98xvS///[email protected]. CSeq: 6 REGISTER. Contact: <sip:[email protected]:5060;transport=TCP;uniq=MultiReg>;expires=600. Contact: <sip:[email protected]: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:[email protected]>;tag=l0p3Kw9T0iksJso7bfbajNx8zFbTLMdv-1. To: "cippa" <sip:[email protected]>. Call-ID: 5300432-enOD-gYijrKAsugiWFZ8iYVublP98xvS///[email protected]. CSeq: 6 REGISTER. Contact: <sip:[email protected]:5060;transport=TCP;uniq=MultiReg>;expires=600, <sip:[email protected]: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:[email protected]>;tag=l0p3Kw9T0iksJso7bfbajNx8zFbTLMdv-1. To: "cippa" <sip:[email protected]>. Call-ID: 5300432-enOD-gYijrKAsugiWFZ8iYVublP98xvS///[email protected]. CSeq: 6 REGISTER. Contact: <sip:[email protected]:5060;transport=TCP;uniq=MultiReg>, <sip:[email protected]: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 [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
