[cisco-voip] CUBE and LTI for MTPs
Brian V
bvanbens at gmail.com
Tue Dec 6 23:16:06 EST 2016
Resurrecting this thread again.... :)
Anthony, were you ever able to find a definitive answer if you can register
a software-only MTP to CUBE using the LTI method ? I'm trying it on a ISR
4321 with IOS-XE 16.3.2 and finding the same result you did where it won't
register.
I also share your observation (perhaps wonderment) that CUBE appears to
natively inter-network between the CUCM call leg using KPML and the SIP
provider call leg using rte-nte (RFC2833) without using any MTP or
transcoders. This is contrary to the supported DTMF inter-networking
support in the latest CUBE book for IOX-XE (
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html
)
When there is a call setup where the leg from CUBE to CUCM is using KPML
(to an MGCP controlled FXS port) and the leg to the SIP provider is using
rtp-nte:
The FXS phone presses a digit,
I see CUCM send the Notify to CUBE, then CUBE seems to package up the digit
in rtp-nte RTP packets and sends it out the call-leg toward the SIP
provider. No MTPs are configured on CUBE, No transcoders on CUBE and the
media streaming service is shut down on both CUCM nodes just for testing.
This is not supposed to work according to the documentation, yet it does.
debugs
debug ccsip messages
debug VOIP RTP ALL Named Events is ON
debug VOIP RTP DTMF-RELAY Events is ON
!! config snippets
voice service voip
ip address trusted list
no ip address trusted authenticate
allow-connections sip to sip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
registrar server
listen-port non-secure 5070
early-offer forced
no call service stop
voice class uri FromCUCM sip
host ipv4:172.25.1.10
host ipv4:172.25.1.11
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8
voice class e164-pattern-map 50
e164 91[2-9]..[2-9]......
e164 1[2-9]..[2-9]......
e164 9[2-9]......
voice class server-group 100
ipv4 172.25.1.10 port 5060 preference 1
ipv4 172.25.1.11 port 5060 preference 2
description CUCM Servers - PUB First
dial-peer voice 201 voip
session protocol sipv2
session target sip-server
incoming called-number 608xxxssss ! < ==inbound dial-peer for SIP service
dtmf-relay rtp-nte
codec g711ulaw
no vad
dial-peer voice 600 voip
description Google Voice via Simonics.com SIP TRUNK
translation-profile outgoing VoIPOut-Drp9-LDKeep1-IntKeep011
session protocol sipv2
session target dns:gvgw.simonics.com:5070 <== outbound dial peer to SIP
service
destination e164-pattern-map 50
voice-class codec 1
dtmf-relay rtp-nte
dial-peer voice 300 voip
description outgoing to CUCM <== outbound dial peer to CUCM
destination-pattern 608xxxssss <= matches inbound dial peer telephone
number
session protocol sipv2
session transport tcp
session server-group 100
voice-class codec 1
dtmf-relay sip-kpml rtp-nte
ip qos dscp cs3 signaling
no vad
*** call is up, 2-way audio*
PSTN-WAN#sh sip-ua calls
Total SIP call legs:2, User Agent Client:1, User Agent Server:1
SIP UAC CALL INFO
Call 1
SIP Call ID : D370F53F-BB6811E6-80B6B76E-F014D1AB at 192.168.0.4
State of the call : STATE_ACTIVE (7)
Substate of the call : SUBSTATE_NONE (0)
Calling Number : 608xxxssss
Called Number : 608xxxyyyy
Called URI : sip:608xxxssss at 172.25.1.10:5060
Bit Flags : 0xC04018 0x90000100 0x80
CC Call ID : 169
Source IP Address (Sig ): 192.168.0.4
Destn SIP Req Addr:Port : [172.25.1.10]:5060 <== CUCM
Destn SIP Resp Addr:Port: [172.25.1.10]:5060
Destination Name : 172.25.1.10
Number of Media Streams : 1
Number of Active Streams: 1
RTP Fork Object : 0x0
Media Mode : flow-through
Media Stream 1
State of the stream : STREAM_ACTIVE
Stream Call ID : 169
Stream Type : voice-only (0)
Stream Media Addr Type : 1
Negotiated Codec : g711ulaw (160 bytes)
Codec Payload Type : 0
Negotiated Dtmf-relay : sip-kpml
Dtmf-relay Payload Type : 0
QoS ID : -1
Local QoS Strength : BestEffort
Negotiated QoS Strength : BestEffort
Negotiated QoS Direction : None
Local QoS Status : None
Media Source IP Addr:Port: [192.168.0.4]:16476
Media Dest IP Addr:Port : [10.10.111.3]:16462 <== MGCP FXS Port
Options-Ping ENABLED:NO ACTIVE:NO
Number of SIP User Agent Client(UAC) calls: 1
SIP UAS CALL INFO
Call 1
SIP Call ID : 6814308 at 162.243.107.101:5070
State of the call : STATE_ACTIVE (7)
Substate of the call : SUBSTATE_NONE (0)
Calling Number : 608xxxyyyy
Called Number : 608xxxssss
Called URI : sip:608xxxssss at 69.129.203.165:53467
;transport=tcp
Bit Flags : 0xC0401C 0x10000100 0x4
CC Call ID : 168
Source IP Address (Sig ): 192.168.0.4
Destn SIP Req Addr:Port : [162.243.107.101]:5070 <== SIP Provider
Destn SIP Resp Addr:Port: [162.243.107.101]:5070
Destination Name : 162.243.107.101
Number of Media Streams : 1
Number of Active Streams: 1
RTP Fork Object : 0x0
Media Mode : flow-through
Media Stream 1
State of the stream : STREAM_ACTIVE
Stream Call ID : 168
Stream Type : voice+dtmf (0)
Stream Media Addr Type : 1
Negotiated Codec : g711ulaw (160 bytes)
Codec Payload Type : 0
Negotiated Dtmf-relay : rtp-nte
Dtmf-relay Payload Type : 101
QoS ID : -1
Local QoS Strength : BestEffort
Negotiated QoS Strength : BestEffort
Negotiated QoS Direction : None
Local QoS Status : None
Media Source IP Addr:Port: [192.168.0.4]:16474
Media Dest IP Addr:Port : [162.243.107.101]:32738
Options-Ping ENABLED:NO ACTIVE:NO
Number of SIP User Agent Server(UAS) calls: 1
*** Now press button 5 on the MGCP FXS phone with the debugs on*
PSTN-WAN#sh debug
debug VOIP RTP ALL Named Events is ON
debug VOIP RTP DTMF-RELAY Events is ON
CCSIP SPI: SIP Call Message tracing is enabled (filter is OFF)
PSTN-WAN#
Dec 7 04:05:45.577: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
NOTIFY sip:608xxxssss at 192.168.0.4:5070;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 172.25.1.10:5060;branch=z9hG4bKeec9a316b8c73
From: <sip:608xxxssss at 172.25.1.10
>;tag=1294924~b2f5c4f8-0137-42eb-8fa5-d6a25f53a8b9-18334838
To: "VAN BENSCHOTEN" <sip:608xxxyyyy at gvgw.simonics.com>;tag=174FD08-EF4
Call-ID: D370F53F-BB6811E6-80B6B76E-F014D1AB at 192.168.0.4
CSeq: 108 NOTIFY
Max-Forwards: 70
Date: Wed, 07 Dec 2016 04:05:45 GMT
User-Agent: Cisco-CUCM11.0
Event: kpml
Subscription-State: active;expires=7030
Contact: <sip:172.25.1.10:5060;transport=tcp>
Content-Type: application/kpml-response+xml
Content-Length: 336
<?xml version="1.0" encoding="UTF-8" ?>
<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
code="200" digits="5" forced_flush="false" suppressed="false" tag="dtmf"
text="Success" version="1.0"/>
Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03
sequence 0x7188 timestamp 0x4E9576E9
Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:0A 00 00 <Snd>>>
Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03
sequence 0x7189 timestamp 0x4E9576E9
Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:0A 00 00 <Snd>>>
Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03
sequence 0x718A timestamp 0x4E9576E9
Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:0A 00 00 <Snd>>>
Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03
sequence 0x718B timestamp 0x4E9576E9
Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:0A 01 90 <Snd>>>
Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03
sequence 0x718C timestamp 0x4E9576E9
PSTN-WAN#
Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:84 03 20 <Snd>>>
Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03
sequence 0x718D timestamp 0x4E9576E9
Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:84 03 20 <Snd>>>
Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03
sequence 0x718E timestamp 0x4E9576E9
Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:84 03 20 <Snd>>>
Sure looks like CUBE is internetworking between SIP-KPML and RTP-NTE
(RFC2833) when it's not supported
*!!*** now press button 6 from the PSTN phone*
PSTN-WAN#
PSTN-WAN#
Dec 7 04:10:00.649: s=VoIP d=DSP payload 0x65 ssrc 0x5B76F3C5
sequence 0x7F3F timestamp 0xE703188
Dec 7 04:10:00.649: <<<Rcv> Pt:101 Evt:6 Pkt:00 00 00
Dec 7 04:10:00.649: s=DSP d=VoIP payload 0x65 ssrc 0x5B76F3C5
sequence 0x7F3F timestamp 0xE703188
Dec 7 04:10:00.649: Pt:101 Evt:6 Pkt:00 00 00 <Snd>>>
Dec 7 04:10:00.669: s=VoIP d=DSP payload 0x65 ssrc 0x5B76F3C5
sequence 0x7F40 timestamp 0xE703188
Dec 7 04:10:00.669: <<<Rcv> Pt:101 Evt:6 Pkt:80 07 80
Dec 7 04:10:00.669: s=DSP d=VoIP payload 0x65 ssrc 0x5B76F3C5
sequence 0x7F40 timestamp 0xE703188
PSTN-WAN#
Dec 7 04:10:00.669: Pt:101 Evt:6 Pkt:80 07 80 <Snd>>>
Dec 7 04:10:00.669: s=VoIP d=DSP payload 0x65 ssrc 0x5B76F3C5
sequence 0x7F40 timestamp 0xE703188
Dec 7 04:10:00.669: <<<Rcv> Pt:101 Evt:6 Pkt:80 07 80
Dec 7 04:10:00.669: s=DSP d=VoIP payload 0x65 ssrc 0x5B76F3C5
sequence 0x7F40 timestamp 0xE703188
Dec 7 04:10:00.669: Pt:101 Evt:6 Pkt:80 07 80 <Snd>>>
PSTN-WAN#
We see inbound rte-nte packets, *no* SIP-Notify towards CUCM , yet on the
MGCP FXS phone I hear the inbound DTMF.
Whats going on here ?
Any thoughts ?
On Fri, Jul 8, 2016 at 3:31 PM, Anthony Holloway <
avholloway+cisco-voip at gmail.com> wrote:
> I use rtp-nte to SIP KPML in CUBE quite a bit actually, despite the
> documentation saying it's not supported. I also use digit-drop too by the
> way, because on more than one occasion I have had double DTMF issues.
>
> E.g., dtmf-relay sip-kpml rtp-nte digit-drop
>
> Also, unless you like using MTPs in your some of call flows (E.g., UCCX),
> you should have one OOB and one inband DTMF offering on your dial-peers.
> It surprises me how often I see and hear of people only putting rtp-nte on
> there.
>
> On Thu, Jul 7, 2016 at 7:20 PM, Ed Leatherman <ealeatherman at gmail.com>
> wrote:
>
>> I've been beating my head on this all day, glad I ran across this thread
>> as it at least seems to rule out one potential issue on my current SIP
>> puzzle :)
>>
>> I've found 2 different documents with tables that suggest KPML <> rpt-nte
>> shouldn't work... i realize its over a year since this thread popped in -
>> has anyone ever seen something to the contrary in official documentation?
>>
>> On Tue, Mar 31, 2015 at 11:54 AM, Anthony Holloway <
>> avholloway+cisco-voip at gmail.com> wrote:
>>
>>> After reading a bit more in the CUCM SRND, I see that SIP INFO is not
>>> supported by CUCM, and furthermore, Cisco's preferred OOB method is KPML.
>>>
>>> "Out-of-band (OOB) SIP DTMF signalling methods include Unsolicited
>>> Notify (UN), Information
>>> (INFO), and Key Press Mark-up Language (KPML). KPML (RFC 4730) is the
>>> OOB signalling method
>>> preferred by Cisco and is supported by Cisco Unified CM, Cisco IOS
>>> platforms (Release 12.4 and later),
>>> and most models of Cisco Unified IP Phones. INFO is not supported by
>>> Unified CM."
>>> Source: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/
>>> cucm/srnd/collab10/collab10/trunks.html#pgfId-1346554
>>>
>>> With that said, according to the link you provided on CUBE and DTMF
>>> inter-working, it would appear as though the only option which remains is
>>> SIP NOTIFY. This method requires the SIP Trunk Security Profile to have
>>> the Accept unsolicited notification checkbox checked.
>>>
>>> I did test with KPML, and CUBE did inter-work it. My IOS/CUBE version
>>> is as follows:
>>>
>>> *CUBE#sh cube status | in Version*
>>> *CUBE-Version : 10.0.2*
>>> *SW-Version : 15.4.3.M2, Platform CISCO2921/K9*
>>>
>>> I think I'll go with KPML for now, and thank you for helping me to see
>>> the light.
>>>
>>> On Mon, Mar 30, 2015 at 1:52 PM Brian Meade <bmeade90 at vt.edu> wrote:
>>>
>>>> This chart has all the interoperability that can be handled by
>>>> dtmf-relay natively on CUBE- http://www.cisco.com/c/
>>>> en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-
>>>> book/dtmf-relay.html#concept_264617919921874995299551391601561
>>>>
>>>> Brian
>>>>
>>>> On Mon, Mar 30, 2015 at 2:29 PM, Brian Meade <bmeade90 at vt.edu> wrote:
>>>>
>>>>> dtmf-relay I believe should handle that find for you without the MTP.
>>>>>
>>>>> On Mon, Mar 30, 2015 at 1:21 PM, Anthony Holloway <
>>>>> avholloway+cisco-voip at gmail.com> wrote:
>>>>>
>>>>>> Oooo, good question Brian. It's my understanding that in order for
>>>>>> the below specific call flow to work, an MTP is required for DTMF
>>>>>> inter-working of inband to out-of-band.
>>>>>>
>>>>>> PSTN Caller Pushes DTMF ---> ITSP Delivers RFC2833 ---> CUBE Delivers
>>>>>> OOB ---> CUCM Devlier OOB ---> UCCX CTI Port Receives OOB
>>>>>>
>>>>>> Is that not the case?
>>>>>>
>>>>>> On Mon, Mar 30, 2015 at 12:01 PM Brian Meade <bmeade90 at vt.edu> wrote:
>>>>>>
>>>>>>> What are you trying to accomplish with the MTP that can't already be
>>>>>>> accomplished with media flow-through and dtmf-relay?
>>>>>>>
>>>>>>> On Mon, Mar 30, 2015 at 12:38 PM, Anthony Holloway <
>>>>>>> avholloway+cisco-voip at gmail.com> wrote:
>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>> I know the name itself, LTI, includes the word transcoding, but I'm
>>>>>>>> just double checking that this will or will not work for registering an MTP
>>>>>>>> on the CUBE. All roads are leading me to the answer, but it just seems
>>>>>>>> like a huge miss on Cisco's part to not allow us to register MTPs as well
>>>>>>>> as XCODE via the LTI method.
>>>>>>>>
>>>>>>>> This works for me:
>>>>>>>> dspfarm profile 1 transcode
>>>>>>>> codec g711ulaw
>>>>>>>> codec g729ar8
>>>>>>>> max sessions 1
>>>>>>>> assoc app cube
>>>>>>>> no shut
>>>>>>>> !
>>>>>>>>
>>>>>>>> This does not work for me (it hangs on associating to cube app):
>>>>>>>> dapfarm profile 2 mtp
>>>>>>>> codec g711ulaw
>>>>>>>> max sessions software 1
>>>>>>>> assoc app cube
>>>>>>>> no shut
>>>>>>>> !
>>>>>>>>
>>>>>>>> I have the required dspfarm and mode border-element commands, and
>>>>>>>> rebooted after as well.
>>>>>>>>
>>>>>>>> Seems like with the standard requirement of rfc2833 on SIP trunks
>>>>>>>> to the ITPS, and CTI apps in the network (I'm looking at you UCCX), MTPs
>>>>>>>> play a large role in the success of SIP trunking for customers, and yet I
>>>>>>>> cannot even register them locally with the LTI.
>>>>>>>>
>>>>>>>> I do have a fallback plan, so I'm not stuck. I'm just looking for
>>>>>>>> the optimal design scenario. In my order of preference I would like to go:
>>>>>>>>
>>>>>>>> 1. LTI
>>>>>>>> 2. SCCP via Telephony Service
>>>>>>>> 3. SCCP via CUCM
>>>>>>>>
>>>>>>>> Would you rank them differently?
>>>>>>>>
>>>>>>>> Thanks for your input in advance.
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>
>>>
>>
>>
>> --
>> Ed Leatherman
>>
>
>
> _______________________________________________
> cisco-voip mailing list
> 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/20161206/eba4efbc/attachment.html>
More information about the cisco-voip
mailing list