[Home]

Summary:ASTERISK-15028: RTP Media Port Change Ignored
Reporter:Team Forrest (teamforrest)Labels:
Date Opened:2009-10-23 14:51:06Date Closed:2011-06-07 14:08:09
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 16122-sip-debug.txt
( 1) bugreport
Description:In a SIP conversation, asterisk is sending an OK to a SIP Reinvite with a media port change. Asterisk is not using this new port and will continue to use the original port in the original invite. In the example below, when connecting to 71.116.126.81, the original media port was 7750. A reinvite was made to port 7752, however asterisk will continue to use 7750. This can be reproduced and has same behavior no matter how the canreinvite flag is set (ie no, yes, update, etc.). This can be tested by calling to 3366@conf.zipdx.com and pressing 2. This test was done to 3366@conf.hificonf.com, which is a lab server active at the time of this post.

NGREP of SIP traffic:

ngrep -W byline -q -T 71.116.126.81
interface: eth0 (172.16.1.0/255.255.255.0)
match: 71.116.126.81

U +10.175362 71.116.126.81:5060 -> 172.16.1.220:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 76.206.40.250:5060;rport=1024;branch=z9hG4bK05f69878.
From: "Fred Posner" <sip:qxork@76.206.40.250>;tag=as61320760.
Call-ID: 723341d540ae29472b91211466cf500d@76.206.40.250.
CSeq: 102 INVITE.
To: <sip:3366@conf.hificonf.com>;tag=telStage-2d24-4ae1fb95.
Content-Length: 0.
Contact: <sip:71.116.126.81;transport=udp>.
Server: ZipDX-3.10.3.
.


U +0.030072 71.116.126.81:5060 -> 172.16.1.220:5060
SIP/2.0 200 Ok.
Via: SIP/2.0/UDP 76.206.40.250:5060;rport=1024;branch=z9hG4bK05f69878.
From: "Fred Posner" <sip:qxork@76.206.40.250>;tag=as61320760.
Call-ID: 723341d540ae29472b91211466cf500d@76.206.40.250.
CSeq: 102 INVITE.
To: <sip:3366@conf.hificonf.com>;tag=telStage-2d24-4ae1fb95.
Content-Length: 203.
Content-Type: application/sdp.
Allow: INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, INFO, REGISTER, SUBSCRIBE, MESSAGE.
Contact: <sip:71.116.126.81;transport=udp>.
Server: ZipDX-3.10.3.
Supported: timer.
.
v=0.
o=telStage 270 3465312789 IN IP4 71.116.126.81.
s=-.
c=IN IP4 71.116.126.81.
t=0 0.
m=audio 7750 RTP/AVP 9 101.
a=rtpmap:9 G722/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.


U +0.000307 172.16.1.220:5060 -> 71.116.126.81:5060
ACK sip:71.116.126.81;transport=udp SIP/2.0.
Via: SIP/2.0/UDP 76.206.40.250:5060;branch=z9hG4bK2b902523;rport.
Max-Forwards: 70.
From: "Fred Posner" <sip:qxork@76.206.40.250>;tag=as61320760.
To: <sip:3366@conf.hificonf.com>;tag=telStage-2d24-4ae1fb95.
Contact: <sip:qxork@76.206.40.250>.
Call-ID: 723341d540ae29472b91211466cf500d@76.206.40.250.
CSeq: 102 ACK.
User-Agent: Asterisk PBX 1.6.0.15.
Content-Length: 0.
.


U +11.995979 71.116.126.81:5060 -> 172.16.1.220:5060
INVITE sip:qxork@76.206.40.250 SIP/2.0.
From: <sip:3366@conf.hificonf.com>;tag=telStage-2d24-4ae1fb95.
To: "Fred Posner" <sip:qxork@76.206.40.250>;tag=as61320760.
Contact: <sip:71.116.126.81;transport=udp>.
Call-ID: 723341d540ae29472b91211466cf500d@76.206.40.250.
CSeq: 20447 INVITE.
Content-Length: 184.
Content-Type: application/sdp.
Supported: timer.
User-Agent: ZipDX-3.10.3.
Max-Forwards: 70.
Via: SIP/2.0/UDP 71.116.126.81:5060;branch=z9hG4bK4ae1fba1-0050-00004858-6a76558a-8d23bf0c.
.
v=0.
o=telStage 271 3465312801 IN IP4 71.116.126.81.
s=-.
c=IN IP4 71.116.126.81.
t=0 0.
m=audio 7752 RTP/AVP 9 96.
a=rtpmap:9 G722/8000.
a=rtpmap:96 telephone-event/8000.
a=ptime:20.


