[asterisk-bugs] [JIRA] (ASTERISK-27386) asterisk seems to miss udp port change in ok message

Tue Oct 31 19:03:30 CDT 2017

    [ https://issues.asterisk.org/jira/browse/ASTERISK-27386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=239770#comment-239770 ] 

Joe Pruett commented on ASTERISK-27386:
---------------------------------------

this looks like the issue: Call 1312597a3efcc69d68f0a63e231b6377 at 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 at 192.168.200.107>;tag=as465e5bd0
[2017-10-31 16:54:06] DEBUG[13082] chan_sip.c:  Header  2 [ 85]: To: <sip:5032332904 at 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 at 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 at 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 at 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 at 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 at 192.168.200.107:5060 responded to our reinvite without changing SDP version; ignoring SDP.

> asterisk seems to miss udp port change in ok message
> ----------------------------------------------------
>
>                 Key: ASTERISK-27386
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27386
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 13.17.2
>         Environment: freepbx distro
>            Reporter: Joe Pruett
>            Assignee: Joe Pruett
>         Attachments: ast.pcap
>
>
> 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.

--
This message was sent by Atlassian JIRA
(v6.2#6252)