[cisco-voip] Jabber region restriction issue

Kent Roberts kent at fredf.org
Mon Oct 8 12:17:26 EDT 2018


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 at 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.albler at gmail.com <mailto:bernhard.albler at 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 at puck.nether.net <mailto:cisco-voip at 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 at 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 at 10.0.100.2
>>>        <mailto:sip%3A3560 at 10.0.100.2>>;tag=36658~4fdda745-cceb-4407-a170-1420de65d7d7-22052972
>>>        To: <sip:947930020 at 10.0.100.1 <mailto:sip%3A947930020 at 10.0.100.1>>
>>>        Date: Sun, 07 Oct 2018 20:45:59 GMT
>>>        Call-ID: fd98a300-bba17087-1b99-264000a at 10.0.100.2
>>>        <mailto:fd98a300-bba17087-1b99-264000a at 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 at 10.0.100.2
>>>        <mailto:sip%3A3560 at 10.0.100.2>>
>>>        Remote-Party-ID: <sip:3560 at 10.0.100.2
>>>        <mailto:sip%3A3560 at 10.0.100.2>>;party=calling;screen=yes;privacy=off
>>>        Contact:
>>>        <sip:3560 at 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  <tron at huapi.ba.ar
>>>        <mailto:tron at huapi.ba.ar>>  LW7 EQI  Argentina
>>>        _______________________________________________
>>>        cisco-voip mailing list
>>>        cisco-voip at puck.nether.net <mailto:cisco-voip at 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 at puck.nether.net <mailto:cisco-voip at puck.nether.net>
>>>    https://puck.nether.net/mailman/listinfo/cisco-voip
>>> 
>> 
> 
> -- 
> Carlos G Mendioroz  <tron at huapi.ba.ar>  LW7 EQI  Argentina
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip



More information about the cisco-voip mailing list