Solved: SIP provider, CUBE and CUCM7.0. inbound works, outbound fails

ant.work · ‎07-31-2009

I seem to be going round in circles and would like some pointers.

We have a SIP provider connected via a VPN (so no SIP authentication), an 2811 acting as CUBE and CUCM 7 with SCCP phones and a SIP trunk to CUBE.

Voice Class Codec on CUBE with G729r8, G711Ulaw & G711Alaw preferenced in that order.

Inter-region CODEC between SIP trunk and Phones set to G729.

Route pattern on CUCM is doing all digit manipulation for outbound (striping predot) so full UK number sent to SIP provider.

Inbound calls work fine and connect at g729 regardless of the inter-region Codec (729 or 711), expected behavior.

Outbound is my problem. Call is routed, end phone rings (maybe) and the call is dropped...regardless of inter-region codec.

SIP tracing and debugging shows that on the 183 session progress sent by SIP provider, the gateway, or trunk sends a cancel with Q.850 disconnect 65 - The equipment sending this cause does not support the bearer capability requested.

In the CCSIP mess debugs you see the SDP message sent to provider and the codec requested is always G711Ulaw, regardless of inter-region codec and or contents of voice class codec.

so it appears to be media negotiation is at fault but i am at a loss to resolve this.

Not sure if i need MTP/Xcode resource so i have made both available on the CUCM to no avail (i think this is DTMF relay stuff, haven't tgot that far yet, plain voice would be nice!!). I have tied the codec down on the dialpeers even tried CODEC TRANSPARENT (even though docs say for h323 only), nothing.

Now for the funny, if I configure a gatekeeper controlled trunk on CUCM and configure the CUBE to register to GATEKEEPER and use the GK trunk for outbound calls it works with inter-region of G711, but again not with G729 although the failure this time is that teh call is dropped when remote end answers!!!!

So does anyone please have an idea of where i can look next, i can't be far off as inbound works

IOS is SPSERVICES 12.4.24.T1

Nicholas Matthews · ‎07-31-2009

A few things:

In CUCM 7.0, this was the first version that allowed outgoing SIP trunks to use G.729 with an MTP. It sounds like you don't have it enabled so you're doing delayed offer.

The suggestion is to use DO-EO conversion with CUBE with the 'early offer forced' configuration on the outgoing dial peer.

Then on your dial peer you can set the codec there. I would check a few things:

1) Codec g729r8 is higher on your voice class codec list

2) Your outgoing and incoming dial peers have the same voice class codec defined

You can also try 'codec transparent' on both dial peers. Note: you cannot use EO-DO with codec transparent.

hth,

nick

View solution in original post

Nicholas Matthews · ‎07-31-2009

A few things:

In CUCM 7.0, this was the first version that allowed outgoing SIP trunks to use G.729 with an MTP. It sounds like you don't have it enabled so you're doing delayed offer.

The suggestion is to use DO-EO conversion with CUBE with the 'early offer forced' configuration on the outgoing dial peer.

Then on your dial peer you can set the codec there. I would check a few things:

1) Codec g729r8 is higher on your voice class codec list

2) Your outgoing and incoming dial peers have the same voice class codec defined

You can also try 'codec transparent' on both dial peers. Note: you cannot use EO-DO with codec transparent.

hth,

nick

ant.work · ‎07-31-2009

thanks for the reply,

so i need to add

voice-class sip early-offered forced

to the outbound dial peer? the voice class is already the same for all dial peers

voice class codec 1

codec preference 1 g729r8

codec preference 2 g711ulaw

codec preference 3 g711alaw

tried codec transparent to no avail

will try this now

Anthony

Nicholas Matthews · ‎07-31-2009

To be honest - there are about 30 reasons why this may not be working. A 'debug ccsip message' is the best place to start.

-nick

ant.work · ‎07-31-2009

FIXED!!!!

The delayed-offer to Early-offer conversion worked. going to do a little more testing but i think its cracked.

i have enclosed a debug CCSIP message trace for a failing call for peoples information.

Nicholas Matthews · ‎07-31-2009

Glad I could help :)

I would recommend rating posts so that others can find solutions easier.

-nick