[cisco-voip] Do you need CUBE over a private VPN between the 2 Cisco Clusters ( same company ) ?

Tue Feb 20 08:22:13 EST 2018

It’s not going to be a great experience unless both sides have their own local voice media termination. I’m assuming one side has the CUBE and one side would do the SIP trunk to the other side for PSTN needs? If so, media will have to traverse this tunnel too (unless the phone networks have a different route to the other side where CUBE is).

Your QoS strategy will be gone once traffic hit the tunnel, so if it’s congested that may be an issue. If the VPN isn’t setup correctly, you may have one-way audio off the bat; how easy is it for you to interface with the customer network teams for troubleshooting? “MTP Required” may be an option if you hit network/audio issue the customer can’t/won’t resolve but it isn’t a great solution.

If the trunk is just to enable site to site calling, have them use the PSTN (you could simulate site-to-site using the PSTN with translation and route patterns if necessary); it would be a better experience and the carrier is on the hook for call quality issues.

Having been down this path before; it’s possible but not usually an exceptionally great end user experience and you, as the implementation engineer, will be bruised along the way (so find a bus to sit under now).

Thanks,

Ryan

On Feb 20, 2018, at 02:33, Gary_Bates_Command_Solutions <gbates at commandsolutions.com.au<mailto:gbates at commandsolutions.com.au>> wrote:

Hi Cisco VOIP experts.

My client is part of NASA in Australia.
They want to have a SIP trunk linking their Oz cluster to their US cluster.
I understand the many functions of CUBE and what it does.
In this scenario there is a very secure VPN

So is it possible to run a SIP trunk between the 2 clusters without CUBE ?

Regards
Gary, Canberra

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Anthony Holloway
Sent: Friday, 9 February 2018 4:44 AM
To: Jonatan Quezada <jonatan.quezada at chemeketa.edu<mailto:jonatan.quezada at chemeketa.edu>>
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>; Fernando Fernandez Lopez <fferna12 at chemeketa.edu<mailto:fferna12 at chemeketa.edu>>
Subject: Re: [cisco-voip] one way audio after SIP cupover

The SIP Profile in CUCM does not apply to your CUBE, it applies to your CUCM as it's speaking to the CUBE.  Don't forget to reset the trunk after changing this, and be warned that all active calls would drop at that time.

Only configuration applied on the CLI of the CUBE will affect how CUBE behaves.

Thanks to a forum post by Brian Meade<https://supportforums.cisco.com/t5/ip-telephony/sip-udp-rtp-port-range/td-p/2423707>, I found out, that the way you limit/change the RTP port range on your gateway is:

voice service voip
 rtp-port range 20000 30000
!

However, that's global and not leg specific.

On Thu, Feb 8, 2018 at 9:02 AM Jonatan Quezada <jonatan.quezada at chemeketa.edu<mailto:jonatan.quezada at chemeketa.edu>> wrote:
I was able to see these calls with these port open, but I thought the cube has its own internal set 16384 to 32766 for the inside facing my cucm, and the outside set range, per centuryLink 20000 to 59999.  how can I make sure that the cube is obeying the range in the SIP profile I have on the trunk that lives on the cube?

<image001.png><image002.png>

i feels like the matching is not happening, But also the CUCM should be matching in and out on its own or automagically.
How can I verify that the sip profile and or trunk settings are configured to make sure this happens for each call?

On Tue, Feb 6, 2018 at 12:19 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:
You can use this tutorial to see what steps are being processed in the script, as well as what digits are being received if any.

https://supportforums.cisco.com/t5/collaboration-voice-and-video/uccx-viewing-executed-script-steps-via-cli/ta-p/3162231

If you don't know what DTMF methods you're using on the outside and inside of your network, then I would start by using the following command on your CUBE and inspect the output during an active call:

show call active voice | in PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD

On Tue, Feb 6, 2018 at 10:24 AM Jonatan Quezada <jonatan.quezada at chemeketa.edu<mailto:jonatan.quezada at chemeketa.edu>> wrote:
regarding the UCCX choking on calls, they are seeing more transfer drops than anything else. The other really bad part is, it seems that all of scripts are not registering the options when pressed it just drops the call. Is there more going on with the CTI ports, or rather an update to the configuration to handle the change in signalling from our provider?

where else can I look to make sure that the UCCX is processing the calls from the sip trunk correctly?

On Tue, Feb 6, 2018 at 6:57 AM, Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:
Good morning to you Mr. Holloway :)!

DTMF: Generally speaking, mis-matched DTMF methods, in my experience, presents with different symptoms than shown on that screenshot of the phone.

