Ask the Experts: Configuring and Troubleshooting Cisco SIP CUBE/Gateways and MGCP Gateways

[ciscomoderator]

With Edson Pineiro

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about configuring and troubleshooting Cisco session initiation protocol (SIP) Cisco Unified Border Element (CUBE)/Gateways and Media Gateway Control Protocol (MGCP) Gateways with Cisco expert Edson Pineiro. Learn about the different types of  various aspects of call signaling methods, requests, response SIP exchange and behaviors and why secure device provisioning (SDP) is important. You'll also learn about common issues when troubleshooting call manager MGCP registration, digital signal processors, foreign exchange subscriber interface (FXS), foreign exchange office (FXO), Integrated Services Digital Network (ISDN) Primary Rate Interface (PRI), integration with service providers and Q signaling (QSIG) Private Branch Exchanges (PBX).

Edson Pineiro is a senior customer support engineer in the Cisco Technical Assistance Center in Sydney. His current role includes configuring, troubleshooting, and designing gateways, gatekeepers, Cisco Unified Border Element Enterprise Edition, and Cisco Unified Call Manager using his deep knowledge of signaling protocols such as SIP, H.323, MGCP, SKINNY, and others. He has been involved in several bug fixes, escalations, and critical account cases from around the globe. He has over seven years of experience in the IP voice industry.

Remember to use the rating system to let Edson know if you have received an adequate response.

Edson might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Collaboration Voice, & Video IP Telephony subcommunity shortly after the event.This event lasts through Friday April 19, 2013. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.

[shiblyibrahim]

Hey Edson,

I can understand CUBE is required but is their a possiblity to configure SIP in CUCM without CUBE?

We have 2 kinds of SIP trunks - Credential based and IP authenticated based.

[Edson Pineiro]

Hello Mohamed,

   Thank you for your question.

   I understand your questions is in regards to SIP user agent client (UAC) authentication with a user agent server (UAS). Your scenario is in regards to a service provider challenging the request INVITE from the CUCM with a 401 Unautherized to authenticate a specified credential. In this case the UAC is the request originator on Cisco unified Communications manager (CUCM) and the UAS is the responding challenger (Telco). Your currently using the Cisco Border Element to authenticate calls, however would like to verify if this feature is available on Cisco Unified Communications Manager.

   Please be advised that CUCM has the ability to match the realm of the UAS when challenged with a SIP 401. The UCM matches the telco's realm to a specified credential. The realm can be found by reviewing the SIP 401 Unautherized WWW-Authenticate header. The WWW-Authenticate line will contain a "realm="" header. The realm will be matched when the CUCM responds to the challenge. In the following scenario, the CUCM will send a REINVITE including the username and password for edson when matching the cisco.com realm (realm="cisco.com") contained in the SIP 401. Please see the following print screens:

401 Unautherized header:

!

Received: 

SIP/2.0 401 Unauthorized

WWW-Authenticate: DIGEST qop="auth",nonce="",realm="cisco.com",algorithm=MD5

!

CUCM Realm Print screen:

   Please be advised that in certain scenarios SIP trunks directly to the carrier may work, however the CUBE provides many features such as MMOH to Unicast streaming and much more that assist with interpretability.

   For your reference please review the following configuration guide:

SIP Realm Configuration Settings:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/security/8_0_1/secugd/secrealm.html#wp1070376

   Please let me know if you have any further question.

Thank you

&

Best Regards,

Edson Pineiro

CISCO

[Anthony Holloway]

MGCP

Does the command mgcp dtmf-relay voip codec all mode out-of-band actually prevent RTP-NTE negotiations?  I am seeing on my VG224 gateway, which has this command, that RTP-NTE is always used.  Codec is G711.

MGCP

When the MGCP gateway negoatiates/agrees upon RTP-NTE DTMF relay, why does it still send MGCP commands to the Call Agent in addition to sending the RTP-NTE to the other end point?

MGCP

Why isn't the fm package documented at the following link?  Document defect, or other reason?

http://www.cisco.com/en/US/docs/ios/voice/command/reference/vr_m1.html#wp1439734

SIP

Is the mode border-element command recommended for every CUBE deployment, or does Cisco recommend only using this command when necessary?  The command itself would imply this is how you turn the VGW into CUBE, but that appears to be the job of the allow-connections sip to sip.

SIP