U +0.000335 172.16.1.220:5060 -> 71.116.126.81:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 71.116.126.81:5060;branch=z9hG4bK4ae1fba1-0050-00004858-6a76558a-8d23bf0c;received=71.116.126.81.
From: <sip:3366@conf.hificonf.com>;tag=telStage-2d24-4ae1fb95.
To: "Fred Posner" <sip:qxork@76.206.40.250>;tag=as61320760.
Call-ID: 723341d540ae29472b91211466cf500d@76.206.40.250.
CSeq: 20447 INVITE.
User-Agent: Asterisk PBX 1.6.0.15.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
Supported: replaces, timer.
Contact: <sip:qxork@76.206.40.250>.
Content-Length: 0.
.


U +0.000041 172.16.1.220:5060 -> 71.116.126.81:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 71.116.126.81:5060;branch=z9hG4bK4ae1fba1-0050-00004858-6a76558a-8d23bf0c;received=71.116.126.81.
From: <sip:3366@conf.hificonf.com>;tag=telStage-2d24-4ae1fb95.
To: "Fred Posner" <sip:qxork@76.206.40.250>;tag=as61320760.
Call-ID: 723341d540ae29472b91211466cf500d@76.206.40.250.
CSeq: 20447 INVITE.
User-Agent: Asterisk PBX 1.6.0.15.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
Supported: replaces, timer.
Contact: <sip:qxork@76.206.40.250>.
Content-Type: application/sdp.
Content-Length: 263.
.
v=0.
o=root 1586015446 1586015447 IN IP4 76.206.40.250.
s=Asterisk PBX 1.6.0.15.
c=IN IP4 76.206.40.250.
t=0 0.
m=audio 10378 RTP/AVP 9 96.
a=rtpmap:9 G722/8000.
a=rtpmap:96 telephone-event/8000.
a=fmtp:96 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.


U +0.118024 71.116.126.81:5060 -> 172.16.1.220:5060
ACK sip:qxork@76.206.40.250 SIP/2.0.
From: <sip:3366@conf.hificonf.com>;tag=telStage-2d24-4ae1fb95.
To: "Fred Posner" <sip:qxork@76.206.40.250>;tag=as61320760.
Contact: <sip:71.116.126.81;transport=udp>.
Call-ID: 723341d540ae29472b91211466cf500d@76.206.40.250.
CSeq: 20447 ACK.
Content-Length: 0.
Via: SIP/2.0/UDP 71.116.126.81:5060;branch=z9hG4bK4ae1fba1-00dd-00004859-6a76558a-8d23bf0c.
.


U +15.023183 172.16.1.220:5060 -> 71.116.126.81:5060
BYE sip:71.116.126.81;transport=udp SIP/2.0.
Via: SIP/2.0/UDP 76.206.40.250:5060;branch=z9hG4bK519c988b;rport.
Max-Forwards: 70.
From: "Fred Posner" <sip:qxork@76.206.40.250>;tag=as61320760.
To: <sip:3366@conf.hificonf.com>;tag=telStage-2d24-4ae1fb95.
Call-ID: 723341d540ae29472b91211466cf500d@76.206.40.250.
CSeq: 103 BYE.
User-Agent: Asterisk PBX 1.6.0.15.
X-Asterisk-HangupCause: Normal Clearing.
X-Asterisk-HangupCauseCode: 16.
Content-Length: 0.
.

Comments:By: Team Forrest (teamforrest) 2009-10-23 16:59:44

