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,
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
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
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
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
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.