Should CUBE manage its own DSP's and Software MTP's or should you register them to CUCM and let CUCM allocate as needed?  What's best practice here?  Also, having CUBE manage them requires the mode border-element command, correct?

SIP

What are a few reasons customers would switch from UDP to TCP?

SIP

What are some typical timers to look at decreasing or increasing as part of a best practice?

E.g.,

http://www.cisco.com/en/US/docs/ios/voice/command/reference/vr_t2.html#wp1642484

SIP

In the command: dtmf-relay sip-notify rtp-nte digit-drop, is the digit-drop part saying that the gateway will drop DTMF tones from within the audio stream, or just the RTP-NTE's?  Or something completely different?

And lastly, I would echo what Mohamed Ibrhim asked.

Thank you for your time with this community and answering our questions!

[Edson Pineiro]

Hello Anthony,

   Thank you for all your questions. Please find my response inline to each of your questions:

MGCP

Does the command mgcp dtmf-relay voip codec all mode out-of-band actually prevent RTP-NTE negotiations?  I am seeing on my VG224 gateway, which has this command, that RTP-NTE is always used.  Codec is G711.

   Please be advised the dtmf relay out-of-band (OOB) transmits the DTMF digit using an MGCP request notify signalling message. The mgcp request notify (RQNT) can be seen when reviewing the output of debug mgcp packet. If your preference is rtp-nte (RFC2833), then you should enable either the mgcp dtmf relay nte-ca or nte-gw. Depending on the dtmf negotiation on the CUCM and the far end will depend whether or not the mgcp gateway fails or negotiates a DTMF relay. In certain scenarios when both call legs on a CUCM negotiate different DTMF relays, for example H245-Alphanumeric (call-leg_1) to RTP-NTE (call-leg_2) the CUCM may invoke an MTP reference to convert the RTP-NTE embedded in the RTP packet header to H245-Alphanumeric (OOB) relay.

   For your reference please review the following voice command reference for mgcp dtmf-relay:

MGCP dtmf-relay:

http://www.cisco.com/en/US/docs/ios/12_3/vvf_r/vrg_m1_ps1839_TSD_Products_Command_Reference_Chapter.html#wp1022347

MGCP

When the MGCP gateway negoatiates/agrees upon RTP-NTE DTMF relay, why does it still send MGCP commands to the Call Agent in addition to sending the RTP-NTE to the other end point?

   I have seen in certain scenarios were two dtmf-relays are negotiated for the same call i.e. OOB and RFC2833. Certain customers require both for redundancy in heavily SIP networked environments, however not recommended and an MTP reference is usually a good fix to convert the signal if RFC2833 is needed and your endpoint only support OOB. In this scenario you will see both RFC2833 and out of band DTMF digits sent to the far end using RQNT. I have also seen in other scenarios were the mgcp gateway simply sends a notify message to keep the CUCM (Call Agent) aware of the digit being pressed even though RFC2833 is negotiated. However depending on what is actually seen in the debugging and configuration will depend if this is a configuration issue something else.

   Can you please advise what mgcp request or event that occurs when you see both the rfc2833 and the OOB mgcp dtmf signalling?

   Can you please share a "show mgcp" and the following debugs when reproducing the issue?

!

debug mgcp packet

debug voip rtp session named-event

!

MGCP

Why isn't the fm package documented at the following link?  Document defect, or other reason?

http://www.cisco.com/en/US/docs/ios/voice/command/reference/vr_m1.html#wp1439734

   The use of the FM Package is referenced in the Cisco Unified Communications Manager SRND, please see the following document. It maybe that the document team prefer not to duplicate all the references. However I will submit a document bug to review the voice command reference. Thank you for pointing out the document.

DTMF Relay

MGCP Gateway:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/gateways.html#wp1044091

SIP

Is the mode border-element command recommended for every CUBE deployment, or does Cisco recommend only using this command when necessary?  The command itself would imply this is how you turn the VGW into CUBE, but that appears to be the job of the allow-connections sip to sip.

   Your are correct the basic function of the CUBE is to simply allow connections sip to sip. However the "mode border-element" command enables enhanced cube features such as "media transacting high density" etc.

   For your reference please review the following documents:

Cisco Unified Border Element Configuration Guide:

IP-to-IP Gateway: SIP-to-SIP Basic Functionality:

