Hi,
I think I have found a issue with recourd-route in Kamailio 3.0.3.
My old setup was:
Microsoft OCS <--> (TCP) OpenSER (UDP) <---> (UDP) Mediant 2000 (ISDN).
That worked fine.
Now I have inserted a new server in this setup.
Microsoft OCS <--> (TCP) OpenSER (UDP) <---> (UDP) Kamailio (UDP) <--> (UDP) Mediant 2000 (ISDN).
When OpenSer sends the message to Kamailio the recourd-routes look like this:
Record-Route: sip:x.x.248.20;r2=on;lr;ftag=3d9e7d131b Record-Route: sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=3d9e7d131b
But when the message comes back from Kamailio it is: Record-Route: sip:x.x.248.7;lr=on;ftag=3d9e7d131b;did=584.1a683a45,sip:x.x.248.20;r2=on;lr;ftag=3d9e7d131b,sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=3d9e7d131b
OpenSER forwards the message to the OCS with Record-route unchanged and the OCS gets confused and does not reply.
I am not that strong in the SIP RFC's. Is it part of the SIP standard to compact the record-route into one line?
Is it a bug in Kamailio or is it just a parameter that needs to be changed?
Any help will be much appreciated.
Morten Isaksen writes:
When OpenSer sends the message to Kamailio the recourd-routes look like this:
Record-Route: sip:x.x.248.20;r2=on;lr;ftag=3d9e7d131b Record-Route: sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=3d9e7d131b
But when the message comes back from Kamailio it is: Record-Route: sip:x.x.248.7;lr=on;ftag=3d9e7d131b;did=584.1a683a45,sip:x.x.248.20;r2=on;lr;ftag=3d9e7d131b,sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=3d9e7d131b
OpenSER forwards the message to the OCS with Record-route unchanged and the OCS gets confused and does not reply.
then file a bug to ocs folks, because ocs should understand r-r header that contains more than one entry.
-- juha
Is Record-Route: a,b,c
analog of
Record-Route: a Record-Route: b Record-Route: c
or
Record-Route: c Record-Route: b Record-Route: a
?
On Thursday 14 October 2010, Juha Heinanen wrote:
Morten Isaksen writes:
When OpenSer sends the message to Kamailio the recourd-routes look like this:
Record-Route: sip:x.x.248.20;r2=on;lr;ftag=3d9e7d131b Record-Route: sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=3d9e7d131b
But when the message comes back from Kamailio it is: Record-Route: sip:x.x.248.7;lr=on;ftag=3d9e7d131b;did=584.1a683a45,sip:x.x.248.20;r2 =on;lr;ftag=3d9e7d131b,sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=3d9e7d 131b
OpenSER forwards the message to the OCS with Record-route unchanged and the OCS gets confused and does not reply.
then file a bug to ocs folks, because ocs should understand r-r header that contains more than one entry.
-- juha
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,
I was mistaken. This is not the problem. OCS kan handle r-r with multiple entry.
This one works OK - The OCS sends a PRACK
SIP/2.0 180 Ringing Via: SIP/2.0/TCP x.x.42.177:65371;rport=65371;branch=z9hG4bK991996e6 From: sip:+XXXXXX04963;ext=4963@rpvocsmed01.rpdc.local;user=phone;epid=E1A3C38520;tag=74504cfc7a To: sip:+XXXXX07357@sip.uni-tel.dk;user=phone;tag=1c564710455 Call-ID: 707d32ae-acaf-4c13-8117-f9b39c42f26e CSeq: 1429 INVITE Contact: sip:1102@x.x.248.56:5060 Record-Route: sip:x.x.248.20;r2=on;lr;ftag=74504cfc7a,sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=74504cfc7a Supported: em,timer,replaces,path,early-session,resource-priority Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE Require: 100rel RSeq: 1 Server: Audiocodes-Sip-Gateway-Mediant 2000/v.5.60A.035.002 Content-Type: application/sdp Content-Length: 258
v=0 o=AudiocodesGW 564744967 564744627 IN IP4 x.x.248.56 s=Phone-Call c=IN IP4 x.x.248.18 t=0 0 m=audio 62722 RTP/AVP 8 101 c=IN IP4 178.21.248.18 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv
But the OCS does not answer this. Could it be lr=on that triggers the problem? I do not have access to the OCS myself.
SIP/2.0 180 Ringing Via: SIP/2.0/TCP x.x.42.177:65251;rport=65251;branch=z9hG4bK9a5a33df From: sip:+XXXXX04960;ext=4960@rpvocsmed01.rpdc.local;user=phone;epid=E1A3C38520;tag=6f5e4da8ab To: sip:+XXXX37043@sip.uni-tel.dk;user=phone;tag=1c11675351 Call-ID: acf61479-f483-42d8-b5c0-be4feaf6dad7 CSeq: 1412 INVITE Contact: sip:1219@x.x.248.56:5060 Record-Route: sip:x.x.248.7;lr=on;ftag=6f5e4da8ab;did=5e1.cffb1006,sip:x.x.248.20;r2=on;lr;ftag=6f5e4da8ab,sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=6f5e4da8ab Supported: em,timer,replaces,path,early-session,resource-priority Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE Require: 100rel RSeq: 1 Server: Audiocodes-Sip-Gateway-Mediant 2000/v.5.60A.035.002 Content-Type: application/sdp Content-Length: 256
v=0 o=AudiocodesGW 11709683 11709345 IN IP4 178.21.248.56 s=Phone-Call c=IN IP4 x.x.248.22 t=0 0 m=audio 63608 RTP/AVP 8 101 c=IN IP4 x.x.248.22 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv
On Thu, Oct 14, 2010 at 4:57 PM, Juha Heinanen jh@tutpro.com wrote:
Morten Isaksen writes:
When OpenSer sends the message to Kamailio the recourd-routes look like this:
Record-Route: sip:x.x.248.20;r2=on;lr;ftag=3d9e7d131b Record-Route: sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=3d9e7d131b
But when the message comes back from Kamailio it is: Record-Route: sip:x.x.248.7;lr=on;ftag=3d9e7d131b;did=584.1a683a45,sip:x.x.248.20;r2=on;lr;ftag=3d9e7d131b,sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=3d9e7d131b
OpenSER forwards the message to the OCS with Record-route unchanged and the OCS gets confused and does not reply.
then file a bug to ocs folks, because ocs should understand r-r header that contains more than one entry.
-- juha
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
The spec requires just lr. There were some buggy clients that couldn't do just lr and therefor lr=on was introduced. If it works with lr, then don't enable lr=on (which is disabled by default): modparam("rr", "enable_full_lr", 0)
http://www.kamailio.org/docs/modules/3.1.x/modules_k/rr.html#id2805457
Regards, Ovidiu Sas
On Thu, Oct 14, 2010 at 12:19 PM, Morten Isaksen misak@misak.dk wrote:
Hi,
I was mistaken. This is not the problem. OCS kan handle r-r with multiple entry.
This one works OK - The OCS sends a PRACK
SIP/2.0 180 Ringing Via: SIP/2.0/TCP x.x.42.177:65371;rport=65371;branch=z9hG4bK991996e6 From: sip:+XXXXXX04963;ext=4963@rpvocsmed01.rpdc.local;user=phone;epid=E1A3C38520;tag=74504cfc7a To: sip:+XXXXX07357@sip.uni-tel.dk;user=phone;tag=1c564710455 Call-ID: 707d32ae-acaf-4c13-8117-f9b39c42f26e CSeq: 1429 INVITE Contact: sip:1102@x.x.248.56:5060 Record-Route: sip:x.x.248.20;r2=on;lr;ftag=74504cfc7a,sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=74504cfc7a Supported: em,timer,replaces,path,early-session,resource-priority Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE Require: 100rel RSeq: 1 Server: Audiocodes-Sip-Gateway-Mediant 2000/v.5.60A.035.002 Content-Type: application/sdp Content-Length: 258
v=0 o=AudiocodesGW 564744967 564744627 IN IP4 x.x.248.56 s=Phone-Call c=IN IP4 x.x.248.18 t=0 0 m=audio 62722 RTP/AVP 8 101 c=IN IP4 178.21.248.18 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv
But the OCS does not answer this. Could it be lr=on that triggers the problem? I do not have access to the OCS myself.
SIP/2.0 180 Ringing Via: SIP/2.0/TCP x.x.42.177:65251;rport=65251;branch=z9hG4bK9a5a33df From: sip:+XXXXX04960;ext=4960@rpvocsmed01.rpdc.local;user=phone;epid=E1A3C38520;tag=6f5e4da8ab To: sip:+XXXX37043@sip.uni-tel.dk;user=phone;tag=1c11675351 Call-ID: acf61479-f483-42d8-b5c0-be4feaf6dad7 CSeq: 1412 INVITE Contact: sip:1219@x.x.248.56:5060 Record-Route: sip:x.x.248.7;lr=on;ftag=6f5e4da8ab;did=5e1.cffb1006,sip:x.x.248.20;r2=on;lr;ftag=6f5e4da8ab,sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=6f5e4da8ab Supported: em,timer,replaces,path,early-session,resource-priority Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE Require: 100rel RSeq: 1 Server: Audiocodes-Sip-Gateway-Mediant 2000/v.5.60A.035.002 Content-Type: application/sdp Content-Length: 256
v=0 o=AudiocodesGW 11709683 11709345 IN IP4 178.21.248.56 s=Phone-Call c=IN IP4 x.x.248.22 t=0 0 m=audio 63608 RTP/AVP 8 101 c=IN IP4 x.x.248.22 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv
On Thu, Oct 14, 2010 at 4:57 PM, Juha Heinanen jh@tutpro.com wrote:
Morten Isaksen writes:
When OpenSer sends the message to Kamailio the recourd-routes look like this:
Record-Route: sip:x.x.248.20;r2=on;lr;ftag=3d9e7d131b Record-Route: sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=3d9e7d131b
But when the message comes back from Kamailio it is: Record-Route: sip:x.x.248.7;lr=on;ftag=3d9e7d131b;did=584.1a683a45,sip:x.x.248.20;r2=on;lr;ftag=3d9e7d131b,sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=3d9e7d131b
OpenSER forwards the message to the OCS with Record-route unchanged and the OCS gets confused and does not reply.
then file a bug to ocs folks, because ocs should understand r-r header that contains more than one entry.
-- juha
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
-- Morten Isaksen
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,
That solved the problem with OCS. :)
/Morten
On Thu, Oct 14, 2010 at 6:34 PM, Ovidiu Sas osas@voipembedded.com wrote:
The spec requires just lr. There were some buggy clients that couldn't do just lr and therefor lr=on was introduced. If it works with lr, then don't enable lr=on (which is disabled by default): modparam("rr", "enable_full_lr", 0)
http://www.kamailio.org/docs/modules/3.1.x/modules_k/rr.html#id2805457
Regards, Ovidiu Sas
On Thu, Oct 14, 2010 at 12:19 PM, Morten Isaksen misak@misak.dk wrote:
Hi,
I was mistaken. This is not the problem. OCS kan handle r-r with multiple entry.
This one works OK - The OCS sends a PRACK
SIP/2.0 180 Ringing Via: SIP/2.0/TCP x.x.42.177:65371;rport=65371;branch=z9hG4bK991996e6 From: sip:+XXXXXX04963;ext=4963@rpvocsmed01.rpdc.local;user=phone;epid=E1A3C38520;tag=74504cfc7a To: sip:+XXXXX07357@sip.uni-tel.dk;user=phone;tag=1c564710455 Call-ID: 707d32ae-acaf-4c13-8117-f9b39c42f26e CSeq: 1429 INVITE Contact: sip:1102@x.x.248.56:5060 Record-Route: sip:x.x.248.20;r2=on;lr;ftag=74504cfc7a,sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=74504cfc7a Supported: em,timer,replaces,path,early-session,resource-priority Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE Require: 100rel RSeq: 1 Server: Audiocodes-Sip-Gateway-Mediant 2000/v.5.60A.035.002 Content-Type: application/sdp Content-Length: 258
v=0 o=AudiocodesGW 564744967 564744627 IN IP4 x.x.248.56 s=Phone-Call c=IN IP4 x.x.248.18 t=0 0 m=audio 62722 RTP/AVP 8 101 c=IN IP4 178.21.248.18 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv
But the OCS does not answer this. Could it be lr=on that triggers the problem? I do not have access to the OCS myself.
SIP/2.0 180 Ringing Via: SIP/2.0/TCP x.x.42.177:65251;rport=65251;branch=z9hG4bK9a5a33df From: sip:+XXXXX04960;ext=4960@rpvocsmed01.rpdc.local;user=phone;epid=E1A3C38520;tag=6f5e4da8ab To: sip:+XXXX37043@sip.uni-tel.dk;user=phone;tag=1c11675351 Call-ID: acf61479-f483-42d8-b5c0-be4feaf6dad7 CSeq: 1412 INVITE Contact: sip:1219@x.x.248.56:5060 Record-Route: sip:x.x.248.7;lr=on;ftag=6f5e4da8ab;did=5e1.cffb1006,sip:x.x.248.20;r2=on;lr;ftag=6f5e4da8ab,sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=6f5e4da8ab Supported: em,timer,replaces,path,early-session,resource-priority Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE Require: 100rel RSeq: 1 Server: Audiocodes-Sip-Gateway-Mediant 2000/v.5.60A.035.002 Content-Type: application/sdp Content-Length: 256
v=0 o=AudiocodesGW 11709683 11709345 IN IP4 178.21.248.56 s=Phone-Call c=IN IP4 x.x.248.22 t=0 0 m=audio 63608 RTP/AVP 8 101 c=IN IP4 x.x.248.22 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv
On Thu, Oct 14, 2010 at 4:57 PM, Juha Heinanen jh@tutpro.com wrote:
Morten Isaksen writes:
When OpenSer sends the message to Kamailio the recourd-routes look like this:
Record-Route: sip:x.x.248.20;r2=on;lr;ftag=3d9e7d131b Record-Route: sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=3d9e7d131b
But when the message comes back from Kamailio it is: Record-Route: sip:x.x.248.7;lr=on;ftag=3d9e7d131b;did=584.1a683a45,sip:x.x.248.20;r2=on;lr;ftag=3d9e7d131b,sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=3d9e7d131b
OpenSER forwards the message to the OCS with Record-route unchanged and the OCS gets confused and does not reply.
then file a bug to ocs folks, because ocs should understand r-r header that contains more than one entry.
-- juha
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
-- Morten Isaksen
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
As long as the order of the Record-route headers is preserved, multiple Record-Route headers can be compacted into a single header and kamailio is able to deal with it. Please post a trace of a call exposing the issue.
Regards, Ovidiu Sas
On Thu, Oct 14, 2010 at 10:40 AM, Morten Isaksen misak@misak.dk wrote:
Hi,
I think I have found a issue with recourd-route in Kamailio 3.0.3.
My old setup was:
Microsoft OCS <--> (TCP) OpenSER (UDP) <---> (UDP) Mediant 2000 (ISDN).
That worked fine.
Now I have inserted a new server in this setup.
Microsoft OCS <--> (TCP) OpenSER (UDP) <---> (UDP) Kamailio (UDP) <--> (UDP) Mediant 2000 (ISDN).
When OpenSer sends the message to Kamailio the recourd-routes look like this:
Record-Route: sip:x.x.248.20;r2=on;lr;ftag=3d9e7d131b Record-Route: sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=3d9e7d131b
But when the message comes back from Kamailio it is: Record-Route: sip:x.x.248.7;lr=on;ftag=3d9e7d131b;did=584.1a683a45,sip:x.x.248.20;r2=on;lr;ftag=3d9e7d131b,sip:x.x.248.20;transport=tcp;r2=on;lr;ftag=3d9e7d131b
OpenSER forwards the message to the OCS with Record-route unchanged and the OCS gets confused and does not reply.
I am not that strong in the SIP RFC's. Is it part of the SIP standard to compact the record-route into one line?
Is it a bug in Kamailio or is it just a parameter that needs to be changed?
Any help will be much appreciated.
-- Morten Isaksen
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
-
Juha Heinanen -
Morten Isaksen -
Ovidiu Sas -
Sergey Okhapkin