[cisco-voip] Jabber region restriction issue

Mon Oct 8 10:12:16 EDT 2018

Carlos,

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.

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.

On Mon, Oct 8, 2018 at 5:25 AM Carlos G Mendioroz <tron at huapi.ba.ar> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181008/3a5e5932/attachment.html>