http://www.cisco.com/en/US/docs/ios/voice/cube/configuration/guide/vb_6788_ps5640_TSD_Products_Configuration_Guide_Chapter.html

Cisco Voice Command Reference:

mode border-element:

http://www.cisco.com/en/US/docs/ios/voice/command/reference/vr_m3.html#wp1396382

SIP

Should CUBE manage its own DSP's and Software MTP's or should you register them to CUCM and let CUCM allocate as needed?  What's best practice here?  Also, having CUBE manage them requires the mode border-element command, correct?

   Good question. It depends on your design and the features supported on the 3rd party carrier or SIP endpoint that your integrating with. For example in certain circumstances, if the carrier did not support RFC2833 for a specific 1800 number however accepts the digits using in-band audible DTMF tones and your internal network required a DTMF relay such as RFC2833. Then you can manage this issue by registering a CUBE transcoder to convert the RFC2833 signal to an in-band DTMF audible tone. On the other hand in certain circumstances CUCM allocates an MTP resource to manage different codecs or supplementary services such as supervised transfers, MMOH or conference.

   A basic CUBE MTP does not require "mode border-element" however if you need an enhance transcoder you may enable "mode border-element" for high density transcoding. For your reference please review the following reference:

Support for Software Media Termination Point:

http://www.cisco.com/en/US/docs/ios-xml/ios/voice/cube_proto/configuration/15-mt/voi-suppt-smtp.html

   In an ideal situation were there are no integration issues, MTP or transcoders would not be required on a CUBE. The best practice would be to avoid using MTP resources towards a CUBE unless it's a must have for interoperability and integration design.

SIP

What are a few reasons customers would switch from UDP to TCP?

   In certain instances the TCP buffer becomes full and will not accept new TCP sessions unless they are cleared. This maybe caused by Stale TCP sessions when SIP OPTIONS is enabled. In this scenario UDP would be the solution since it is not connection oriented and does not need specific exchange to clear to tear down the connection when compared to TCP. I have seen TCP issues before when the SIP TCP packet is double natted before a firewall and specific TCP timers need adjusting. I have also seen in the TCP hand shake failures when a SIP request is initiated causing the calls to fail. However these issue would not happen when using UDP.

SIP

What are some typical timers to look at decreasing or increasing as part of a best practice?

E.g.,

http://www.cisco.com/en/US/docs/ios/voice/command/reference/vr_t2.html#wp1642484

   Generally the SIP timers do not need much adjusting unless your looking for a specific feature. This would not be the same when compared to h323, in h.323, h225 Setup timers always need adjusting. However SIP is a very intelligent signalling protocol and supports different transport methods and other SIP exchanges that restarts the timers during a call.

   With regards to Design, I've had the need to adjust the timer buffer-invite when using calling name display on ISDN Gateways. Basically the buffer allows enough time for the gateway to collect the details from the ISDN network before initiating the Invite towards the IP network. In this case calling name arrived in a facility message after the ISDN setup, so it needed a little more time.

SIP

In the command: dtmf-relay sip-notify rtp-nte digit-drop, is the digit-drop part saying that the gateway will drop DTMF tones from within the audio stream, or just the RTP-NTE's?  Or something completely different?

   Correct, the command "dtmf-relay digit drop" will drop the in-band audible digit and forward only the rtp-nte signal towards the IP network. However please be advised that all 3 dtmf-relays specified in your command string are 3 totally separate DTMF relays. Each will be used based on the negotiated DTMF relay during the SIP SDP capabilities exchange.

   For your reference please see the following command reference:

Cisco IOS Voice Command Reference:

dtmf-relay (Voice over IP):

http://www.cisco.com/en/US/docs/ios/voice/command/reference/vr_d2.html#wp1449003

   Please let me know if you have any further question.

Thank you

&

Best Regards,

Edson Pineiro

CISCO

[Ayodeji Okanlawon]

Edson,

Can you please enumerate on the transport protocol to use for SIP. I read a few benefits of using UDP over TCP from your answer to Anthony. Can you substatiate further on when its best to use one over the other. I have spoken to a few Cisco folks who advised to use TCP in your internal network and then use UDP to ITSP becaus emost of them prefer UDP...What are the advantages of UDP over TCP and vice versa and when should one be used over the other

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Edson Pineiro]

Hello Aokanlawon,

   In the basic scenario TCP or UDP will be sufficient depending on the support transport method used by both devices besides the CUBE, for example:

