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
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
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
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.
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
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