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
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
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
FTR, this proved to be tough on me.
And I thought I knew something about it :)
Ended up removing a force rtp-nte that was there, and adding sip-kpml as
an alternative on the CUBE (performing as a CME in this case too).
And changed the sip profile on the CUCM to do Early offer (best effort).
HTH
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
> wrote:
>
> Grr,
> now that MTP is not forced,