PSTN --- UDP ---- CUBE ---- TCP --- CUCM ---- Phone

or

3rd Party SIP endpoint ---- UDP ---- CUBE ---- TCP ---- CUCM --- Phone

   It really depends on the supported transport method used by the SIP end point. CUBE and Call manager can do either TCP, UDP, TLS etc.

   In a CVP SIP proxy controlled environment or in a scenario were multiple SIP trunks need link monitoring using out of dialog (OOD) Option Ping. If TCP was the transport method the router will be build multiple TCP sessions based on the amount of SIP dial-peers and the OOD Options Ping timer configured on the CUBE. For example in a scenario were the CUBE has multiple dial-peers each configured with OOD Options Ping to monitor the state of the dial-peer when the link to the session target drops towards different SIP endpoints call would busy-out or route to the next dial-peer. You can imaging the amount of TCP session remaining open if the TCP socket was not closed with a TCP FIN by the far end SIP endpoint. Each TCP session that does not close or partially close would cause stale TCP sessions, this also includes calls that do not completely clear such as stale sip sessions. The tcp timers may be adjusted however when the TCP buffer becomes saturated with stale TCP sessions, any new SIP request will fail to initiate a TCP request for basic calls, until the TCP buffer is cleared. At this stage a router reload will help, however the reload is not a solution. For your reference a typical call flow that needs this consideration maybe described in the following diagrams:

SIP Trunk Monitoring with CUSP+CUBE OOD Options Ping:

OR

OR

   For further details regarding OOD Options Ping please see following reference:

Cisco UBE Support for generating Out-of-dialog SIP OPTIONS Ping messages to monitor SIP:

http://www.cisco.com/en/US/docs/ios/voice/cube/configuration/guide/vb_9321.html

   Thank you for providing good questions.

   If you have any further questions please let me know.

Thank you

&

Best Regards

Edson Pineiro

CISCO

[Ayodeji Okanlawon]

Thank you for the excellent answer! Looks like OOD options Ping is a big factor for choosing a sip transport protocol.

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Anthony Holloway]

Hi Edson,

Thank you for taking the time to answer all of my questions so thoroughly.  I have read through your reply, and will need to spend more time referring to the resources you linked me to, in an effort to fully understand the responses.

In the mean time, I do have two immediate follow up items for you.

1. In response to your reply to my question:

MGCP
Does the command mgcp dtmf-relay voip codec all mode out-of-band actually prevent RTP-NTE negotiations?  I am seeing on my VG224 gateway, which has this command, that RTP-NTE is always used.  Codec is G711.

I feel like you gave me a great explanation of how it should work, but I would like to clarify the question I was asking, as I am seeing what appears like the command not working.

Why would I see the gateway always negotiating RTP-NTE when I have specifically told it to use OOB for all Codecs?

I do see there is another MGCP command, which I cannot configure DTMF realy for, that might explain why I see RTP-NTE all the time:

CUBE#show mgcp | in voAAL2
MGCP dtmf-relay for voAAL2 is SDP controlled

The SDP's in my environment are almost always going to show RTP-NTE as the DTMF relay method.

Thoughts?  I can provide captures if necessary, as you had asked for a different question I had.  Let me know.

2.  In your reply to Mohamed you stated the following:

...the CUBE provides many features such as MMOH to Unicast streaming...

When deploying a few sites using local CUBE's and MMOH, MOH was not working to the PSTN phones, and our deployment team came to the conclusion that this simply would not work.  Therefore we now burn bandwith from the centralized MOH servers to each site using unitcast.  Any additional information and links you could provide would be great.

Thank you.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[Edson Pineiro · Accepted solution]

Hello Anthony,

   Thank you for the follow up questions. Please find my response inline to your questions prepended by :

1. In response to your reply to my question:

MGCP

Does the command mgcp dtmf-relay voip codec all mode out-of-band actually prevent RTP-NTE negotiations?  I am seeing on my VG224 gateway, which has this command, that RTP-NTE is always used.  Codec is G711.

I feel like you gave me a great explanation of how it should work, but I would like to clarify the question I was asking, as I am seeing what appears like the command not working.

Why would I see the gateway always negotiating RTP-NTE when I have specifically told it to use OOB for all Codecs?

