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
9 Sep
9 Sep
8:31 a.m.
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(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
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
9:24 a.m.
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
4760
days inactive
4760
days old
2 comments
3 participants
participants (3)
-
Francesco Castellano -
Henning Westerholt -
Klaus Darilion