[cisco-voip] one way audio after SIP cupover

Tue Feb 6 11:57:41 EST 2018

If I configure MTP, globally on the sip profile, what impact would that
have on the CTI ports that the UCCX uses?

On Tue, Feb 6, 2018 at 8: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/20180206/5456f5b3/attachment.html>