SIP Re-invite with multiple codecs

[Redash6174183]

Hi Team

ı have case with our provider  that he cliams that the re-invite message contains only g711alaw but we want to send two codec with sdp (g711alaw and ulaw) How can we do that ?

 below is the mesage for ITSP

"Checked via trace  The B party number 011-xxxx generate the RE-INVITE message and for Code only have the PCMU voice codec.So please check IPPBX for the RE-INVITE message , and also allow the PCMA and PCMU both voice codec"

Is it possible to send two codec with re-invite ? is it required in cucm or Cube

[Roger Kallberg]

Try adding offer-all to the codec list command on the outbound dial peer. For more information please see this document Cisco Unified Border Element Configuration Guide Through Cisco IOS XE 17.5 

[Redash6174183]

In the dial-peer I already added voice-class codec 1 which includes all required codecs 

voice class codec 1
codec preference 1 g711alaw
codec preference 2 g711ulaw
codec preference 3 g729r8

Is this being used in Re-Invite messages ? because I see in SIP message only 0 and 101   (8 is not there)

[Roger Kallberg]

Do you have this on your outbound dial peer?

voice-class codec 1 offer-all

[Redash6174183]

No , only voice-class codec 1.

will add it and check the result . Thanks so much

[TechLvr]

Can you please explain what is the issue experienced at the user level?

Unless there is a specific requirement, you don't really have to send re-invite messages to the ITSP. You can do this by blocking mid-call signaling using the following commands on the CUBE. Your MOH and call transfers will still work as expected.

voice service voip
sip
midcall-signaling block

With the above configs, the CUBE will consume the Re-Invite messages instead of passing them on to the ITSP.

For example, when you receive an inbound call from the ITSP. You answer the call and place it on hold. As soon as you press hold, here is what happens.
CUCM sends a Re-Invite W/ SDP (inactive) message to the CUBE
CUBE consumes the Re-Invite and stops sending RTP to CUCM
CUBE does not send a Re-invite to the ITSP, so the ITSP facing leg of the call remains unaffected
The CUCM then Sends a re-invite with delayed offer
CUBE sends a 200 OK with SDP
CUCM sends MOH to the CUBE
CUBE sends MOH traffic to the ITSP facing call leg of call
Once the call is removed from hold, a few more messages are exchanged between CUCM and CUBE before RTP is connected in both directions again.

Please see screenshot below as an example.