The Adtran community holiday season is starting next week! The holiday period will span from December 21, 2024 to January 6, 2025. During this time, responses to feedback form submissions may be delayed. If you are encountering product issues, you can reach out to Adtran support at any time.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jjeffries
New Contributor II

one way audio on calls to a 908e doing SIP -> PRI... 908 ICMP-rejects RTP?

Jump to solution

Getting one way voice on calls from SIP -> 908e PRI. Calls out from the PRI -> SIP work fine.

SDP sets up the call normally, but then RTP packets to the agreed-upon port are not accepted by the 908, check it out:

SDP from switch:
        v=0
        o=- 897409120 897409120 IN IP4 x.y.52.23
        s=-
        c=IN IP4 x.y.52.23
        t=0 0
        m=audio 33530 RTP/AVP 18 0 101
        a=rtpmap:101 telephone-event/8000
        a=ptime:20

SDP 908:
        v=0
        o=- 1375286943 2 IN IP4 10.3.64.72
        s=-
        c=IN IP4 10.3.64.72
        t=0 0
        m=audio 10006 RTP/AVP 0 101
        a=rtpmap:0 PCMU/8000
        a=silenceSupp:off - - - -
        a=rtpmap:101 telephone-event/8000
        a=fmtp:101 0-15


12:08:38.129635 IP (tos 0xb8, ttl 63, id 26129, offset 0, flags [none], proto UDP (17), length 200)
    x.y.52.23.33530 > 10.3.64.72.10006: UDP, length 172
12:08:38.130794 IP (tos 0x0, ttl 255, id 1888, offset 0, flags [none], proto ICMP (1), length 56)
    10.3.64.72 > x.y.52.23: ICMP 10.3.64.72 udp port 10006 unreachable, length 36
        IP (tos 0xb8, ttl 62, id 26129, offset 0, flags [none], proto UDP (17), length 200)
    x.y.52.23.33530 > 10.3.64.72.10006: UDP, length 172

This issue just turned up on some brand-new 908Es. I'm using the same working config that I have been for some time on a number of other 908Es. Tried on SW v 10.6 thru 10.8 with no difference. Doesn't seem to matter if the 908's firewall is on or off. Nothing new or different on the network/switch side AFAIK.

So what stupid thing am I missing here?

Labels (1)
0 Kudos
1 Solution

Accepted Solutions
jjeffries
New Contributor II

Re: one way audio on calls to a 908e doing SIP -> PRI... 908 ICMP-rejects RTP?

Jump to solution

Ok, I figured this out. I had "ringback override 180" on the SIP trunk as I wasn't getting any ringback from the PBX when calling into it without that setting. When I took that out, two-way audio was restored. We'll deal with the ringback thing elsehow.

I would love to know *why* this happens.

View solution in original post

0 Kudos
5 Replies
jayh
Honored Contributor
Honored Contributor

Re: one way audio on calls to a 908e doing SIP -> PRI... 908 ICMP-rejects RTP?

Jump to solution

Assuming that x.y.52.23 is a public IP address it looks like a NAT traversal issue as the 908e is sourcing RTP from RFC1918 address 10.3.64.72.

Is there another device doing NAT between the 908e and the switch? 

Do you have media-gateway ip primary on the Internet-facing port of the 908e?

jjeffries
New Contributor II

Re: one way audio on calls to a 908e doing SIP -> PRI... 908 ICMP-rejects RTP?

Jump to solution

There is no NAT here; though "fake", that is a routable address on my network. I do have media-gateway ip primary on the switch-facing port.

Anonymous
Not applicable

Re: one way audio on calls to a 908e doing SIP -> PRI... 908 ICMP-rejects RTP?

Jump to solution

Try the R10.3.3 firmware.

Can you post your config?

jjeffries
New Contributor II

Re: one way audio on calls to a 908e doing SIP -> PRI... 908 ICMP-rejects RTP?

Jump to solution

Ok, I figured this out. I had "ringback override 180" on the SIP trunk as I wasn't getting any ringback from the PBX when calling into it without that setting. When I took that out, two-way audio was restored. We'll deal with the ringback thing elsehow.

I would love to know *why* this happens.

0 Kudos

Re: one way audio on calls to a 908e doing SIP -> PRI... 908 ICMP-rejects RTP?

Jump to solution

for people that come across this, i ran into the same issue and found the underlying real problem. when using the ringback override, the adtran switches the rtp stream between two ports, but it doesn't send proper sdp packets to indicate that and newer versions of asterisk ignore the sdp and thus don't talk to the correct port for the audio. sdp packets have a version (v=#) field and that is supposed to change when the sdp is giving new information. the adtran always presents v=0 and so asterisk ignores the sdp packet that switches back to the real audio stream. there is an asterisk setting (ignoresdpversion) that can supposedly get around this, but i haven't tested that. in my case i didn't actually need the ringback override, it was just left over from a copy/paste.

i don't know if adtran monitors these boards, but this is a bug that should be fixed.