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

Reply via email to