One way Audio issue

[seanm]

I have a customer utilizing a Nortel Norstar pbx and they started complaining of one way audio this week.  This particular customer has been up and working for several months with no issue, that is until this week.  One of our field techs was onsite with their vendor and tested the pri with his JDSU test set.  He made multiple calls using every channel individually.  When their vendor tested through the pbx he experienced the one way audio issue on channels 4, 7, 8, and 12 and claims it only happens when they have more than 3 calls up at the same time.  I have this configured for a full pri.  I am listing the voice portions of the config to ensure I am not over looking something.  As I stated, this has been up and working fine for months, so I am at a loss.  I initially wondered if someone may have been messing with the network configurations, but that has all been verified.  The DIA is configured for 5 Meg of bandwidth.  I also see some messages that periodically scroll across the screen.  I will list that below as well.

Error messages:

2009.07.07 11:30:05 TM.T02 01 IsdnTmStateIdling - clear trunk appearance

2009.07.07 11:30:07 TM.T02 01 IsdnTmStateIdling - clear trunk appearance

2009.07.07 11:30:31 TM.T02 01 IsdnTmStateIdling - clear trunk appearance

Voice config:

interface t1 0/3

  description 27/PRIV/0054964-01/IC/01

  lbo short 133

  tdm-group 1 timeslots 1-24 speed 64

  no shutdown

!

interface pri 1

  description pri 1

  isdn name-delivery setup

  connect t1 0/3 tdm-group 1

  role network b-channel-restarts disable

  no shutdown

voice trunk T01 type sip

  description "TO Safari C3"

  sip-server primary 74.131.0.34

  codec-group G711_uLaw

  default-ring-cadence internal

!

voice trunk T02 type isdn

  description "TO PBX - PRI 1"

  resource-selection linear ascending

  connect isdn-group 1

  rtp delay-mode adaptive

  codec-group G711_uLaw

!

voice trunk T03 type isdn

  description "TO PBX - PRI 2"

  resource-selection linear ascending

  connect isdn-group 2

  rtp delay-mode adaptive

  codec-group G711_uLaw

!

!

voice grouped-trunk NETWORK

  no description

  trunk T01

  accept $ cost 0

!

!

voice grouped-trunk PRI1

  description "27/PRIV/0054964-01/IC/01"

  trunk T02

(This is where I listed the Tn's)

Thanks,

Sean

[Anonymous · Accepted solution]

Seanm,

Thanks for posting!  This may be an issue that we need to work over the phone.  You can open a Technical Support ticket by calling 888-423-8276.  However, if you can duplicate the issue, I would first check the output of "debug sip stack messages" and "debug isdn L2-formatted" to see if anything appears different for the one-way audio call compared to normal calls.  Things to look for would include the SDP negotiated, which B channel was requested, etc.

If you do not see anything out of the ordinary with the call control, I would attempt to keep up a call with one-way audio and check the output of "show media-gateway session" to verify we have transmit and receive packets.  Below is an example of one of the channels that will be displayed with this command.

Session 0/1.1 (ACTIVE)

  slot 0, DSP 1, channel 1

  start time: 4:56 PM Wed, Apr 10, 2013, duration: 00:01:43

Local

  TDM description:

  IP: N/A, UDP port: 10000

Remote

  SIP description:

  IP: <removed>, UDP port: 20000

Vocoder: No Codec, VAD disabled, 2 frames per packet

Echo-cancellation enabled

Receive

5168 rx packets, 103360 rx bytes

  Jitter Buffer Stats:

  0 current depth (bytes), 6 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

  3 flushed packets

  0x0000 0000 sync source

Transmit

5167 tx packets, 103340 tx bytes

  0x068a 1bd4 sync source

You will have to look for the session associated with your call, which should be "ACTIVE".  You should see roughly equal numbers of transmit (tx) and receive (rx) packets, which verifies RTP is being sent and received.  If this all looks fine, then we usually attempt to get a DSP capture of a call to verify the audio within the RTP packets.  This process is outlined in How to Perform a DSP Capture.

Lastly, you may want to verify with "show version" that the unit is running at least A4.11.00 or that the unit is running firmware from the new R10 series.  These are our recommended firmware versions at this time.

Thanks!

David

[Anonymous]

You might need to do a packet capture at each hop until you find out where the audio is dropping.  You may also want to check for any firewall changes or routing issues with the service provider.  In some of our cases we have had to work with our SIP service provider to route the RTP traffic properly to overcome issues like this.  A packet capture with Wireshark helped us eliminate certain parts of the network.

[Anonymous]

Seanm,

I just wanted to check back in with you on this issue.  Were you able to resolve the issue?  Feel free to respond on this post if we can be of further assistance.

Thanks!

David

[Anonymous]

Seanm,

I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post and unmark it and select another in its place with the applicable buttons.  If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.

Thanks,

David