<div dir="ltr">DTMF and SIP has been a real challenge for me lately. For some reason the KPML to RFC2833 (RTP-NTE) inter-working has not been working for me. As in, I'm seeing a higher rate of failures using this inter-working method. I have recently switched over to NOTIFY to RFC2833 inter-working and so far, I haven't seen any problems. You just have to enable unsolicited notify on the SIP trunk security profile. Sorry, but I don't have an answer for you.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 6, 2016 at 10:16 PM, Brian V <span dir="ltr"><<a href="mailto:bvanbens@gmail.com" target="_blank">bvanbens@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Resurrecting this thread again.... :)<br><br></div>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.<br><br></div>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 (<a href="http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html" target="_blank">http://www.cisco.com/c/en/us/<wbr>td/docs/ios-xml/ios/voice/<wbr>cube/configuration/cube-book/<wbr>dtmf-relay.html</a>)<br><br></div>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:<br></div>The FXS phone presses a digit,<br>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.<br><br></div><div>debugs<br>debug ccsip messages<br>debug VOIP RTP ALL Named Events is ON<br>debug VOIP RTP DTMF-RELAY Events is ON<br><br><br></div><div>!! config snippets<br><span style="font-family:monospace,monospace">voice service voip<br> ip address trusted list<br> no ip address trusted authenticate<br> allow-connections sip to sip<br> fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none<br> sip<br> registrar server<br> listen-port non-secure 5070<br> early-offer forced<br> no call service stop<br><br>voice class uri FromCUCM sip<br> host ipv4:172.25.1.10<br> host ipv4:172.25.1.11<br><br>voice class codec 1<br> codec preference 1 g711ulaw</span><br> <span style="font-family:monospace,monospace">codec preference 2 g729r8<br><br>voice class e164-pattern-map 50<br> e164 91[2-9]..[2-9]......<br> e164 1[2-9]..[2-9]......<br> e164 9[2-9]......<br><br>voice class server-group 100<br> ipv4 172.25.1.10 port 5060 preference 1<br> ipv4 172.25.1.11 port 5060 preference 2<br> description CUCM Servers - PUB First<br><br>dial-peer voice 201 voip<br> session protocol sipv2<br> session target sip-server<br> incoming called-number 608xxxssss ! < ==inbound dial-peer for SIP service<br> dtmf-relay rtp-nte<br> codec g711ulaw<br> no vad<br><br>dial-peer voice 600 voip<br> description Google Voice via Simonics.com SIP TRUNK<br> translation-profile outgoing VoIPOut-Drp9-LDKeep1-<wbr>IntKeep011<br> session protocol sipv2<br> session target dns:<a href="http://gvgw.simonics.com:5070" target="_blank">gvgw.simonics.com:5070</a> <== outbound dial peer to SIP service<br> destination e164-pattern-map 50<br> voice-class codec 1 <br> dtmf-relay rtp-nte <br><br></span><br><span style="font-family:monospace,monospace">dial-peer voice 300 voip<br> description outgoing to CUCM <== outbound dial peer to CUCM <br> destination-pattern 608xxxssss <= matches inbound dial peer telephone number<br> session protocol sipv2<br> session transport tcp<br> session server-group 100<br> voice-class codec 1 <br> dtmf-relay sip-kpml rtp-nte<br> ip qos dscp cs3 signaling<br> no vad <br><br><br></span><br><b><span style="font-family:arial,helvetica,sans-serif">** call is up, 2-way audio</span></b><span style="font-family:monospace,monospace"><br><br>PSTN-WAN#sh sip-ua calls <br>Total SIP call legs:2, User Agent Client:1, User Agent Server:1<br>SIP UAC CALL INFO<br>Call 1<br>SIP Call ID : <a href="mailto:D370F53F-BB6811E6-80B6B76E-F014D1AB@192.168.0.4" target="_blank">D370F53F-BB6811E6-80B6B76E-<wbr>F014D1AB@192.168.0.4</a><br> State of the call : STATE_ACTIVE (7)<br> Substate of the call : SUBSTATE_NONE (0)<br> Calling Number : 608xxxssss<br> Called Number : 608xxxyyyy<br> Called URI : <a href="http://sip:608xxxssss@172.25.1.10:5060" target="_blank">sip:608xxxssss@172.25.1.10:<wbr>5060</a><br> Bit Flags : 0xC04018 0x90000100 0x80<br> CC Call ID : 169<br> Source IP Address (Sig ): 192.168.0.4<br> Destn SIP Req Addr:Port : [172.25.1.10]:5060 <== CUCM<br> Destn SIP Resp Addr:Port: [172.25.1.10]:5060<br> Destination Name : 172.25.1.10<br> Number of Media Streams : 1<br> Number of Active Streams: 1<br> RTP Fork Object : 0x0<br> Media Mode : flow-through</span><br> <span style="font-family:monospace,monospace">Media Stream 1<br> State of the stream : STREAM_ACTIVE<br> Stream Call ID : 169<br> Stream Type : voice-only (0)<br> Stream Media Addr Type : 1<br> Negotiated Codec : g711ulaw (160 bytes)<br> Codec Payload Type : 0 <br> Negotiated Dtmf-relay : sip-kpml<br> Dtmf-relay Payload Type : 0<br> QoS ID : -1<br> Local QoS Strength : BestEffort<br> Negotiated QoS Strength : BestEffort<br> Negotiated QoS Direction : None<br> Local QoS Status : None<br> Media Source IP Addr:Port: [192.168.0.4]:16476<br> Media Dest IP Addr:Port : [10.10.111.3]:16462 <== MGCP FXS Port<br><br><br>Options-Ping ENABLED:NO ACTIVE:NO<br> Number of SIP User Agent Client(UAC) calls: 1<br></span><br><span style="font-family:monospace,monospace">SIP UAS CALL INFO<br>Call 1<br>SIP Call ID : <a href="http://6814308@162.243.107.101:5070" target="_blank">6814308@162.243.107.101:5070</a><br> State of the call : STATE_ACTIVE (7)<br> Substate of the call : SUBSTATE_NONE (0)<br> Calling Number : 608xxxyyyy<br> Called Number : 608xxxssss<br> Called URI : <a href="mailto:sip%3A608xxxssss@69.129.203.165">sip:608xxxssss@69.129.203.165</a>:<wbr>53467;transport=tcp<br> Bit Flags : 0xC0401C 0x10000100 0x4<br> CC Call ID : 168<br> Source IP Address (Sig ): 192.168.0.4<br> Destn SIP Req Addr:Port : [162.243.107.101]:5070 <== SIP Provider<br> Destn SIP Resp Addr:Port: [162.243.107.101]:5070<br> Destination Name : 162.243.107.101<br> Number of Media Streams : 1<br> Number of Active Streams: 1<br> RTP Fork Object : 0x0<br> Media Mode : flow-through<br> Media Stream 1<br> State of the stream : STREAM_ACTIVE<br> Stream Call ID : 168<br> Stream Type : voice+dtmf (0)<br> Stream Media Addr Type : 1<br> Negotiated Codec : g711ulaw (160 bytes)<br> Codec Payload Type : 0 <br> Negotiated Dtmf-relay : rtp-nte<br> Dtmf-relay Payload Type : 101<br> QoS ID : -1<br> Local QoS Strength : BestEffort<br> Negotiated QoS Strength : BestEffort<br> Negotiated QoS Direction : None</span><br> <span style="font-family:monospace,monospace"> Local QoS Status : None<br> Media Source IP Addr:Port: [192.168.0.4]:16474<br> Media Dest IP Addr:Port : [162.243.107.101]:32738<br><br><br>Options-Ping ENABLED:NO ACTIVE:NO<br> Number of SIP User Agent Server(UAS) calls: 1</span><br><br></div><div><b><br></b></div><div><b>** Now press button 5 on the MGCP FXS phone with the debugs on</b><br><br>PSTN-WAN#sh debug<br><br><span style="font-family:monospace,monospace"> debug VOIP RTP ALL Named Events is ON<br> debug VOIP RTP DTMF-RELAY Events is ON<br>CCSIP SPI: SIP Call Message tracing is enabled (filter is OFF)</span><br><br><br></div><div><br><span style="font-family:monospace,monospace">PSTN-WAN#<br>Dec 7 04:05:45.577: //-1/xxxxxxxxxxxx/SIP/Msg/<wbr>ccsipDisplayMsg:<br>Received: <br>NOTIFY <a href="mailto:sip%3A608xxxssss@192.168.0.4">sip:608xxxssss@192.168.0.4</a>:<wbr>5070;transport=tcp SIP/2.0<br>Via: SIP/2.0/TCP 172.25.1.10:5060;branch=<wbr>z9hG4bKeec9a316b8c73<br>From: <<a href="mailto:sip%3A608xxxssss@172.25.1.10" target="_blank">sip:608xxxssss@172.25.1.10</a>>;<wbr>tag=1294924~b2f5c4f8-0137-<wbr>42eb-8fa5-d6a25f53a8b9-<wbr>18334838<br>To: "VAN BENSCHOTEN" <<a href="mailto:sip%3A608xxxyyyy@gvgw.simonics.com" target="_blank">sip:608xxxyyyy@gvgw.simonics.<wbr>com</a>>;tag=174FD08-EF4<br>Call-ID: <a href="mailto:D370F53F-BB6811E6-80B6B76E-F014D1AB@192.168.0.4" target="_blank">D370F53F-BB6811E6-80B6B76E-<wbr>F014D1AB@192.168.0.4</a><br>CSeq: 108 NOTIFY<br>Max-Forwards: 70<br>Date: Wed, 07 Dec 2016 04:05:45 GMT<br>User-Agent: Cisco-CUCM11.0<br>Event: kpml<br>Subscription-State: active;expires=7030<br>Contact: <sip:<a href="http://172.25.1.10:5060">172.25.1.10:5060</a>;<wbr>transport=tcp><br>Content-Type: application/kpml-response+xml<br>Content-Length: 336<br><br><?xml version="1.0" encoding="UTF-8" ?><br><kpml-response xmlns="urn:ietf:params:xml:ns:<wbr>kpml-response" xmlns:xsi="<a href="http://www.w3.org/2001/XMLSchema-instance" target="_blank">http://www.w3.org/<wbr>2001/XMLSchema-instance</a>" xsi:schemaLocation="urn:ietf:<wbr>params:xml:ns:kpml-response kpml-response.xsd" code="200" digits="5" forced_flush="false" suppressed="false" tag="dtmf" text="Success" version="1.0"/></span><br><br><br><span style="font-family:monospace,monospace">Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03 sequence 0x7188 timestamp 0x4E9576E9<br>Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:0A 00 00 <Snd>>><br>Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03 sequence 0x7189 timestamp 0x4E9576E9<br>Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:0A 00 00 <Snd>>><br>Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03 sequence 0x718A timestamp 0x4E9576E9<br>Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:0A 00 00 <Snd>>><br>Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03 sequence 0x718B timestamp 0x4E9576E9<br>Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:0A 01 90 <Snd>>><br>Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03 sequence 0x718C timestamp 0x4E9576E9<br>PSTN-WAN#<br>Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:84 03 20 <Snd>>><br>Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03 sequence 0x718D timestamp 0x4E9576E9<br>Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:84 03 20 <Snd>>><br>Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03 sequence 0x718E timestamp 0x4E9576E9<br>Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:84 03 20 <Snd>>><br></span></div><div><div><div><div><br><br></div><div>Sure looks like CUBE is internetworking between SIP-KPML and RTP-NTE (RFC2833) when it's not supported<br><br></div><div><b>!!*** now press button 6 from the PSTN phone</b><br><br><span style="font-family:monospace,monospace">PSTN-WAN#<br>PSTN-WAN#<br>Dec 7 04:10:00.649: s=VoIP d=DSP payload 0x65 ssrc 0x5B76F3C5 sequence 0x7F3F timestamp 0xE703188<br>Dec 7 04:10:00.649: <<<Rcv> Pt:101 Evt:6 Pkt:00 00 00<br>Dec 7 04:10:00.649: s=DSP d=VoIP payload 0x65 ssrc 0x5B76F3C5 sequence 0x7F3F timestamp 0xE703188<br>Dec 7 04:10:00.649: Pt:101 Evt:6 Pkt:00 00 00 <Snd>>><br>Dec 7 04:10:00.669: s=VoIP d=DSP payload 0x65 ssrc 0x5B76F3C5 sequence 0x7F40 timestamp 0xE703188<br>Dec 7 04:10:00.669: <<<Rcv> Pt:101 Evt:6 Pkt:80 07 80<br>Dec 7 04:10:00.669: s=DSP d=VoIP payload 0x65 ssrc 0x5B76F3C5 sequence 0x7F40 timestamp 0xE703188<br>PSTN-WAN#<br>Dec 7 04:10:00.669: Pt:101 Evt:6 Pkt:80 07 80 <Snd>>><br>Dec 7 04:10:00.669: s=VoIP d=DSP payload 0x65 ssrc 0x5B76F3C5 sequence 0x7F40 timestamp 0xE703188<br>Dec 7 04:10:00.669: <<<Rcv> Pt:101 Evt:6 Pkt:80 07 80<br>Dec 7 04:10:00.669: s=DSP d=VoIP payload 0x65 ssrc 0x5B76F3C5 sequence 0x7F40 timestamp 0xE703188<br>Dec 7 04:10:00.669: Pt:101 Evt:6 Pkt:80 07 80 <Snd>>><br>PSTN-WAN#<br></span><br><br></div><div>We see inbound rte-nte packets, <u>no</u> SIP-Notify towards CUCM , yet on the MGCP FXS phone I hear the inbound DTMF.<br><br></div><div>Whats going on here ?<br></div><div>Any thoughts ?<br></div><div><br><br></div><div><br></div></div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 8, 2016 at 3:31 PM, Anthony Holloway <span dir="ltr"><<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.<wbr>com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>E.g., dtmf-relay sip-kpml rtp-nte digit-drop</div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 7, 2016 at 7:20 PM, Ed Leatherman <span dir="ltr"><<a href="mailto:ealeatherman@gmail.com" target="_blank">ealeatherman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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 :)<div><br></div><div>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? </div></div><div class="gmail_extra"><div><div class="m_-4917066708678112052m_-5818046081333971002h5"><br><div class="gmail_quote">On Tue, Mar 31, 2015 at 11:54 AM, Anthony Holloway <span dir="ltr"><<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.c<wbr>om</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>"Out-of-band (OOB) SIP DTMF signalling methods include Unsolicited Notify (UN), Information</div><div>(INFO), and Key Press Mark-up Language (KPML). KPML (RFC 4730) is the OOB signalling method</div><div>preferred by Cisco and is supported by Cisco Unified CM, Cisco IOS platforms (Release 12.4 and later),</div><div>and most models of Cisco Unified IP Phones. INFO is not supported by Unified CM."</div><div>Source: <a href="http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab10/collab10/trunks.html#pgfId-1346554" target="_blank">http://www.cisco.com/c<wbr>/en/us/td/docs/voice_ip_comm/c<wbr>ucm/srnd/collab10/collab10/tru<wbr>nks.html#pgfId-1346554</a><br><div><br></div><div>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.</div><div><br></div><div>I did test with KPML, and CUBE did inter-work it. My IOS/CUBE version is as follows:</div><div><br></div><div><div><div><b>CUBE#sh cube status | in Version</b></div><div><b>CUBE-Version : 10.0.2</b></div><div><b>SW-Version : 15.4.3.M2, Platform CISCO2921/K9</b></div></div><div><br></div><div>I think I'll go with KPML for now, and thank you for helping me to see the light.</div><div><div><br><div class="gmail_quote">On Mon, Mar 30, 2015 at 1:52 PM Brian Meade <<a href="mailto:bmeade90@vt.edu" target="_blank">bmeade90@vt.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This chart has all the interoperability that can be handled by dtmf-relay natively on CUBE- <a href="http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561" target="_blank">http://www.cisco.com/c/e<wbr>n/us/td/docs/ios-xml/ios/voice<wbr>/cube/configuration/cube-book/<wbr>dtmf-relay.html#concept_264617<wbr>919921874995299551391601561</a></div><div dir="ltr"><div><br></div><div>Brian</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 30, 2015 at 2:29 PM, Brian Meade <span dir="ltr"><<a href="mailto:bmeade90@vt.edu" target="_blank">bmeade90@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">dtmf-relay I believe should handle that find for you without the MTP.</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 30, 2015 at 1:21 PM, Anthony Holloway <span dir="ltr"><<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.c<wbr>om</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<br><br><div>PSTN Caller Pushes DTMF ---> ITSP Delivers RFC2833 ---> CUBE Delivers OOB ---> CUCM Devlier OOB ---> UCCX CTI Port Receives OOB</div><div><br></div><div><span style="line-height:1.5;font-size:13.1999998092651px">Is that not the case?</span><br></div></div><div><div><br><div class="gmail_quote">On Mon, Mar 30, 2015 at 12:01 PM Brian Meade <<a href="mailto:bmeade90@vt.edu" target="_blank">bmeade90@vt.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">What are you trying to accomplish with the MTP that can't already be accomplished with media flow-through and dtmf-relay?</div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 30, 2015 at 12:38 PM, Anthony Holloway <span dir="ltr"><<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.c<wbr>om</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">All,<div><br></div><div>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.</div><div><br></div><div>This works for me:</div><div>dspfarm profile 1 transcode</div><div> codec g711ulaw</div><div> codec g729ar8</div><div> max sessions 1</div><div> assoc app cube</div><div> no shut</div><div>!</div><div><br></div><div>This does not work for me (it hangs on associating to cube app):</div><div>dapfarm profile 2 mtp</div><div> codec g711ulaw</div><div> max sessions software 1</div><div> assoc app cube</div><div> no shut</div><div>!</div><div><br></div><div>I have the required dspfarm and mode border-element commands, and rebooted after as well.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>1. LTI</div><div>2. SCCP via Telephony Service</div><div>3. SCCP via CUCM</div><div><br></div><div>Would you rank them differently?</div><div><br></div><div>Thanks for your input in advance.</div></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">______________________________<wbr>_________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailma<wbr>n/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</blockquote></div></div></div></div></div></div>
<br>______________________________<wbr>_________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailma<wbr>n/listinfo/cisco-voip</a><br>
<br></blockquote></div><br><br clear="all"><span class="m_-4917066708678112052HOEnZb"><font color="#888888"><div><br></div></font></span></div></div><span class="m_-4917066708678112052HOEnZb"><font color="#888888"><span class="m_-4917066708678112052m_-5818046081333971002HOEnZb"><font color="#888888">-- <br><div data-smartmail="gmail_signature">Ed Leatherman<br></div>
</font></span></font></span></div>
</blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailma<wbr>n/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>