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:[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 _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
