No audio two ways - Access 916e (2nd Gen) / OS version A4.11.00.E

[rivera]

Device: Access 916e (2nd Gen)

AOS: A4.11.00.E

I am doing a new set up with a Access 916e (2nd Gen) and Metaswitch for some reason the call can be established but there is not audio both ways. I guess this may be a problem with the RTP. I did some research in forum and I found the command  "sh media-gateway" here is the output of that command:

sh media-gateway session 0/1.1

Session 0/1.1 (ACTIVE)
  slot 0, DSP 1, channel 1
  start time: 1:54 PM Wed, Jun 26, 2013, duration: 00:02:31
Local
  TDM description: FLORIDA CALL
  IP: 10.100.112.253, UDP port: 10000
Remote
  SIP description: T02
  IP: 96.47.150.10, UDP port: 29498
Vocoder: G.711 uLaw, VAD disabled, 2 frames per packet
Echo-cancellation enabled
Receive
0 rx packets, 0 rx bytes
  Jitter Buffer Stats:
  0 current depth (bytes), 0 highest depth (bytes)
  50 current delay (ms), 50 highest delay (ms)
  0 late arrival drops, 0 early arrival drops
  0 buffer full drops, 0 unknown packets
  0 flushed packets
  0x0000 0000 sync source
Transmit
  7512 tx packets, 1201920 tx bytes
  0x3536 1b14 sync source

As you can see the IAD is not receiving packets. My question is: there is another way to troubleshoot this case ?

Thanks in advance

Jean Louis

[jayh]

First thing I would do is move to more recent code.  A4.11.00 is getting long in the tooth.  R10.5.3 would be a good choice.

Debug sip stack messages and look at the SDP, ensure that the IP and ports match the other end.  compare with the INVITE from the Meta or SBC if you have access to them.

"media-gateway ip primary" configured on interface facing the Meta?

Device behind a NAT?

DSP involved - is this a PRI or analog port?  Other calls or other devices have good audio?

Sanitized config would help. 

[rivera]

Jayh:

My replies by points:

1- The AOS we are using is old but is the recommended one by the Adtran Technical Support Engineer to do SIP to PRI

2- The IP to the other end match the configuration

3-  media-gateway ip primary command is in the right interface

4- No NAT

5- This is a SIP to PRI / DSP involve is on my initial information: slot 0, DSP 1, channel 1 / This is a initial set up no other calls at this time

6- Config is very standard according to "Total Access 900_900e SIP Trunk Quick Configuration Guide"

Thanks

[jayh]

rivera wrote:

Device: Access 916e (2nd Gen)

AOS: A4.11.00.E

I am doing a new set up with a Access 916e (2nd Gen) and Metaswitch for some reason the call can be established but there is not audio both ways. I guess this may be a problem with the RTP. I did some research in forum and I found the command  "sh media-gateway" here is the output of that command:

Remote
  SIP description: T02
  IP: 96.47.150.10, UDP port: 29498
Vocoder: G.711 uLaw, VAD disabled, 2 frames per packet

As you can see the IAD is not receiving packets. My question is: there is another way to troubleshoot this case ?

Thanks in advance

Jean Louis

The 2 frames per packet may be the issue with A4.11.00

From R10.5.0 release notes:

• If an unsupported packetization period was presented to the ADTRAN unit in an SDP answer, no indication that the presented ptime was not supported by the ADTRAN unit was sent to the remote user agent. This resulted in no talk path.

You note in your reply, "The IP to the other end match the configuration".  What I was after was to have you look at the SDP in the SIP message debugs and ensure that the RTP media IP and ports matched and were reciprocal.

[jayh]

rivera wrote:

My replies by points:

...

4- No NAT

Local

  TDM description: FLORIDA CALL

  IP: 10.100.112.253, UDP port: 10000

Remote

  SIP description: T02

  IP: 96.47.150.10, UDP port: 29498

Your local IP10.100.112.253 isn't routable on the public Internet but the remote side appears to be a public IP, so it would appear that there is a NAT between the device and the Internet, or the local RTP source is incorrect.

[Anonymous]

Rivera,

I just wanted to check back in with you to see if you were able to determine the issue.  We would be glad to help troubleshoot further, but we likely need a complete debug and possibly a packet capture.  Feel free to respond on this thread if you have any further questions or updates.

Thanks!

David

[Anonymous]

Rivera,

I went ahead and flagged this post as "Assumed Answered".  If any of the responses on this thread assisted you, please mark them as Correct or Helpful as the case may be with the applicable buttons.  This will make them visible and help other members of the community find solutions more easily.  If you still need assistance, I would be more than happy to continue working with you on this - just let me know in a reply.

Thanks!

David

[rivera]

Thanks David, no more assistance needed. It was a configuration issue in the upstream provider.

If you have further questions please feel free to call us at the NOC number 877 244 0242 opt 1 or e-mail us at the NOC e-mail noc@usmetrotel.com<mailto:noc@usmetrotel.com>.

Jean Louis Rivera

US Metropolitan Telecom, LLC

24017 Production Circle

Bonita Springs, FL 34135

239-244-0242 ext. 559

jeanlouis.rivera@usmetrotel.com<mailto:jeanlouis.rivera@usmetrotel.com>