SIP ACL: Correct, only applies to signaling, and if blocked, would ultimately lead to a loss of RTP (but would then generally lead to the call being disconnected and in most cases, stop the call from even setting up. However, in a stressed CPU scenario (more common than you might think, ACL application can be delayed). This would lead into my question about how long the call was staying connected and what call flow that screen shot depicts (in or out). I assume an inbound call based on the OP using the word “caller”.

The reason I suggest adding media and signaling addresses into the sip ACL list is because some carriers will send signaling and media from the same address or pool of addresses. Just did one not too long ago like that.
Sent from my iPhone

On Feb 6, 2018, at 9:22 AM, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:
Ryan,

For what you said here:

"Your call doesn’t appear to have a need for MTP or Transcoding (G711 both sides and matching sample sizes); so I wouldn’t start there."

Don't forget that DTMF relay needs to match too, and this is something, in my opinion, that people miss-configure a lot!  In fact, I see people with h245 alpha on their SIP dial peers?  Like what?  Typically, the SIP ITSP will support RTP-NTE (RFC2833 [RFC 4733]) only, and your CUBE will need to inter-work that DTMF with an OOB DTMF relay, such as SIP NOTIFY.  But then your SIP Trunk Sec Prof will need to allow Unsolicited Notifications in order for that to work.  Also, some devices can support RTP-NTE, but usually your CTI based apps cannot.  E.g., UCCX

And for here:

"CUBE: ip trusted address list (make sure all provider signaling and media addresses are authorized or ip authentication is off (which I do not recommend) and make sure you include any CUCM addresses that are not used in dial peers)."

Since this feature is just for signaling, and the call does establish, this wouldn't be the cause of an RTP issue, and you wouldn't be putting your media addresses in here.

Do you agree with both of those remarks, or did I misunderstand something?

On Mon, Feb 5, 2018 at 5:14 PM Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:
Empirically, this “looks” like one way audio. How long will the call stay connected? Indefinitely? 30 seconds? 2 minutes?

Your call doesn’t appear to have a need for MTP or Transcoding (G711 both sides and matching sample sizes); so I wouldn’t start there.

Check these items and see what you find;

CUBE: ip trusted address list (make sure all provider signaling and media addresses are authorized or ip authentication is off (which I do not recommend) and make sure you include any CUCM addresses that are not used in dial peers).

CUBE: double check your media and signal bindings and make sure they are binding correctly. Are you globally binding or dial peer binding?

CUCM: verify the SIP trunk points to the CUBE interface that signaling is bound to (generally the same interface media would be bound to as well).

CUBE:
#logging buffered 10000000
#enable debug ccsip messages

Place a call and then look at the logs. Do you see any SIP error messages in the 4xx, 5xx (or more rare 6xx) range?

As a quick gut check, if you can, enable “MTP Required” on the CUCM SIP trunk facing the CUBE (and make sure it has access to an MRGL/MRG that uses a CUCM node for MTP) and reset the trunk and test a call. If this works, it likely means you’re facing a network path issue between the phone’s IP network and the network of the CUBE interface facing CUCM.

Outside of that, like Anthony said, it could be almost anything. A “sh run” or “sh tech” on the cube with a logging buffer from a ccsip messages during a failed call will generally get the ball rolling for most of us on this list in terms of offering targeted assistance.

Thanks,

Ryan

On Feb 5, 2018, at 2:37 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:
The fact that you received 2 packets is interesting.  Tells me that there is routing happening correctly...to some degree.

If you go to the web page of the phone and click on stream 1, does the far end IP address match your CUBE address?

Also, there's a lot of settings that need to be considered when implementing SIP, such as:

Early Offer and MTP usage
PRACK/Early Media
Offfer/Answer (Capabilities)
Interface Binding
Transport Protocol
OPTIONS Ping
Duplex Streaming
Midcall Signaling
Timers
etc.

Depending on your setting, a lot of different possibilities exist for why you might have the experience you have.  If you could paint a clearer picture of your scenario, that might help out.
On Fri, Feb 2, 2018 at 5:47 PM Jonatan Quezada <jonatan.quezada at chemeketa.edu<mailto:jonatan.quezada at chemeketa.edu>> wrote:
I get that this is usually routing but, is it also routing when the issue is intermittent?

our call flow is like so

CentLink(Provider) ----siptrunk30Meg-PPP(IQ-private)---Cube---CUCM10.5, uccx,unity

<image.png>

bonus facts, I have an operator who is in one of the two most affected buildings and she can recover the call after hold, resume,hold,resume sequence. then full rtp stream is there and she can hear and speak with caller.

are there SIP state change timers I can adjust, I want to tread lightly though because out of all of our outreachs seperated by a metro ethernet hub and spoke topology and almost 30 buildings here on main campus only 2 seem to be affected.

--
For immediate assistance please reach out to Chemeketa IT Help Desk at 5033997899<tel:(503)%20399-7899>
-or-
Visit the help center from your employee dashboard found here:
https://dashboard.chemeketa.edu/helpcenter/default.aspx

Johnny Q
Voice Technology Analyst - TelNet
Chemeketa Community College
Johnny.Q at chemeketa.edu<mailto:Johnny.Q at chemeketa.edu>
Building 22 Room 131
Work 5033995294<tel:(503)%20399-5294>
Mobile 9712182110<tel:(971)%20218-2110>
SIP 5035406686<tel:(503)%20540-6686>
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

--
For immediate assistance please reach out to Chemeketa IT Help Desk at 5033997899<tel:(503)%20399-7899>
-or-
Visit the help center from your employee dashboard found here:
https://dashboard.chemeketa.edu/helpcenter/default.aspx

Johnny Q
Voice Technology Analyst - TelNet
Chemeketa Community College
Johnny.Q at chemeketa.edu<mailto:Johnny.Q at chemeketa.edu>
Building 22 Room 131
Work 5033995294<tel:(503)%20399-5294>
Mobile 9712182110<tel:(971)%20218-2110>
SIP 5035406686<tel:(503)%20540-6686>

--
For immediate assistance please reach out to Chemeketa IT Help Desk at 5033997899<tel:(503)%20399-7899>
-or-
Visit the help center from your employee dashboard found here:
https://dashboard.chemeketa.edu/helpcenter/default.aspx

Johnny Q
Voice Technology Analyst - TelNet
Chemeketa Community College
Johnny.Q at chemeketa.edu<mailto:Johnny.Q at chemeketa.edu>
Building 22 Room 131
Work 5033995294<tel:(503)%20399-5294>
Mobile 9712182110<tel:(971)%20218-2110>
SIP 5035406686<tel:(503)%20540-6686>
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180220/3a7cad08/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 111924 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180220/3a7cad08/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 119136 bytes
Desc: image002.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180220/3a7cad08/attachment-0001.png>