mmetry is disabled so CUBE is
> not passing the received dynamic PT through to the next-hop dial-peer - we
> have symmetry on both call legs for our NTE PT.
>
>
>
> Note that CUBE has no issues receiving one dynamic PT for NTE and sending
> another (ex: receiving PT 100 and transmitting 1
CM but enabled to
>>>>>>> ATT, we would receive 100 PT from ATT, send 101 to CUCM, receive 101
>>>>>>> from
>>>>>>> CUCM, and send 101 to ATT. The resulting PTs would be symmetrical
>>>>>>> between
>
oad disabled on both call-legs using
>> the same call flow. CUBE receives PT of 100 from ATT -- the outbound
>> dialpeer has asymmetry disabled, so it transmits the PT specified for that
>> dial-peer (default 101 or any hardcoded dynamic PT) to CUCM. We then
>> receive 101 fr
CUBE is
> not passing the received dynamic PT through to the next-hop dial-peer - we
> have symmetry on both call legs for our NTE PT.
>
>
>
> Note that CUBE has no issues receiving one dynamic PT for NTE and sending
> another (ex: receiving PT 100 and transmitting 101 for RTP-NTE) on
8, 2016 3:10 PM To: Cisco VOIP <cisco-voip@puck.nether.net>
Subject: [cisco-voip] DTMF interworking on CUBE - asymmetric payloads I'm
trying to get my head wrapped around some DTMF interworking features... I
have this setup: UCM -- CUBE --- 3rd party system F
>> *Let’s change it up a bit… A second example.*
>>>>>>>
>>>>>>> If asymmetry was disabled on the dial-peer to CUCM but enabled to
>>>>>>> ATT, we would receive 100 PT from ATT, send 101 to CUCM, receive 101
>>>>>>> from
>>>>&
;>>>>> CUCM, and send 101 to ATT. The resulting PTs would be symmetrical between
>>>>>> CUBE and CUCM, but asymmetrical between CUBE and ATT.
>>>>>>
>>>>>>
>>>>>>
>>>>>> See screenshot below for a third example:
>
;
>>>>> See screenshot below for a third example:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This example shows asymmetric payload disabled on both call-legs using
>>>>> the same call flow. CUBE receiv
screenshot below for a third example:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This example shows asymmetric payload disabled on both call-legs using
>>>>> the same call flow. CUBE receives PT of 100 from ATT --
dial-peer (default 101 or any hardcoded dynamic PT) to CUCM. We then
>>>> receive 101 from CUCM and, since our inbound dial-peer has asymmetry
>>>> disabled, CUBE sends 100 to match the original PT it received. Asymmetry is
>>>> disabled so CUBE is
ny hardcoded dynamic PT) to CUCM. We then
>>> receive 101 from CUCM and, since our inbound dial-peer has asymmetry
>>> disabled, CUBE sends 100 to match the original PT it received. Asymmetry is
>>> disabled so CUBE is not passing the received dynamic PT through to the
>>>
ing the received dynamic PT through to the
>> next-hop dial-peer - we have symmetry on both call legs for our NTE PT.
>>
>>
>>
>> Note that CUBE has no issues receiving one dynamic PT for NTE and sending
>> another (ex: receiving PT 100 and transmitting 101 for RTP-NTE) on t
> end attach-----
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On Behalf
> Of *Ed Leatherman
> *Sent:* Monday, July 18, 2016 3:10 PM
> *To:* Cisco VOIP <cisco-voip@puck.nether.net>
> *Subject:* [cisco-voip] DTMF interworking on CUBE -
I'm trying to get my head wrapped around some DTMF interworking features...
I have this setup:
UCM -- CUBE --- 3rd party system
For both call legs through CUBE I'm advertising kpml and rtp-nte for
dtmf-relay
The 3rd party sometimes sends me rtp payload type 101 for nte's, and no
kpml,
14 matches
Mail list logo