I do see there is another MGCP command, which I cannot configure DTMF realy for, that might explain why I see RTP-NTE all the time:

CUBE#show mgcp | in voAAL2

MGCP dtmf-relay for voAAL2 is SDP controlled

The SDP's in my environment are almost always going to show RTP-NTE as the DTMF relay method.

Thoughts?  I can provide captures if necessary, as you had asked for a different question I had.  Let me know.

   Firstly I would like to clear your query regarding voaal2 or voice over atm adaptation layer 2. There are 3 main types of voice over networks, for example: Voice Over Frame-relay (VoFR), Voice Over ATM (VoATM) and Voice Over IP (VOIP). In this case mgcp gateways also support voice over ATM AAL2. To be honest VoFR and VoATM are legacy voice over layer 3 protocols which are rarely used in this day and age.

  For further details regarding Voaal2 on mgcp gateways, please reference the following documents:

MGCP Gateways using Voice over ATM AAL2:

http://www.cisco.com/en/US/docs/ios-xml/ios/voice/mgcp/configuration/12-4t/vm-cas-pbx-aal2-pvc.html#GUID-DD7A9496-D312-4DA4-9A1E-44AD4CDDAFEE

   The reason why the gateway may use rtp-nte when configured with OOB for all codecs, maybe a few things however without verifying the mgcp debugging messages I cannot confirm. Another possibility can be since mgcp has a client to server base relationship between its endpoints. The client in this case would be the mgcp gateway, and server is the unified communications manager. It maybe possible that the Call Agent Server is requesting the mgcp gateway to send rtp-nte, due to the other call agent call leg even though the mgcp client responds with OOB capability within the create connection (CRXC) modify connection (MDCX) and 200-ok request and response. This is the main reason why I asked for the following:

!

debug mgcp packet

debug vpm signal

debug voip rtp session named-event

!

   Also sometimes mgcp gateways become out of sync with there call-agents, a ccm-manager config force download and mgcp reset on both the gateway and the CUCM can help these type of situations. If you like please apply the following before collecting the debugs and test again:

!

!!!!### Reset the mgcp gateway on call-manager

!

no mgcp

!

!!!!###Wait for the mgcp process to stop

!

!

no ccm-manager config

!

!!!### Wait a minute

!

ccm-manager config

!

!!!###Wait

!

!!!!###Collect debugs and test

!

   After applying the above, please ensure the output from the show ccm-manager shows that the download is complete and the configuration is set to the same number as the download attempt. It should look like so:

!

Configuration Auto-Download Information

=======================================

No configurations downloaded

Current state: Waiting for commands

Configuration Download statistics:

        Download Attempted             : 1

          Download Successful          : 1

          Download Failed              : 0

        Configuration Attempted        : 1

          Configuration Successful     : 1

          Configuration Failed(Parsing): 0

          Configuration Failed(config) : 0

!

2.  In your reply to Mohamed you stated the following:

...the CUBE provides many features such as MMOH to Unicast streaming...

When deploying a few sites using local CUBE's and MMOH, MOH was not working to the PSTN phones, and our deployment team came to the conclusion that this simply would not work.  Therefore we now burn bandwith from the centralized MOH servers to each site using unitcast.  Any additional information and links you could provide would be great.

   Multicast Music-on-Hold is now supported on CUBE and is a new feature. As per my previous note it basically converts the Multicast RTP stream into a unicast media stream sent out towards the other call leg. However the prerequisite is IOS version 15.2(1)T or above. For a configuration reference please review the following document:

Multicast Music-on-Hold Support on Cisco UBE:

http://www.cisco.com/en/US/docs/ios-xml/ios/voice/cube_proto/configuration/15-mt/voi-multicast-moh.html

   Thank you for all your questions, please keep it up!

   If you have any further queries regarding any of my points, please let me know.

Thank you

&

Best Regards,

Edson Pineiro

CISCO

[Daniele Giordano]

Hi Edson, I've a strange issue and any suggestion is appreciated.

I've used three AS5400HPX in two ways:
-  H.323 gateway

- MGCP gateway controlled by Cisco PGW 9.8(1) (current scenario)

I've loaded different IOS during years (now 12.4(15)T) but in all these environments I had always same SPE version (np.0.10.9.0.spe) and same two issues:

1) sporadic CROSSTALK

2) sporadic ONE-WAY AUDIO

For the first, CROSSTALK, I found these informations on Cisco Bug Toolkit:

- CSCea16527 Terminated (Unreproducible)

- CSCtk34885 Fixed (Resolved)  with "voice service voip - sip - source filter" command. The above command only works for SIP, so H323, MGCP, and SCCP are still affected.

- CSCtw73602 Fixed whit command "voice service voip - sip - source filte"

- CSCtq47019 work in progress, maybe - support on H.323, SCCP, and MGCP . This will allow the command to be used in all VoIP environments

Now, I suppose that this problem is a "well know" question.

And also, Cisco AS5400 is widely used with Cisco PGW 2200 Softswitch. In this scenario (like mine) the gateway is controlled via MGCP.

So, can you give me informations about the Cisco bug ID CSCtq47019 ? Unfortunatly it's not shown in bug tool kit.

Do you know a workaround for MGCP?

The second problem, ONE-WAY AUDIO, is very interesting.

In some calls my customers have one-way audio.

This problem is present only during incoming calls.
I've no NAT and IP routing is ok.
I've no codec negotiation problem.
The problem is indipended by customer CPEs. Is present with different devices: Cisco ATA18x SIP, Linksys SPA2102, Cisco SRP520, Cisco SPA122,  Linksys SPA8000, Linksys WRP400, etc.

I've captured problematic calls with wireshark.

In every case I've notice two RTP flows, one from AS5400 to customer CPE and one in the opposite direction. 
RTP stream from the CPE to AS5400 is correct (in wireshark you can listen the audio), but the RTP from AS5400 doesn't contain voice (wireshark plays only silence).

I've saved the audio trace and I've amplified the volume with Audacity.
After this manipulation you can hear a distorted voice.

In summary:

- after many years I've changed 3 TDM provider without fix problems

- the problem regards about 1% of incoming calls

- the audio issue is always in the call leg from TDM to IP side

- we observed this strange issue on all AS5400HPX gateway (3 different gateway with different IP address and bought in different period)

- IOS indipendent

- a bidirectional RTP flow is always estabilished

- the problematic RTP flow from TDM to IP have always the same volume level: -30,4 dBm (checked with show port operational-status)

- the wireshark audio trace shows only noise but if I increase the volume I can hear the voice

- it happens on different DSP slot (checked with show port operational-status)

So the problem is in the AS5400. Can be a DSP bug?

Do you have any suggestions?

Thank you and Best Regards.

[Edson Pineiro]

Hello Daniele.

   Thank you for your question. Please review my answers in the following points:

1. Sporadic CROSSTALK:

- You are correct, filtering RTP traffic by matching the source port will resolve most cross talk issue when the remote side transmits parallel RTP streams to the same destination RTP port used by other calls. At the moment the RTP source filter is only available on SIP endpoints. Hence a TAC engineer opened an enhancement defect tracked in CSCtq47019 - "Feature Request: IOS RTP stack should do source IP/port validation".  If you believe the issue is purely related to this feature request, can you please confirmed if the symptom remains the same after moving to SIP and applying the RTP source filter?

2) sporadic ONE-WAY AUDIO

- In my 7 years experience I have dealt with several different types of one way audio issues. According to your problem statement, as per the packet capture the RTP stream sourced from the TDM port towards the IP (TDM to IP) contains a stream with  audio levels at -30dBm. This problem has also remained the same after moving to different service providers.

   To troubleshoot these types of issues I recommend to collect a PCM capture from the DSP. The PCM capture collects 3 audio streams, one before DSP processing and another after DSP processing on PVDM version 2 (PVDM2) and above.

   In certain circumstances the customer may use Next Port DSP's were this is not possible. The options in this scenario would be collect a packet capture to isolate the issue, then use a T1/E1 analyser to collect the audio traffic from the B channel between the carrier and the AS5400. Obviously the packet capture will isolate the issue towards a specific gateway and the T1/E1 analyser will isolate the issue on the carrier or the port.

   Either way if you have PVDM2's then the PCM capture will be the best option. I have a GL Communications T1/E1 analyser on my desk, works perfectly when recreating intermittent issues and in the past I have asked carriers to also analyse E1/T1 B channels for certain customers. However a PCM capture will do a better job as it provides usable data and DSP tracing. Once you have the PCM capture please upload it and I will extract the audio streams for you. Well, until the issue is captured we will never know the root cause.

   For further details regarding PCM capture please reference the following document:

Pulse Code Modulation Audio Capture:

http://www.cisco.com/en/US/partner/docs/ios-xml/ios/voice/cube_mgmt/configuration/15-2mt/voi-pcm.html

How to enable PCM Capture:

https://supportforums.cisco.com/docs/DOC-14060

   If you have any further questions please let me know.

Thank you

&

Regards,

Edson Pineiro

CISCO

[Daniele Giordano]

Hi Edson, a very helpful suggestion.

In the past year I tested one of the my AS5400HPX in our lab with H.323, MGCP and SIP scenarios. I confirm crosstalk in H.323 and MGCP. In SIP, with "voice service voip - sip - source filter" command, I was not able to replicate the problem. So, YES. I think that "source IP/port validation" fixed it.

For one-way issue, unfortunatly, my AS use NextPort DSP and so I can't run a PCM capture directly on the gateway. For this reason I changed PSTN provider three times whitout solved my problem. I also tried a capture with E1 analyzer direct on TDM leg (RAD equipment). In this case the incoming audio on B channel was good but the audio on RTP stream was muted in one direction.

Can you suggest me how to proceed in debug?

I've a new questions.

Sometimes the AS5400 starts an RTP stream with 1 single packet in G.711ulaw while the rest of the stream uses the negotiated codec. Why?

Is there a way to reload a voice gateway only when there aren't active calls?

An "idle reset"?

Thank you and Best Regards.

[Edson Pineiro]

Hello Daniele

   Thank you for you questions.

   With regards to the NextPort DSP debugging. The NextPort DSP software support has expired as of the 31st of March 2011, according to the AS5400XM Eol document. Please see the following reference:

End-of-Sale and End-of-Life Announcement for the Cisco AS5400XM and AS5350XM:

http://www.cisco.com/en/US/prod/collateral/iad/ps505/end_of_life_notice_c51-556594.html

   With regards to the AS5400HPX. The device has been end of life since December 2008. Please reference the following link:

EoL/EoS for the Cisco AS5400HPX:

http://www.cisco.com/en/US/prod/collateral/iad/ps505/ps507/prod_end-of-life_notice0900aecd804c6e98.html

   For your reference the debugging needed to troubleshoot NextPort on an MGCP gateway would be the following. However since there is no Software support from our developers I cannot log an issue for you with our DE teams to find a DSP fix.

!

debug nextport spe api

debug nextport ssm detail

debug nextport vpd error

debug nextport vsmgr detail

debug mgcp packet

debug mgcp error

debug mgcp state

debug mgcp event

debug voip vtsp all                                                   

debug voip dspapi all

debug voip dsmp all

debug voip dsm all

debug voip ccapi all

debug voip rtp packet

debug voip rtp session

debug voip rtp error

!

   During the time that the issue occurs you may collect the following show output:

!

show voice dsmp stream

show voice vtsp call fsm

show voice call summary

show spe

!

   With regards to call idle reloads. In the past I have worked on TCL scripting and EEM scripts to provide similar functionality to collect debugs and captures on a router. However I have not written a script to reload a router during call idle times. For further references on Embedded Event Manager please reference the following links. With regards to custom TCL scripts and certain EEM scripts, please open a case with our Cisco Development team. For your reference please see the following documents:

EEM Configuration for Cisco Integrated Service Router Platforms:

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6815/config_guide_eem_configuration_for_cisco_integrated_services_router_platforms.html

Cisco IOS Embedded Event Manager (EEM):

http://www.cisco.com/en/US/products/ps6815/products_ios_protocol_group_home.html

Cisco Developers:

www.cisco.com/go/developers

   To get you started I quickly created the following EEM script that will issue the command reload every night at 2 am:

!

event manager applet night-timereload

event timer cron name night-timereload cron-entry  "0 2 * * *"

action 0.8 cli command "enable"

action 0.9 cli command "reload"

action 1.1 cli command " "

action 1.2 cli command " "

!

   If you have any further questions please let me know.

Thank you

&

Regards,

Edson Pineiro

CISCO

[black.robber]

hi everyone is there any one would like to help me

i got following situation

how to share router one fastethernet port (e.g fa0/0) with different network addresses(e.g 192.168.1.1 and 192.168.2.1 and 192.168.3.1) when using them as a gateway using RIP or static routing?

any one please help me..