Grr, now that MTP is not forced, calls from CUCM phones to some dialpeers (phones) on the CUBE fail :(
The only weirdness seems to be: v=0 o=CiscoSystemsSIP-GW-UserAgent 2983 2791 IN IP4 10.0.100.1 s=SIP Call c=IN IP4 10.0.100.1 t=0 0 m=audio 18746 RTP/AVP 9 116 0 8 18 101 c=IN IP4 10.0.100.1 a=rtpmap:9 G722/8000 a=fmtp:9 bitrate=64 a=rtpmap:116 iLBC/8000 a=fmtp:116 mode=20 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 versus: v=0 o=CiscoSystemsCCM-SIP 38001 1 IN IP4 10.0.100.2 s=SIP Call c=IN IP4 10.0.100.5 b=TIAS:64000 b=AS:64 t=0 0 m=audio 49328 RTP/AVP 9 101 a=rtpmap:9 G722/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:49329 IN IP4 10.0.100.5 (note 101 0-16 and 0-15 missmatch). The CUBE is tearing down with: Reason: Q.850;cause=172 Carlos G Mendioroz via cisco-voip @ 08/10/2018 07:25 -0300 dixit: > Indeed, an MTP was forced by the SIP trunk config. > I'll have to rethink my MTP strategy, because having had so many issues > with NOT having an MTP, I'm used to insert MTPs by default on SIP trunks. > > Still not comfortable though, CUCM knows it's going to a dead end and > waits untill progress to "bail out". But I can understand why now (there > could have been xcodes to make the job, there are none). > > Thanks!!! > > Anthony Holloway @ 08/10/2018 01:16 -0300 dixit: >> Bernhard, Good job proposing an MTP is being invoked, and I would say >> the same. There's a number of places/reasons an MTP could be inserted, >> how would you systematically check this? I.e., What's your approach? >> >> Also, we don't have to assume .2 is a CUCM node. Look at the SIP Via: >> header. The call flow was was described as: Jabber > CUCM > CUBE > SP, >> and the SIP request is label as being "CUBE received." >> >> Not too mention the handful of other lines in that message which all >> point to .2 being a CUCM node. (SDP o line, SIP User-Agent header, etc.) >> * >> * >> >> >> On Sun, Oct 7, 2018 at 10:22 PM Bernhard Albler >> <bernhard.alb...@gmail.com <mailto:bernhard.alb...@gmail.com>> wrote: >> >> looking at your invite it looks like an MTP is being invoked ( >> assuming .2 is the address of a cucm node) >> Thats the reason g711 is being used >> now the question is if the MTP was inserted via config or because of >> some ( e.g. dtmf) other reason and if it is safe to remove it >> therefore... >> >> On Mon 8. Oct 2018 at 00:21, Carlos G Mendioroz via cisco-voip >> <cisco-voip@puck.nether.net <mailto:cisco-voip@puck.nether.net>> wrote: >> >> Hi, >> kind of rusty (me, long time since engaging in troubleshooting >> of Voip) >> but I encountered something weird (again, may be me). >> >> Jabber Android (12.1) registered to CUCM (10.5) with region set >> with 16K >> audio limit. >> >> Call comes from Jabber through CUCM to CUBE to SP, but signalled >> as G711 >> and after session progress, it gets cancelled. >> >> Shouldn't CUCM signal the call with G.729 in the first place ? >> >> CUBE received: >> INVITE sip:947930020@10.0.100.1:5060 >> <http://sip:947930020@10.0.100.1:5060> SIP/2.0 >> Via: SIP/2.0/TCP 10.0.100.2:5060;branch=z9hG4bK235a8e855ad >> From: >> <sip:3560@10.0.100.2 >> >> <mailto:sip%3A3560@10.0.100.2>>;tag=36658~4fdda745-cceb-4407-a170-1420de65d7d7-22052972 >> To: <sip:947930020@10.0.100.1 <mailto:sip%3A947930020@10.0.100.1>> >> Date: Sun, 07 Oct 2018 20:45:59 GMT >> Call-ID: fd98a300-bba17087-1b99-264000a@10.0.100.2 >> <mailto:fd98a300-bba17087-1b99-264000a@10.0.100.2> >> Supported: timer,resource-priority,replaces >> Min-SE: 1800 >> User-Agent: Cisco-CUCM10.5 >> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, >> REFER, >> SUBSCRIBE, NOTIFY >> CSeq: 101 INVITE >> Expires: 180 >> Allow-Events: presence, kpml >> Supported: X-cisco-srtp-fallback,X-cisco-original-called >> Cisco-Guid: 4254638848-0000065536-0000000690-0040108042 >> Session-Expires: 1800 >> P-Asserted-Identity: <sip:3560@10.0.100.2 >> <mailto:sip%3A3560@10.0.100.2>> >> Remote-Party-ID: <sip:3560@10.0.100.2 >> <mailto:sip%3A3560@10.0.100.2>>;party=calling;screen=yes;privacy=off >> Contact: >> <sip:3560@10.0.100.2:5060 >> >> <http://sip:3560@10.0.100.2:5060>;transport=tcp>;+u.sip!devicename.ccm.cisco.com >> <http://devicename.ccm.cisco.com>="BOTTRON" >> Max-Forwards: 13 >> Content-Type: application/sdp >> Content-Length: 197 >> >> v=0 >> o=CiscoSystemsCCM-SIP 36658 1 IN IP4 10.0.100.2 >> s=SIP Call >> c=IN IP4 10.0.100.2 >> t=0 0 >> m=audio 26804 RTP/AVP 0 101 >> a=rtpmap:0 PCMU/8000 >> a=rtpmap:101 telephone-event/8000 >> a=fmtp:101 0-15 >> >> >> TIA, >> -- >> Carlos G Mendioroz <t...@huapi.ba.ar >> <mailto:t...@huapi.ba.ar>> LW7 EQI Argentina >> _______________________________________________ >> cisco-voip mailing list >> cisco-voip@puck.nether.net <mailto:cisco-voip@puck.nether.net> >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >> -- >> Bernhard Albler, +4369917207384 >> -- >> "Was Nachwelt! Wie komm' ich dazu was für die Nachwelt zu tun? Was >> hat denn die Nachwelt für mich getan?" >> --Carl Friedrich Zelter >> _______________________________________________ >> cisco-voip mailing list >> cisco-voip@puck.nether.net <mailto:cisco-voip@puck.nether.net> >> https://puck.nether.net/mailman/listinfo/cisco-voip >> > -- Carlos G Mendioroz <t...@huapi.ba.ar> LW7 EQI Argentina _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip