You might update your dial-peers to use G729 and G711 only. Not all carriers support G722. Or put it as 3rd of 4th option. Also might try early offer on the cube.
> On Oct 8, 2018, at 10:10 AM, Carlos G Mendioroz via cisco-voip > <cisco-voip@puck.nether.net> wrote: > > 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 _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
