14 Mar
2011
14 Mar
'11
10:35 p.m.
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
14 Mar
14 Mar
11:15 p.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
15 Mar
15 Mar
10:27 a.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
12:59 p.m.
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?
5:29 p.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
8:16 p.m.
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.
16 Mar
16 Mar
12:17 p.m.
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(a)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(a)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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:32 p.m.
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 :)
4986
days inactive
4988
days old
7 comments
3 participants
participants (3)
-
Alex Balashov -
Asgaroth -
Klaus Darilion