Hi All,
I have a scenario where I have 2 asterisk media servers that, when calling a registered sip account, will forward off the invite to a location server, who looks up the contact information, then forwards the invite off to the proxy that the user registered against (done via the path module). This all appears to work perfectly until the us hangs up the call. The BYE message does not make it all the way back to the originating asterisk media server, it makes it back to the location server that looked up the registration information.
To overcome this issue, I add a "Record-Route" header specifying the address of the asterisk media server that the request originated from. However, when I add the custom header, the Invite shows up as fragmented packet my wire-shark trace at the end-user's soft-phone. The call sets up properly and when I hang up it looks like the BYE message makes it all the way back to the media server, but when it is relayed on the the caller, the sip proxy then fails the call with a message too big. If I remove the line that adds the record-route header, then all looks fine, except that I am unable to tear down calls from sip end-points.
The specific line I'm using to add the header is as follows:
insert_hf("Record-Route: sip:$si:$sp;lr=on\r\n","Record-Route");
I do remove this from the route header on in-dialog replies as loose-route does not remove the header on the original location server as it does not see the route header as local, so I manually remove it.
Has anyone come across this particular issue? I'm using Kamailio 3.1.2. Am I going about this is the wrong way? I've been reading the module docs for registrar/usrloc/rr/path/textops to see if there is something I've missed but cannot see it.
Any tips/suggestions would be greatly appreciated.
Thanks
It sounds like adding the RR header adds just enough payload to push the size of your packet over the edge of being too close to the MTU boundary. There's no particular solution except to make the message smaller, and/or use a receiving endpoint that supports fragmented SIP messages.
On 03/14/2011 03:35 PM, Asgaroth wrote:
Hi All,
I have a scenario where I have 2 asterisk media servers that, when calling a registered sip account, will forward off the invite to a location server, who looks up the contact information, then forwards the invite off to the proxy that the user registered against (done via the path module). This all appears to work perfectly until the us hangs up the call. The BYE message does not make it all the way back to the originating asterisk media server, it makes it back to the location server that looked up the registration information.
To overcome this issue, I add a "Record-Route" header specifying the address of the asterisk media server that the request originated from. However, when I add the custom header, the Invite shows up as fragmented packet my wire-shark trace at the end-user's soft-phone. The call sets up properly and when I hang up it looks like the BYE message makes it all the way back to the media server, but when it is relayed on the the caller, the sip proxy then fails the call with a message too big. If I remove the line that adds the record-route header, then all looks fine, except that I am unable to tear down calls from sip end-points.
The specific line I'm using to add the header is as follows:
insert_hf("Record-Route:sip:$si:$sp;lr=on\r\n","Record-Route");
I do remove this from the route header on in-dialog replies as loose-route does not remove the header on the original location server as it does not see the route header as local, so I manually remove it.
Has anyone come across this particular issue? I'm using Kamailio 3.1.2. Am I going about this is the wrong way? I've been reading the module docs for registrar/usrloc/rr/path/textops to see if there is something I've missed but cannot see it.
Any tips/suggestions would be greatly appreciated.
Thanks
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
Am 14.03.2011 20:35, schrieb Asgaroth:
Hi All,
I have a scenario where I have 2 asterisk media servers that, when calling a registered sip account, will forward off the invite to a location server, who looks up the contact information, then forwards the invite off to the proxy that the user registered against (done via the path module). This all appears to work perfectly until the us hangs up the call. The BYE message does not make it all the way back to the originating asterisk media server, it makes it back to the location server that looked up the registration information.
To overcome this issue, I add a "Record-Route" header specifying the address of the asterisk media server that the request originated from. However, when I add the custom header, the Invite shows up as fragmented packet my wire-shark trace at the end-user's soft-phone. The call sets up properly and when I hang up it looks like the BYE message makes it all the way back to the media server, but when it is relayed on the the caller, the sip proxy then fails the call with a message too big. If I remove the line that adds the record-route header, then all looks fine, except that I am unable to tear down calls from sip end-points.
The specific line I'm using to add the header is as follows:
insert_hf("Record-Route: sip:$si:$sp;lr=on\r\n","Record-Route");
sounds like you are using the internal record_route() function and adding header manually. This might cause problems. If you play around with RR headers, just add them all manually.
Probably you have 2 issues: 1. bad in-dialog routing back to your Asterisk server, 2. fragmentation problem.
Fragmentation shouldn't be a problem, all devices should handle them (I personally never had any issues). If you need to reduce the packet size you can try to remove unneeded headers and remove unused codecs from the SDP.
But back to the original issues. You said, that the BYE (should be loose routed) is not routed correctly back to the Asterisk server. Fix this - as this is your real problem. Take a look at the contact headers and in-dialog request URIs. Then you need not play around with faked record-route headers.
If you need help, post an ngrep trace (or pcap file) of the scenario:
ngrep -W byline -t -q -P "" port 5060
regards klaus
I do remove this from the route header on in-dialog replies as loose-route does not remove the header on the original location server as it does not see the route header as local, so I manually remove it.
Has anyone come across this particular issue? I'm using Kamailio 3.1.2. Am I going about this is the wrong way? I've been reading the module docs for registrar/usrloc/rr/path/textops to see if there is something I've missed but cannot see it.
Any tips/suggestions would be greatly appreciated.
Thanks
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 Klaus,
On 15/03/2011 07:27, Klaus Darilion wrote:
But back to the original issues. You said, that the BYE (should be loose routed) is not routed correctly back to the Asterisk server. Fix this - as this is your real problem. Take a look at the contact headers and in-dialog request URIs. Then you need not play around with faked record-route headers.
I was looking at this a little more. If I remove the manually added RR header, then, yes, the BYE message does not make it back to the originating asterisk media server. The problem, I think, occurs when the contact address is changed from the originating media server to the location server, at the proxy. I think it does this because of the "loose_route()" I force to load the "received" parameter from the "Route" header as passed from the location server. So, for example:
[1] INVITE, from Asterisk, with contact address of "me@1.1.1.1:5060", destined to location server "1.1.1.2:5060" [2] INVITE looked up on location server, then forwarded on to Proxy server "1.1.1.3:5060" with INVITE contact still "me@1.1.1.1:5060" and "Route" parameter has "<1.1.1.3:5060;lr;received="sip:55.55.55.55:1234>" [3] When I perform the "loose_route" on the initial INVITE from location server (to enforce the route), then the contact address changes from "me@1.1.1.1:5060" to "me@1.1.1.2:5060". This is where I think the issue comes in why the BYE message only makes it back to the location server and not the asterisk server.
The problem is, is that I dont know how else to load the "Route" as defined in the route header. I have the "use_received" parameter set for the path module, but it does not seem to change the destination uri to that defined in the the received parameter of the route header on the initial invite (unless I perform a loose_route, then it will load it). The documentation for the path module seems to imply that it will use the received parameter in the Route header that is for the local server. But it does not seem to be doing that by default. Do I need to perform a loose_route before relaying to load the route?
I prefer for ngrep traces (you could replace usernames/IP-addresses)
klaus
On 15.03.2011 10:59, Asgaroth wrote:
Hi Klaus,
On 15/03/2011 07:27, Klaus Darilion wrote:
But back to the original issues. You said, that the BYE (should be loose routed) is not routed correctly back to the Asterisk server. Fix this - as this is your real problem. Take a look at the contact headers and in-dialog request URIs. Then you need not play around with faked record-route headers.
I was looking at this a little more. If I remove the manually added RR header, then, yes, the BYE message does not make it back to the originating asterisk media server. The problem, I think, occurs when the contact address is changed from the originating media server to the location server, at the proxy. I think it does this because of the "loose_route()" I force to load the "received" parameter from the "Route" header as passed from the location server. So, for example:
[1] INVITE, from Asterisk, with contact address of "me@1.1.1.1:5060", destined to location server "1.1.1.2:5060" [2] INVITE looked up on location server, then forwarded on to Proxy server "1.1.1.3:5060" with INVITE contact still "me@1.1.1.1:5060" and "Route" parameter has"<1.1.1.3:5060;lr;received="sip:55.55.55.55:1234>" [3] When I perform the "loose_route" on the initial INVITE from location server (to enforce the route), then the contact address changes from "me@1.1.1.1:5060" to "me@1.1.1.2:5060". This is where I think the issue comes in why the BYE message only makes it back to the location server and not the asterisk server.
The problem is, is that I dont know how else to load the "Route" as defined in the route header. I have the "use_received" parameter set for the path module, but it does not seem to change the destination uri to that defined in the the received parameter of the route header on the initial invite (unless I perform a loose_route, then it will load it). The documentation for the path module seems to imply that it will use the received parameter in the Route header that is for the local server. But it does not seem to be doing that by default. Do I need to perform a loose_route before relaying to load the route?
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 15/03/2011 14:29, Klaus Darilion wrote:
I prefer for ngrep traces (you could replace usernames/IP-addresses)
I have attached 2 text files of ngrep traces. Both are of the same call, one trace was performed at the asterisk media server, and the other was performed at the proxy. I've replaced all user names and ip address.
Just for info the IP are as follows:
1.2.3.1 = Asterisk media server (running asterisk 1.8.3) 1.2.3.2 = Kamailio location server (running kamailio 3.1.2) 1.2.3.3 = Kamailio proxy server (internal interface) (running kamailio 3.1.2) 5.1.1.1 = Kamailio proxy server (external interface) (running kamailio 3.1.2) 6.1.1.1 = Provider proxy server 6.1.1.2 = Provider media gateway
Please let me know if you require any additional information.
Thank you for taking the time to take a look at the traces.
Next time please send only the trace of the relevant SIP dialog (between provider and Kamailio/Asterisk). Ther seconds dialog started by Asterisk is not relevant.
The problem is rather simple:
U 2011/03/15 15:43:48.237614 6.1.1.1:5060 -> 5.1.1.1:5060 INVITE sip:1231234@domain.com SIP/2.0 Record-Route: sip:6.1.1.1;lr=on;ftag=B0432A3C-37B Via: SIP/2.0/UDP 6.1.1.1;branch=z9hG4bK4e1f.614446c3.0 Via: SIP/2.0/UDP 6.1.1.2:5060;branch=z9hG4bK47ABD036B Remote-Party-ID: sip:1231000@6.1.1.2;party=calling;screen=yes;privacy=off From: "1231000" sip:1231000@6.1.1.2;tag=B0432A3C-37B To: sip:1231234@ire.e164.org.uk Date: Tue, 15 Mar 2011 15:43:48 gmt Call-ID: DA4501A5-4E5111E0-A17EB0FA-C1EC011B@6.1.1.2 Supported: timer,resource-priority,replaces Min-SE: 1800 User-Agent: MSSGW Allow: INVITE, BYE, CANCEL, ACK CSeq: 101 INVITE Max-Forwards: 14 Timestamp: 1300203828 Contact: sip:1231000@6.1.1.2:5060 Expires: 180 Allow-Events: telephone-event Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 417
v=0 o=CiscoSystemsSIP-GW-UserAgent 4797 428 IN IP4 6.1.1.2 s=SIP Call c=IN IP4 6.1.1.2 t=0 0 m=audio 23382 RTP/AVP 8 18 4 3 98 0 101 c=IN IP4 6.1.1.2 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:4 G723/8000 a=fmtp:4 bitrate=6.3;annexa=no a=rtpmap:3 GSM/8000 a=rtpmap:98 G726-32/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16
U 2011/03/15 15:43:48.246612 5.1.1.1:5060 -> 6.1.1.1:5060 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 6.1.1.1;branch=z9hG4bK4e1f.614446c3.0;rport=5060 Via: SIP/2.0/UDP 6.1.1.2:5060;branch=z9hG4bK47ABD036B From: "1231000" sip:1231000@6.1.1.2;tag=B0432A3C-37B To: sip:1231234@ire.e164.org.uk Call-ID: DA4501A5-4E5111E0-A17EB0FA-C1EC011B@6.1.1.2 CSeq: 101 INVITE Server: kamailio (3.1.2 (i386/linux)) Content-Length: 0
U 2011/03/15 15:43:48.248371 1.2.3.3:5060 -> 1.2.3.1:5060 INVITE sip:1231234@domain.com SIP/2.0 Record-Route: sip:1.2.3.3;r2=on;lr=on;ftag=B0432A3C-37B Record-Route: sip:5.1.1.1;r2=on;lr=on;ftag=B0432A3C-37B Record-Route: sip:6.1.1.1;lr=on;ftag=B0432A3C-37B Via: SIP/2.0/UDP 1.2.3.3;branch=z9hG4bK4e1f.576ffdd1.0 Via: SIP/2.0/UDP 6.1.1.1;rport=5060;branch=z9hG4bK4e1f.614446c3.0 Via: SIP/2.0/UDP 6.1.1.2:5060;branch=z9hG4bK47ABD036B Remote-Party-ID: sip:1231000@6.1.1.2;party=calling;screen=yes;privacy=off From: "1231000" sip:1231000@6.1.1.2;tag=B0432A3C-37B To: sip:1231234@ire.e164.org.uk Date: Tue, 15 Mar 2011 15:43:48 gmt Call-ID: DA4501A5-4E5111E0-A17EB0FA-C1EC011B@6.1.1.2 Supported: timer,resource-priority,replaces Min-SE: 1800 User-Agent: MSSGW Allow: INVITE, BYE, CANCEL, ACK CSeq: 101 INVITE Max-Forwards: 13 Timestamp: 1300203828 Contact: sip:1231000@6.1.1.1:5060
^^^^^^^^^^^^^^^^
Here, Kamailio changed the received contact. As there is another proxy between the UAC and Kamailio, Kamailio must not modify the contact. (remove fix_nated_contact() for requests coming from the service provider)
By changing the contact, the BYE gets looped in the provider's Openser proxy until the message gets rejected due to the size.
regards Klaus
On 15.03.2011 18:16, Asgaroth wrote:
On 15/03/2011 14:29, Klaus Darilion wrote:
I prefer for ngrep traces (you could replace usernames/IP-addresses)
I have attached 2 text files of ngrep traces. Both are of the same call, one trace was performed at the asterisk media server, and the other was performed at the proxy. I've replaced all user names and ip address.
Just for info the IP are as follows:
1.2.3.1 = Asterisk media server (running asterisk 1.8.3) 1.2.3.2 = Kamailio location server (running kamailio 3.1.2) 1.2.3.3 = Kamailio proxy server (internal interface) (running kamailio 3.1.2) 5.1.1.1 = Kamailio proxy server (external interface) (running kamailio 3.1.2) 6.1.1.1 = Provider proxy server 6.1.1.2 = Provider media gateway
Please let me know if you require any additional information.
Thank you for taking the time to take a look at the traces.
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 Klaus,
On 16/03/2011 09:17, Klaus Darilion wrote:
Contact: sip:1231000@6.1.1.1:5060
^^^^^^^^^^^^^^^^Here, Kamailio changed the received contact. As there is another proxy between the UAC and Kamailio, Kamailio must not modify the contact. (remove fix_nated_contact() for requests coming from the service provider)
By changing the contact, the BYE gets looped in the provider's Openser proxy until the message gets rejected due to the size.
Thank you again for taking the time to look at the trace.
This did indeed fix the issue, it was, as you said, a nated contact substitution that was the issue.
Cant believe I missed that though, sometimes all it takes is another pair of eyes :)
Thank you all for taking the time for reading and helping out :)
-
Alex Balashov -
Asgaroth -
Klaus Darilion