Added a sip history / sip debug / verbose logging from another test call.
By: Leif Madsen (lmadsen) 2009-10-26 08:57:22

Acknowledging this issue as I've gotten the same thing.
By: Jeff Peeler (jpeeler) 2009-12-08 17:38:30.000-0600

Can you ensure that you have nat=no set? Otherwise, I'd like the sip debug along with the rtp debug.
By: Team Forrest (teamforrest) 2009-12-08 17:59:30.000-0600

I currently have:

canreinvite=yes
nat=yes

I tried different settings with same results.

I did attach a sip history and sip debug.
By: Jeff Peeler (jpeeler) 2009-12-08 18:05:24.000-0600

RTP debug output provides different information than the SIP debug. Can you not provide that as well?
By: Team Forrest (teamforrest) 2009-12-08 18:33:45.000-0600

I have not experienced this with 1.6.2 branch and no longer have a log from early October. I did provide the method of recreating this:

"This can be reproduced and has same behavior no matter how the canreinvite flag is set (ie no, yes, update, etc.). This can be tested by calling to 3366@conf.zipdx.com and pressing 2. This test was done to 3366@conf.hificonf.com, which is a lab server active at the time of this post."

Have you attempted to recreate? (if you have that platform running and can reproduce would make more sense than me downgrading to send a log)
By: Jeff Peeler (jpeeler) 2009-12-09 12:33:50.000-0600

I've tested both with 1.6.0.15 and 1.6.0 head and am seeing the rtp get sent to the proper port, both with nat=yes and nat=no. Note that when nat=yes, the port being sent to will only use what's in the reinvite until another packet is received. Since I haven't found any problem, I'll have to close this unless the rtp debug output is provided along with the sip debug.
By: Team Forrest (teamforrest) 2009-12-09 13:36:14.000-0600

Leif,

Do you have the other version running to make a rtp debug?
By: Leif Madsen (lmadsen) 2009-12-10 12:03:33.000-0600

Logging attached. Used 1.6.1.10.
By: Jeff Peeler (jpeeler) 2009-12-10 13:21:12.000-0600

The attached log is not indicative of any problem. I guess I'll wait a little longer for logs actually demonstrating an issue.
By: Leif Madsen (lmadsen) 2009-12-10 13:23:14.000-0600

What part isn't a problem? The audio is dropped in that scenario so I don't hear it anymore on my phone.
By: Jeff Peeler (jpeeler) 2009-12-10 14:03:27.000-0600

Audio being dropped with the scenario of nat=yes is expected behavior. But remember, the port behavior is the concern.
By: Leif Madsen (lmadsen) 2009-12-10 14:13:06.000-0600

If it is expected behaviour, then I believe some sort of documentation update need to be done to make this clear to the end user.

However, here is a conversation on IRC in #vuc which makes me wonder why 1.6.2.0 acts differently than 1.6.0 and 1.6.1:

<DocAwesome> qxork: when you enable nat=yes in 1.6.2.0, does it still work?
<qxork> yes
<DocAwesome> hmmmmmmmmmm
<qxork> I know
<DocAwesome> that makes me wonder if there is something broken in 1.6.2.0
<DocAwesome> maybe it SHOULDN'T work :)
<qxork> I tried it with nat=yes and nat=no
<qxork> in 1.6.1 or 1.6.0
<qxork> with same results.
<DocAwesome> my gut instinct is that it has something to do with the kill-the-user stuff...
<DocAwesome> qxork: you're saying nat=yes in 1.6.0 and 1.6.1 causes it to drop audio, but not in 1.6.2.0 ?
<DocAwesome> or that you don't get dropped audio at all anymore?
<qxork> in 1.6.0 and 1.6.1 I dropped audio with nat=yes. I also dropped it with nat=no
<qxork> in 1,6,2 I have nat=yes and have not dropped
<DocAwesome> huh... that's even more strange as I don't have the issue with dropped audio with 1.6.1.10 with nat=no
<DocAwesome> something is not in sync then
By: Jeff Peeler (jpeeler) 2009-12-21 10:36:02.000-0600

Closing this as no evidence for an issue was provided.