At least one of our locations reports clipping on external calls about 80% of the time. Some times pretty severe. We have CM 6.2; Sess Mngr 6.2; SBC 6.2; 9650 IP phones in that site and we use AT&T SIP for external calls. We have a core location/remote sites are on redundant WAN circuits. All external calls traverse the network from/to the core. Our vendor has recommended going to G711 on all calls and elimiate Wide-band in a trouble shooting step. Wire shark traces are hard to get because it is intermittent. We have also tried failing over to the backup WAN - issue persisted. All of this seem to start after we converted to SIP for external. Not getting complaints from other locations. As another troubleshooting step, they thought eliminating the SBC's communication with the remote site's network region and instead make their calls use the network region at the core. Thoughts?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Voice Clipping
- Thread starter demanding
- Start date
What kind of clipping? Does it sound like something silence suppression might be causing?
Depending on those characteristics, I might look at shuffling or tying down calls to a DSP to see if it still happens with those.
I'd also look at doing shuffling through early media to set up speech paths from the phones straight to the SBCs
And then you get into the nasty part of making sure you're doing your network regions right. You ought to be able to use wideband in the whole network except when using the trunks to AT&T who would be in another NR altogether and you can force G711 there.
Depending on those characteristics, I might look at shuffling or tying down calls to a DSP to see if it still happens with those.
I'd also look at doing shuffling through early media to set up speech paths from the phones straight to the SBCs
And then you get into the nasty part of making sure you're doing your network regions right. You ought to be able to use wideband in the whole network except when using the trunks to AT&T who would be in another NR altogether and you can force G711 there.
- Thread starter
- #3
It sounds like parts of words are missing...at times difficult to understand. Our vendor tried turning on early media and then other problems started for all offices...so we turned it off at the direction of Avaya. Are you saying that their local Gateway might be causing this (reference to DSP)?
I'm saying the local gateway (or other gateways) can be involved in the call without you wanting them to be and could be contributing.
I had something similar with core SIP trunks and voicemail. I found the audio was coming into the core, looping through the gateway at the site of the user that didn't answer, and that gateway was sending the RTP to AAM. You would expect the RTP to just be SBC-->AAM and not looping through a remote site.
That happened because we had an option on in coverage forwarding that left that call still tied to the station - Keep SBA at Principal or something.
For your case, assuming that QoS checks out, that you never have these problems calling between sites over the same WAN and only ever having it going out the SIP trunks, you'd want as detailed a flow of the media as you can. Your network region connectivity plays heavily into that.
Figuring out how to reproduce it reliably and tracing analog/digital/h323/sip and seeing if its all the same will probably point you in the right direction.
I had something similar with core SIP trunks and voicemail. I found the audio was coming into the core, looping through the gateway at the site of the user that didn't answer, and that gateway was sending the RTP to AAM. You would expect the RTP to just be SBC-->AAM and not looping through a remote site.
That happened because we had an option on in coverage forwarding that left that call still tied to the station - Keep SBA at Principal or something.
For your case, assuming that QoS checks out, that you never have these problems calling between sites over the same WAN and only ever having it going out the SIP trunks, you'd want as detailed a flow of the media as you can. Your network region connectivity plays heavily into that.
Figuring out how to reproduce it reliably and tracing analog/digital/h323/sip and seeing if its all the same will probably point you in the right direction.
ewaaijenberg
Technical User
You can try wireshark to see if the QoS settings are correctly added to the voicepackets. Most of the time this is a QoS issue.
Also on the G450 gateway there is an application where you can measure RTP streams. On page 378 of the following manual you can check how to configure and how to run reports
Also on the G450 gateway there is an application where you can measure RTP streams. On page 378 of the following manual you can check how to configure and how to run reports
- Status
Similar threads
- Locked
- Question