[cisco-voip] Jabber region restriction issue
Carlos G Mendioroz
tron at huapi.ba.ar
Mon Oct 8 12:10:04 EDT 2018
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
More information about the cisco-voip
mailing list