[cisco-voip] one way audio after SIP cupover

Thu Feb 8 10:02:27 EST 2018

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?

[image: Inline image 1][image: Inline image 2]

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> 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> 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> 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> 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> 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> 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> 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 <(503)%20399-7899>
>>>>> -or-
>>>>> Visit the help center from your employee dashboard found here:
>>>>> *https://dashboard.chemeketa.edu/helpcenter/default.aspx
>>>>> <https://dashboard.chemeketa.edu/helpcenter/default.aspx>*
>>>>>
>>>>>
>>>>> Johnny Q
>>>>> Voice Technology Analyst - TelNet
>>>>> Chemeketa Community College
>>>>> Johnny.Q at chemeketa.edu
>>>>> Building 22 Room 131
>>>>> Work 5033995294 <(503)%20399-5294>
>>>>> Mobile 9712182110 <(971)%20218-2110>
>>>>> SIP 5035406686 <(503)%20540-6686>
>>>>>
>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> 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 <(503)%20399-7899>
>> -or-
>> Visit the help center from your employee dashboard found here:
>> *https://dashboard.chemeketa.edu/helpcenter/default.aspx
>> <https://dashboard.chemeketa.edu/helpcenter/default.aspx>*
>>
>>
>> Johnny Q
>> Voice Technology Analyst - TelNet
>> Chemeketa Community College
>> Johnny.Q at chemeketa.edu
>> Building 22 Room 131
>> Work 5033995294 <(503)%20399-5294>
>> Mobile 9712182110 <(971)%20218-2110>
>> SIP 5035406686 <(503)%20540-6686>
>>
>

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

Johnny Q
Voice Technology Analyst - TelNet
Chemeketa Community College
Johnny.Q at chemeketa.edu
Building 22 Room 131
Work 5033995294
Mobile 9712182110
SIP 5035406686
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180208/d62c8e86/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 81853 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180208/d62c8e86/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 100405 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180208/d62c8e86/attachment-0001.png>