Hi,
Found an interesting call-flow today where a client (pjsip) is behind NAT and behaves like this during registration (kamailio-3.1.3):
REGISTER sip:somedomain.com Contact: sip:me@10.0.0.7:2001;ob Expires: 900
SIP/2.0 200 OK Contact: sip:me@10.0.0.7:2001;ob;expires=900;received="sip:1.2.3.4:3001"
REGISTER sip:somedomain.com Contact: sip:me@1.2.3.4:3001;transport=UDP;ob Contact: sip:me@10.0.0.7:2001;ob;expires=0 Expires: 900
SIP/2.0 200 OK Contact: sip:me@10.0.0.7:2001;ob;expires=900;received="sip:1.2.3.4:3001", sip:me@1.2.3.4:3001;transport=UDP;ob;expires=900
So obviously the client is trying to unregister its private contact (for whatever reason - probably to play nice with registrars not supporting far-end NAT traversal), and tries to register the Contact with the "received" address instead. Kamailio however ignores the ";expires=0" for the private Contact and just saves both of them with the expiry value given in the Expires header.
Taking the client behavior aside for now: is this the correct behavior of the registrar module? In RFC3261 chapter 10.2.1.1 it says:
#+ There are two ways in which a client can suggest an expiration interval for a binding: through an Expires header field or an "expires" Contact header parameter. The latter allows expiration intervals to be suggested on a per-binding basis when more than one binding is given in a single REGISTER request, whereas the former suggests an expiration interval for all Contact header field values that do not contain the "expires" parameter. #-
So I'd say that in my specific case "expires" Contact header param (which is 0 for the binding having 10.0.0.7) should de-register this particular binding, whereas the Expires header should be applied to the second binding (having the 1.2.3.4) because it doesn't carry an "expires" param.
Opinions on that one?
Andreas
Hello,
I looked in the code and the expires is taken from contact header parameter if present. Maybe you can run in higher debug level and see if you can spot something in the log messages that can give a lead.
Cheers, Daniel
On 6/2/11 9:23 PM, Andreas Granig wrote:
Hi,
Found an interesting call-flow today where a client (pjsip) is behind NAT and behaves like this during registration (kamailio-3.1.3):
REGISTER sip:somedomain.com Contact:sip:me@10.0.0.7:2001;ob Expires: 900
SIP/2.0 200 OK Contact:sip:me@10.0.0.7:2001;ob;expires=900;received="sip:1.2.3.4:3001"
REGISTER sip:somedomain.com Contact:sip:me@1.2.3.4:3001;transport=UDP;ob Contact:sip:me@10.0.0.7:2001;ob;expires=0 Expires: 900
SIP/2.0 200 OK Contact: sip:me@10.0.0.7:2001;ob;expires=900;received="sip:1.2.3.4:3001", sip:me@1.2.3.4:3001;transport=UDP;ob;expires=900
So obviously the client is trying to unregister its private contact (for whatever reason - probably to play nice with registrars not supporting far-end NAT traversal), and tries to register the Contact with the "received" address instead. Kamailio however ignores the ";expires=0" for the private Contact and just saves both of them with the expiry value given in the Expires header.
Taking the client behavior aside for now: is this the correct behavior of the registrar module? In RFC3261 chapter 10.2.1.1 it says:
#+ There are two ways in which a client can suggest an expiration interval for a binding: through an Expires header field or an "expires" Contact header parameter. The latter allows expiration intervals to be suggested on a per-binding basis when more than one binding is given in a single REGISTER request, whereas the former suggests an expiration interval for all Contact header field values that do not contain the "expires" parameter. #-
So I'd say that in my specific case "expires" Contact header param (which is 0 for the binding having 10.0.0.7) should de-register this particular binding, whereas the Expires header should be applied to the second binding (having the 1.2.3.4) because it doesn't carry an "expires" param.
Opinions on that one?
Andreas
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi Daniel,
On 06/02/2011 10:24 PM, Daniel-Constantin Mierla wrote:
Hello,
I looked in the code and the expires is taken from contact header parameter if present. Maybe you can run in higher debug level and see if you can spot something in the log messages that can give a lead.
Well, the only thing which looks interesting is this:
DEBUG: registrar [save.c:496]: 1 valid contacts DEBUG: registrar [save.c:518]: 1 contacts after commit
And later:
DEBUG: registrar [reply.c:192]: created Contact HF: Contact: sip:me@10.0.0.7:2001;ob;expires=900;received="sip:1.2.3.4:3001", sip:me@1.2.3.4:3001;transport=UDP;ob;expires=900
So probably it just recognizes the second Contact (the one with the public IP and without the expires param)?
Andreas
Hello,
one more thing, what is the output of kamctl ul show? I want to see if it is a matter of building the contact header for reply or is in internal list of location records.
Cheers, Daniel
On 6/2/11 10:49 PM, Andreas Granig wrote:
Hi Daniel,
On 06/02/2011 10:24 PM, Daniel-Constantin Mierla wrote:
Hello,
I looked in the code and the expires is taken from contact header parameter if present. Maybe you can run in higher debug level and see if you can spot something in the log messages that can give a lead.
Well, the only thing which looks interesting is this:
DEBUG: registrar [save.c:496]: 1 valid contacts DEBUG: registrar [save.c:518]: 1 contacts after commit
And later:
DEBUG: registrar [reply.c:192]: created Contact HF: Contact: sip:me@10.0.0.7:2001;ob;expires=900;received="sip:1.2.3.4:3001", sip:me@1.2.3.4:3001;transport=UDP;ob;expires=900
So probably it just recognizes the second Contact (the one with the public IP and without the expires param)?
Andreas
Hi,
On 06/03/2011 12:10 AM, Daniel-Constantin Mierla wrote:
one more thing, what is the output of kamctl ul show? I want to see if it is a matter of building the contact header for reply or is in internal list of location records.
Domain:: location table=512 records=1 max_slot=1 AOR:: me@somedomain.com Contact:: sip:me@10.0.0.7:52030;ob Q= Expires:: 875 Callid:: DZZHTDttFd5WivydjNnWfpRLsXp8RIYh Cseq:: 4599 User-agent:: myclient Received:: sip:1.2.3.4:55642 Path:: sip:lb@127.0.0.1:5060;lr;received=sip:1.2.3.4:55642 State:: CS_SYNC Flags:: 0 Cflag:: 192 Socket:: udp:127.0.0.1:5062 Methods:: 8143 Contact:: sip:me@1.2.3.4:55642;transport=UDP;ob Q= Expires:: 876 Callid:: DZZHTDttFd5WivydjNnWfpRLsXp8RIYh Cseq:: 4601 User-agent:: myclient Path:: sip:lb@127.0.0.1:5060;lr State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: udp:127.0.0.1:5062 Methods:: 8143
Hope this helps, Andreas
Hello,
I tested with kamailio default config and injected some REGISTERs to reproduce the scenario, see the SIP trace below. The results were ok in 200 reply, also in kamctl.
Can you send me also a SIP trace for the situation? Also, the parameters for registrar and usrloc modules. Do you you have a particular matching_mode set?
Thanks, Daniel
U 2011/06/03 09:39:05.409702 127.0.0.1:56741 -> 127.0.0.1:5060 REGISTER sip:127.0.0.1:5060 SIP/2.0 From: "Test" sip:test@127.0.0.1;tag=as23 To: "Test" sip:test@127.0.0.1 Call-ID: aa@127.0.0.1 User-Agent: snom100_1.9b CSeq: 2 REGISTER Via: SIP/2.0/UDP 127.0.0.1:5080 Contact: sip:me@127.0.0.1:2001;ob Expires: 900 Content-Length: 0
U 2011/06/03 09:39:05.413813 127.0.0.1:5060 -> 127.0.0.1:5080 SIP/2.0 200 OK. From: "Test" sip:test@127.0.0.1;tag=as23 To: "Test" sip:test@127.0.0.1;tag=b27e1a1d33761e85846fc98f5f3a7e58.521d Call-ID: aa@127.0.0.1 CSeq: 2 REGISTER Via: SIP/2.0/UDP 127.0.0.1:5080. Contact: sip:me@127.0.0.1:2001;ob;expires=900. Server: kamailio (3.2.0-dev5 (x86_64/darwin)). Content-Length: 0. .
U 2011/06/03 09:39:43.616036 127.0.0.1:56948 -> 127.0.0.1:5060 REGISTER sip:127.0.0.1:5060 SIP/2.0 From: "Test" sip:test@127.0.0.1;tag=as23 To: "Test" sip:test@127.0.0.1 Call-ID: aa@127.0.0.1 User-Agent: snom100_1.9b CSeq: 3 REGISTER Via: SIP/2.0/UDP 127.0.0.1:5080 Contact: sip:me@127.0.0.1:3001;transport=UDP;ob Contact: sip:me@127.0.0.1:2001;ob;expires=0 Expires: 900 Content-Length: 0
U 2011/06/03 09:39:43.618327 127.0.0.1:5060 -> 127.0.0.1:5080 SIP/2.0 200 OK. From: "Test" sip:test@127.0.0.1;tag=as23 To: "Test" sip:test@127.0.0.1;tag=b27e1a1d33761e85846fc98f5f3a7e58.521d Call-ID: aa@127.0.0.1 CSeq: 3 REGISTER Via: SIP/2.0/UDP 127.0.0.1:5080. Contact: sip:me@127.0.0.1:3001;transport=UDP;ob;expires=900. Server: kamailio (3.2.0-dev5 (x86_64/darwin)). Content-Length: 0. .
# kamctl ul show Domain:: location table=512 records=1 max_slot=1 AOR:: test Contact:: sip:me@127.0.0.1:3001;transport=UDP;ob Q= Expires:: 889 Callid:: aa@127.0.0.1 Cseq:: 3 User-agent:: snom100_1.9b State:: CS_NEW Flags:: 0 Cflag:: 0 Socket:: udp:127.0.0.1:5060 Methods:: 4294967295
# kamctl ul show Domain:: location table=512 records=1 max_slot=1 AOR:: test Contact:: sip:me@127.0.0.1:3001;transport=UDP;ob Q= Expires:: 690 Callid:: aa@127.0.0.1 Cseq:: 3 User-agent:: snom100_1.9b State:: CS_NEW Flags:: 0 Cflag:: 0 Socket:: udp:127.0.0.1:5060 Methods:: 4294967295
On 6/3/11 12:16 AM, Andreas Granig wrote:
Hi,
On 06/03/2011 12:10 AM, Daniel-Constantin Mierla wrote:
one more thing, what is the output of kamctl ul show? I want to see if it is a matter of building the contact header for reply or is in internal list of location records.
Domain:: location table=512 records=1 max_slot=1 AOR:: me@somedomain.com Contact:: sip:me@10.0.0.7:52030;ob Q= Expires:: 875 Callid:: DZZHTDttFd5WivydjNnWfpRLsXp8RIYh Cseq:: 4599 User-agent:: myclient Received:: sip:1.2.3.4:55642 Path::sip:lb@127.0.0.1:5060;lr;received=sip:1.2.3.4:55642 State:: CS_SYNC Flags:: 0 Cflag:: 192 Socket:: udp:127.0.0.1:5062 Methods:: 8143 Contact:: sip:me@1.2.3.4:55642;transport=UDP;ob Q= Expires:: 876 Callid:: DZZHTDttFd5WivydjNnWfpRLsXp8RIYh Cseq:: 4601 User-agent:: myclient Path::sip:lb@127.0.0.1:5060;lr State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: udp:127.0.0.1:5062 Methods:: 8143
Hope this helps, Andreas
Hi all,
Just wanted to confirm that commit 16183d4553aca270da1284255f3f6862132a3aeb in branch 3.1 fixes the problem described below.
Thanks Daniel for you prompt help!
Andreas
On 06/03/2011 12:16 AM, Andreas Granig wrote:
Hi,
On 06/03/2011 12:10 AM, Daniel-Constantin Mierla wrote:
one more thing, what is the output of kamctl ul show? I want to see if it is a matter of building the contact header for reply or is in internal list of location records.
Domain:: location table=512 records=1 max_slot=1 AOR:: me@somedomain.com Contact:: sip:me@10.0.0.7:52030;ob Q= Expires:: 875 Callid:: DZZHTDttFd5WivydjNnWfpRLsXp8RIYh Cseq:: 4599 User-agent:: myclient Received:: sip:1.2.3.4:55642 Path:: sip:lb@127.0.0.1:5060;lr;received=sip:1.2.3.4:55642 State:: CS_SYNC Flags:: 0 Cflag:: 192 Socket:: udp:127.0.0.1:5062 Methods:: 8143 Contact:: sip:me@1.2.3.4:55642;transport=UDP;ob Q= Expires:: 876 Callid:: DZZHTDttFd5WivydjNnWfpRLsXp8RIYh Cseq:: 4601 User-agent:: myclient Path:: sip:lb@127.0.0.1:5060;lr State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: udp:127.0.0.1:5062 Methods:: 8143
Hope this helps, Andreas
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Andreas Granig -
Daniel-Constantin Mierla