Hi,
I am trying to get Kamailio working with a third party SIP provider. This provider pings Kamailio with OPTIONS messages, but Kamailio does not answer correctly: the Call-ID and the tags change where they should not. Here is an example:
Third party SIP server:
OPTIONS sip:false.sip.provider:5060 SIP/2.0 Via: SIP/2.0/UDP 197.17.144.4:5060;branch=z9hG4bK8e45ac1463a From: sip:197.17.144.4;tag=1669836943 To: sip:false.sip.provider Date: Fri, 07 Aug 2015 12:34:37 GMT Call-ID: a012e080-5c41a5ce-8e5-38512c6@197.17.144.4 User-Agent: Cisco-CUCM10.5 CSeq: 101 OPTIONS Contact: sip:197.17.144.4:5060 Max-Forwards: 0 Content-Length: 0
Kamailio's answer:
SIP/2.0 200 OK Via: SIP/2.0/UDP 197.17.144.4:5060;branch=z9hG4bK93e5f072f5f;received=174.37.217.1 From: sip:197.17.144.4;tag=298911055 To: sip:false.sip.provider;tag=b27e1a1d33761e85846fc98f5f3a7e58.8c24 Call-ID: 2defcb00-5c41aa17-93f-38512c6@197.17.144.4 CSeq: 101 OPTIONS Server: kamailio (4.3.1 (x86_64/linux)) Content-Length: 0
You can see that the Call-ID change from "a012e080-5c41a5ce-8e5-38512c6" to "2defcb00-5c41aa17-93f-38512c6". Likewise, the From tag change ("1669836943" to "298911055"). What could be the reason for this ? Moreover I think Kamailio should add the field Allow (with INVITE,ACK,BYE,CANCEL,INFO,OPTIONS,REFER,SUBSCRIBE,NOTIFY), but it does not.
I should mention that I had to modify /kamailio.cfg/ to have Kamailio answer to OPTIONS messages (I added *the code in bold*):
if (*!is_method("OPTIONS") && *!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; }
if(is_method("OPTIONS") && uri==myself && $rU==$null) { *#* sl_send_reply("200","Keepalive"); *options_reply();* exit; }
Maybe this hack replaces an expected behavior that I failed to see/configure ?
Thanks, Jean-Marie.
Hello,
are you sure you got the sip reply for the request?
Apart of cseq number, all the other tokens are different, including the via branch. Kamailio doesn't generate any callid or from-tag when using sl_send_reply() or options_reply(), it reuses the ones from request.
if you still think it is the case of an issues, try:
- add xlog() before sending the reply printing the call-id, from-tag via header and cseq header - grab the pcap capture of such case
Send the syslog messages and the pcap file here on mailing list so we can analyze.
Cheers, Daniel
On 10/08/15 10:41, Jean-Marie Baran wrote:
Hi,
I am trying to get Kamailio working with a third party SIP provider. This provider pings Kamailio with OPTIONS messages, but Kamailio does not answer correctly: the Call-ID and the tags change where they should not. Here is an example:
Third party SIP server:
OPTIONS sip:false.sip.provider:5060 SIP/2.0 Via: SIP/2.0/UDP 197.17.144.4:5060;branch=z9hG4bK8e45ac1463a From: sip:197.17.144.4;tag=1669836943 To: sip:false.sip.provider Date: Fri, 07 Aug 2015 12:34:37 GMT Call-ID: a012e080-5c41a5ce-8e5-38512c6@197.17.144.4 User-Agent: Cisco-CUCM10.5 CSeq: 101 OPTIONS Contact: sip:197.17.144.4:5060 Max-Forwards: 0 Content-Length: 0
Kamailio's answer:
SIP/2.0 200 OK Via: SIP/2.0/UDP 197.17.144.4:5060;branch=z9hG4bK93e5f072f5f;received=174.37.217.1 From: sip:197.17.144.4;tag=298911055 To: sip:false.sip.provider;tag=b27e1a1d33761e85846fc98f5f3a7e58.8c24 Call-ID: 2defcb00-5c41aa17-93f-38512c6@197.17.144.4 CSeq: 101 OPTIONS Server: kamailio (4.3.1 (x86_64/linux)) Content-Length: 0
You can see that the Call-ID change from "a012e080-5c41a5ce-8e5-38512c6" to "2defcb00-5c41aa17-93f-38512c6". Likewise, the From tag change ("1669836943" to "298911055"). What could be the reason for this ? Moreover I think Kamailio should add the field Allow (with INVITE,ACK,BYE,CANCEL,INFO,OPTIONS,REFER,SUBSCRIBE,NOTIFY), but it does not.
I should mention that I had to modify /kamailio.cfg/ to have Kamailio answer to OPTIONS messages (I added *the code in bold*):
if (*!is_method("OPTIONS") && *!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; }
if(is_method("OPTIONS") && uri==myself && $rU==$null) { *#* sl_send_reply("200","Keepalive"); *options_reply();* exit; }
Maybe this hack replaces an expected behavior that I failed to see/configure ?
Thanks, Jean-Marie.
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
My mistake, you're right, I must have picked the wrong frame. I had this request/reply sample and was wondering what was going... Sorry to have bothered you, and thank you for just pointing that out.
By the way, is it normal that I had to change the code to have Kamailio accept OPTIONS messages, or did I miss a config somewhere ?
On 10/08/2015 10:56, Daniel-Constantin Mierla wrote:
Hello,
are you sure you got the sip reply for the request?
Apart of cseq number, all the other tokens are different, including the via branch. Kamailio doesn't generate any callid or from-tag when using sl_send_reply() or options_reply(), it reuses the ones from request.
if you still think it is the case of an issues, try:
- add xlog() before sending the reply printing the call-id, from-tag
via header and cseq header
- grab the pcap capture of such case
Send the syslog messages and the pcap file here on mailing list so we can analyze.
Cheers, Daniel
On 10/08/15 10:41, Jean-Marie Baran wrote:
Hi,
I am trying to get Kamailio working with a third party SIP provider. This provider pings Kamailio with OPTIONS messages, but Kamailio does not answer correctly: the Call-ID and the tags change where they should not. Here is an example:
Third party SIP server:
OPTIONS sip:false.sip.provider:5060 SIP/2.0 Via: SIP/2.0/UDP 197.17.144.4:5060;branch=z9hG4bK8e45ac1463a From: sip:197.17.144.4;tag=1669836943 To: sip:false.sip.provider Date: Fri, 07 Aug 2015 12:34:37 GMT Call-ID: a012e080-5c41a5ce-8e5-38512c6@197.17.144.4 User-Agent: Cisco-CUCM10.5 CSeq: 101 OPTIONS Contact: sip:197.17.144.4:5060 Max-Forwards: 0 Content-Length: 0
Kamailio's answer:
SIP/2.0 200 OK Via: SIP/2.0/UDP 197.17.144.4:5060;branch=z9hG4bK93e5f072f5f;received=174.37.217.1 From: sip:197.17.144.4;tag=298911055 To: sip:false.sip.provider;tag=b27e1a1d33761e85846fc98f5f3a7e58.8c24 Call-ID: 2defcb00-5c41aa17-93f-38512c6@197.17.144.4 CSeq: 101 OPTIONS Server: kamailio (4.3.1 (x86_64/linux)) Content-Length: 0
You can see that the Call-ID change from "a012e080-5c41a5ce-8e5-38512c6" to "2defcb00-5c41aa17-93f-38512c6". Likewise, the From tag change ("1669836943" to "298911055"). What could be the reason for this ? Moreover I think Kamailio should add the field Allow (with INVITE,ACK,BYE,CANCEL,INFO,OPTIONS,REFER,SUBSCRIBE,NOTIFY), but it does not.
I should mention that I had to modify /kamailio.cfg/ to have Kamailio answer to OPTIONS messages (I added *the code in bold*):
if (*!is_method("OPTIONS") && *!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; }
if(is_method("OPTIONS") && uri==myself && $rU==$null) { *#* sl_send_reply("200","Keepalive"); *options_reply();* exit; }
Maybe this hack replaces an expected behavior that I failed to see/configure ?
Thanks, Jean-Marie.
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
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio -http://www.asipto.com
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
On 10 Aug 2015, at 11:19, Jean-Marie Baran jean-marie.baran@ama.bzh wrote:
By the way, is it normal that I had to change the code to have Kamailio accept OPTIONS messages, or did I miss a config somewhere ?
It’s the normal way. You are in full control of handling of SIP messages - requests and responses. Nothing should happen magically in the background.
/O