9 Sep
2011
9 Sep
'11
7:27 a.m.
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(a)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(a)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(a)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(a)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