[Home]

Summary:ASTERISK-27386: asterisk seems to miss udp port change in ok message
Reporter:Joe Pruett (joey@q7.com)Labels:
Date Opened:2017-10-31 14:54:56Date Closed:2017-10-31 19:12:21
Priority:MajorRegression?
Status:Closed/CompleteComponents:
Versions:13.17.2 Frequency of
Occurrence
Related
Issues:
Environment:freepbx distroAttachments:( 0) ast.pcap
Description:i'm attaching a pcap file that shows that the rtp udp port starts at 10474, then goes to 10476 (which asterisk copes with), then in the ok message it switches back to 10474, but asterisk keeps talking to 10476. there are a few icmp unreachables in the mix that don't make sense, but i see those for calls that work, so i'm ignoring them for now.

backstory:

on a new test system i was putting together i was having issues where outgoing calls had no audio in either direction. no firewalls or nat were involved. using a sangoma phone with current freepbx. it had been working for months and then stopped working. i was in the middle of dealing with a fire (literal fire) at our office, so i ignored it and am not sure if this was coincident with an update or not.

after digging into packet dumps, i think i found the problem. the trunk we are using is coming off an adtran and through some copy/paste i had enabled 'ringback override 180' which makes the adtran produce a ring waveform rather than a ring sip message. while doing that it seems to switch the udp ports for the rtp traffic and asterisk misses the last udp change in the ok message and keeps trying to use the port that the ringing comes from (at least that is my theory of what the port change is about).

an old trixbox system needed the ringback override and it copes with the port changing ok. when i changed the config for the new freepbx to not use the ringback override, then calls started working again.
Comments:By: Asterisk Team (asteriskteam) 2017-10-31 14:54:56.595-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Joshua C. Colp (jcolp) 2017-10-31 15:16:43.765-0500

Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. Please read over the Asterisk Issue Guidelines [1] which discusses the information necessary for your issue to be resolved and the format that information needs to be in. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need:

1. The specific steps or actions you took that caused you to encounter the problem.
2. The behavior you expected and the location of documentation that led you to that expectation.
3. The behavior you actually encountered.

To demonstrate the issue in detail, please include Asterisk log files generated per the instructions on the wiki [2]. If applicable, please ensure that protocol-level trace debugging is enabled, e.g., 'sip set debug on' if the issue involves chan_sip, and configuration information such as dialplan and channel configuration.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines

[2] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

In this particular case we also need to see the Asterisk logs as well.
By: Joe Pruett (joey@q7.com) 2017-10-31 15:36:39.926-0500

were you able to look at the pcap file?
By: Joshua C. Colp (jcolp) 2017-10-31 16:08:23.066-0500

Yes, but that just shows me the traffic. It doesn't tell me what Asterisk did with it.
By: Joe Pruett (joey@q7.com) 2017-10-31 16:27:28.350-0500

am i reading it correctly? the sip "ok" message indicates that rtp should now go over 10474, but asterisk continues trying to send to 10476? if i am interpreting it correctly, then i'm willing to break things again and gather more info, but if i'm misreading things, then i'd rather not spin my wheels even more.
By: Joshua C. Colp (jcolp) 2017-10-31 16:49:10.630-0500

Yes, that is what the SDP states.
By: Joe Pruett (joey@q7.com) 2017-10-31 19:03:25.328-0500

this looks like the issue: Call 1312597a3efcc69d68f0a63e231b6377@192.168.200.107:5060 responded to our reinvite without changing SDP version; ignoring SDP.

this could very well just be bad behavior on the adtran's part.

if this asterisk behavior is what is expected, then i'll drop the issue since i am able to make things work by disabling the fake ringing, which isn't needed with this updated pbx.

[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:  Header  0 [ 14]: SIP/2.0 200 OK
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:  Header  1 [ 53]: From: <sip:5032223086@192.168.200.107>;tag=as465e5bd0
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:  Header  2 [ 85]: To: <sip:5032332904@192.168.200.119>;tag=52705f0-7f000001-13c4-278715-76b0d6b1-278715
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:  Header  3 [ 62]: Call-ID: 1312597a3efcc69d68f0a63e231b6377@192.168.200.107:5060
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:  Header  4 [ 16]: CSeq: 102 INVITE
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:  Header  5 [ 71]: Via: SIP/2.0/UDP 192.168.200.107:5060;rport=5060;branch=z9hG4bK2bf1644b
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:  Header  6 [ 60]: Contact: <sip:5032332904@192.168.200.119:5060;transport=UDP>
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:  Header  7 [ 26]: Supported: 100rel,replaces
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:  Header  8 [ 78]: Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:  Header  9 [ 57]: User-Agent: ADTRAN_Total_Access_908e_2nd_Gen/R12.3.0.SA.E
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:  Header 10 [ 29]: Content-Type: application/sdp
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:  Header 11 [ 19]: Content-Length: 214
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:  Header 12 [  0]:
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:    Body  0 [  3]: v=0
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:    Body  1 [ 39]: o=- 1509494038 2 IN IP4 192.168.200.119
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:    Body  2 [  3]: s=-
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:    Body  3 [ 24]: c=IN IP4 192.168.200.119
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:    Body  4 [  5]: t=0 0
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:    Body  5 [ 27]: m=audio 10752 RTP/AVP 0 101
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:    Body  6 [ 25]: a=silenceSupp:off - - - -
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:    Body  7 [ 20]: a=rtpmap:0 PCMU/8000
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:    Body  8 [ 33]: a=rtpmap:101 telephone-event/8000
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:    Body  9 [ 15]: a=fmtp:101 0-15
[2017-10-31 16:54:06] VERBOSE[13082] chan_sip.c: --- (12 headers 10 lines) ---
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c: = Looking for  Call ID: 1312597a3efcc69d68f0a63e231b6377@192.168.200.107:5060 (Checking To) --From tag as465e5bd0 --To-tag 52705f0-7f000001-13c4-278715-76b0d6b1-278715  
[2017-10-31 16:54:06] DEBUG[13082][C-0000003c] chan_sip.c: Acked pending invite 102
[2017-10-31 16:54:06] DEBUG[13082][C-0000003c] chan_sip.c: Stopping retransmission on '1312597a3efcc69d68f0a63e231b6377@192.168.200.107:5060' of Request 102: Match Found
[2017-10-31 16:54:06] DEBUG[13082][C-0000003c] chan_sip.c: SIP response 200 to standard invite
[2017-10-31 16:54:06] DEBUG[13082][C-0000003c] chan_sip.c: Processing session-level SDP v=0... UNSUPPORTED OR FAILED.
[2017-10-31 16:54:06] DEBUG[13082][C-0000003c] chan_sip.c: Call 1312597a3efcc69d68f0a63e231b6377@192.168.200.107:5060 responded to our reinvite without changing SDP version; ignoring SDP.

By: Joshua C. Colp (jcolp) 2017-10-31 19:12:21.162-0500

The RFC[1] states that if the SDP changes then the version should be incremented. If it's the same then it hasn't changed. This behavior can be configured in chan_sip using the "ignoresdpversion" option. When set to yes then the version is ignored and the SDP is always negotiated.

[1] https://www.ietf.org/rfc/rfc3264.txt
By: Joe Pruett (joey@q7.com) 2017-11-01 10:11:51.277-0500

thanks. now that i know the underlying issue i can see a number of other folks have run into it without finding the root cause. i'll try to notify adtran, but not sure if this hardware is too old for them to bother.
By: Asterisk Team (asteriskteam) 2017-11-01 10:11:51.511-0500

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.