<div dir="ltr">Carlos,<div><br></div><div>In my opinion, MTPs should not be used to fix issues, if non-MTP inducing alternative fixes exist. Or to say that another way: MTPs are a last resort. I do use them, sometimes, so don't get me wrong. I'm not saying they're bad and avoid them.</div><div><br></div><div>E.g., If your CUBE is set for rtp-nte DTMF relay only, on your CUCM facing dial-peers, then MTPs will be invoked for calls going to, say, UCCX. You could invoke an MTP to fix those calls to UCCX, or you could just add an Out of Band DTMF relay option on your dial-peers.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 8, 2018 at 5:25 AM Carlos G Mendioroz <<a href="mailto:tron@huapi.ba.ar">tron@huapi.ba.ar</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Indeed, an MTP was forced by the SIP trunk config.<br>
I'll have to rethink my MTP strategy, because having had so many issues<br>
with NOT having an MTP, I'm used to insert MTPs by default on SIP trunks.<br>
<br>
Still not comfortable though, CUCM knows it's going to a dead end and<br>
waits untill progress to "bail out". But I can understand why now (there<br>
could have been xcodes to make the job, there are none).<br>
<br>
Thanks!!!<br>
<br>
Anthony Holloway @ 08/10/2018 01:16 -0300 dixit:<br>
> Bernhard, Good job proposing an MTP is being invoked, and I would say<br>
> the same. There's a number of places/reasons an MTP could be inserted,<br>
> how would you systematically check this? I.e., What's your approach?<br>
> <br>
> Also, we don't have to assume .2 is a CUCM node. Look at the SIP Via:<br>
> header. The call flow was was described as: Jabber > CUCM > CUBE > SP,<br>
> and the SIP request is label as being "CUBE received."<br>
> <br>
> Not too mention the handful of other lines in that message which all<br>
> point to .2 being a CUCM node. (SDP o line, SIP User-Agent header, etc.)<br>
> *<br>
> *<br>
> <br>
> <br>
> On Sun, Oct 7, 2018 at 10:22 PM Bernhard Albler<br>
> <<a href="mailto:bernhard.albler@gmail.com" target="_blank">bernhard.albler@gmail.com</a> <mailto:<a href="mailto:bernhard.albler@gmail.com" target="_blank">bernhard.albler@gmail.com</a>>> wrote:<br>
> <br>
> looking at your invite it looks like an MTP is being invoked (<br>
> assuming .2 is the address of a cucm node)<br>
> Thats the reason g711 is being used<br>
> now the question is if the MTP was inserted via config or because of<br>
> some ( e.g. dtmf) other reason and if it is safe to remove it<br>
> therefore...<br>
> <br>
> On Mon 8. Oct 2018 at 00:21, Carlos G Mendioroz via cisco-voip<br>
> <<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a> <mailto:<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a>>> wrote:<br>
> <br>
> Hi,<br>
> kind of rusty (me, long time since engaging in troubleshooting<br>
> of Voip)<br>
> but I encountered something weird (again, may be me).<br>
> <br>
> Jabber Android (12.1) registered to CUCM (10.5) with region set<br>
> with 16K<br>
> audio limit.<br>
> <br>
> Call comes from Jabber through CUCM to CUBE to SP, but signalled<br>
> as G711<br>
> and after session progress, it gets cancelled.<br>
> <br>
> Shouldn't CUCM signal the call with G.729 in the first place ?<br>
> <br>
> CUBE received:<br>
> INVITE <a href="http://sip:947930020@10.0.100.1:5060" rel="noreferrer" target="_blank">sip:947930020@10.0.100.1:5060</a><br>
> <<a href="http://sip:947930020@10.0.100.1:5060" rel="noreferrer" target="_blank">http://sip:947930020@10.0.100.1:5060</a>> SIP/2.0<br>
> Via: SIP/2.0/TCP 10.0.100.2:5060;branch=z9hG4bK235a8e855ad<br>
> From:<br>
> <<a href="mailto:sip%3A3560@10.0.100.2" target="_blank">sip:3560@10.0.100.2</a><br>
> <mailto:<a href="mailto:sip%253A3560@10.0.100.2" target="_blank">sip%3A3560@10.0.100.2</a>>>;tag=36658~4fdda745-cceb-4407-a170-1420de65d7d7-22052972<br>
> To: <<a href="mailto:sip%3A947930020@10.0.100.1" target="_blank">sip:947930020@10.0.100.1</a> <mailto:<a href="mailto:sip%253A947930020@10.0.100.1" target="_blank">sip%3A947930020@10.0.100.1</a>>><br>
> Date: Sun, 07 Oct 2018 20:45:59 GMT<br>
> Call-ID: <a href="mailto:fd98a300-bba17087-1b99-264000a@10.0.100.2" target="_blank">fd98a300-bba17087-1b99-264000a@10.0.100.2</a><br>
> <mailto:<a href="mailto:fd98a300-bba17087-1b99-264000a@10.0.100.2" target="_blank">fd98a300-bba17087-1b99-264000a@10.0.100.2</a>><br>
> Supported: timer,resource-priority,replaces<br>
> Min-SE: 1800<br>
> User-Agent: Cisco-CUCM10.5<br>
> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,<br>
> REFER,<br>
> SUBSCRIBE, NOTIFY<br>
> CSeq: 101 INVITE<br>
> Expires: 180<br>
> Allow-Events: presence, kpml<br>
> Supported: X-cisco-srtp-fallback,X-cisco-original-called<br>
> Cisco-Guid: 4254638848-0000065536-0000000690-0040108042<br>
> Session-Expires: 1800<br>
> P-Asserted-Identity: <<a href="mailto:sip%3A3560@10.0.100.2" target="_blank">sip:3560@10.0.100.2</a><br>
> <mailto:<a href="mailto:sip%253A3560@10.0.100.2" target="_blank">sip%3A3560@10.0.100.2</a>>><br>
> Remote-Party-ID: <<a href="mailto:sip%3A3560@10.0.100.2" target="_blank">sip:3560@10.0.100.2</a><br>
> <mailto:<a href="mailto:sip%253A3560@10.0.100.2" target="_blank">sip%3A3560@10.0.100.2</a>>>;party=calling;screen=yes;privacy=off<br>
> Contact:<br>
> <<a href="http://sip:3560@10.0.100.2:5060" rel="noreferrer" target="_blank">sip:3560@10.0.100.2:5060</a><br>
> <<a href="http://sip:3560@10.0.100.2:5060" rel="noreferrer" target="_blank">http://sip:3560@10.0.100.2:5060</a>>;transport=tcp>;+u.sip!<a href="http://devicename.ccm.cisco.com" rel="noreferrer" target="_blank">devicename.ccm.cisco.com</a><br>
> <<a href="http://devicename.ccm.cisco.com" rel="noreferrer" target="_blank">http://devicename.ccm.cisco.com</a>>="BOTTRON"<br>
> Max-Forwards: 13<br>
> Content-Type: application/sdp<br>
> Content-Length: 197<br>
> <br>
> v=0<br>
> o=CiscoSystemsCCM-SIP 36658 1 IN IP4 10.0.100.2<br>
> s=SIP Call<br>
> c=IN IP4 10.0.100.2<br>
> t=0 0<br>
> m=audio 26804 RTP/AVP 0 101<br>
> a=rtpmap:0 PCMU/8000<br>
> a=rtpmap:101 telephone-event/8000<br>
> a=fmtp:101 0-15<br>
> <br>
> <br>
> TIA,<br>
> -- <br>
> Carlos G Mendioroz <<a href="mailto:tron@huapi.ba.ar" target="_blank">tron@huapi.ba.ar</a><br>
> <mailto:<a href="mailto:tron@huapi.ba.ar" target="_blank">tron@huapi.ba.ar</a>>> LW7 EQI Argentina<br>
> _______________________________________________<br>
> cisco-voip mailing list<br>
> <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a> <mailto:<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/mailman/listinfo/cisco-voip</a><br>
> <br>
> -- <br>
> Bernhard Albler, +4369917207384<br>
> --<br>
> "Was Nachwelt! Wie komm' ich dazu was für die Nachwelt zu tun? Was<br>
> hat denn die Nachwelt für mich getan?"<br>
> --Carl Friedrich Zelter<br>
> _______________________________________________<br>
> cisco-voip mailing list<br>
> <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a> <mailto:<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/mailman/listinfo/cisco-voip</a><br>
> <br>
<br>
-- <br>
Carlos G Mendioroz <<a href="mailto:tron@huapi.ba.ar" target="_blank">tron@huapi.ba.ar</a>> LW7 EQI Argentina<br>
</blockquote></div>