cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4778
Views
15
Helpful
6
Replies

Re-Invite for Outbound SIP Calls

shibinkumaric
Level 1
Level 1

Hello Experts,

Need your assistance to identify the root cause of one issue which I am facing. I have noted that whenever we make an OB call , a Re-Invites happen even though there is no codec mismatch / hold or transfer. Call flow is as given below

 

IP phone -Leaf cluster -SME-CUSP-CUBE-SIP trunk to Service provider

 

Service provider responds with 183 session progress with SDP for initial INVITE , CUBE send PRACK response with SDP to Service provider and forward the 183 session progress to SME via CUSP. SME responds to PRACK with SDP but it uses SME IP address in the SDP [C=IN IP4 xx.xxx.xx.xx(SME IP)] instead of the Originating Cisco IP phone IP address . Service provider sends 180 ringing and then 200OK response. When SME receives 200 OK it sends ACK with out SDP and then send a Re-Invite. 

There are no MTPs/ Transcoders configured in SME so I would like to know why is it using its IP address in the SDP instead of phone IP. It also include the below attribute in SDP

a=X-cisco-media:nomedia

a=send only

a=mid:1

 

1 Accepted Solution

Accepted Solutions

Jonathan Schulenberg
Hall of Fame
Hall of Fame
This is interesting. So both CUBE and SME respond to the provider’s early media directly instead of passing the 183 all the way back to the leaf to PRACK. I guess that makes sense: a “normal” ACK doesn’t wait for subsequent hops in the call path to process as a request or response would.

May I ask why both the CUCM leaf and SME clusters do not have Early Offer Best Effort enabled? That would have avoided all of this by including SDP in the initial INVITE from the leaf.

View solution in original post

6 Replies 6

Jonathan Schulenberg
Hall of Fame
Hall of Fame
This is interesting. So both CUBE and SME respond to the provider’s early media directly instead of passing the 183 all the way back to the leaf to PRACK. I guess that makes sense: a “normal” ACK doesn’t wait for subsequent hops in the call path to process as a request or response would.

May I ask why both the CUCM leaf and SME clusters do not have Early Offer Best Effort enabled? That would have avoided all of this by including SDP in the initial INVITE from the leaf.

Hi Jonathan,

 

Thank you for your response, enabling Early offer best effort on CUCM leaf or SME would need a MTP resource right ? 

 

Regards,

Shibin

Hi Shibin,

Not necessarily if you use Best Effort Early Offer as mentioned below:


Best Effort Early Offer [Early Offer support for voice and video calls Best Effort (no MTP inserted)]
Best Effort Early Offer can be enabled on the SIP Profile associated with the SIP trunk, and it is the recommended configuration for all Unified CM and Unified CM Session Management Edition (SME) trunks. Best Effort Early Offer trunks never use MTPs to create an Early Offer and, depending on the calling device, may initiate an outbound SIP trunk call using either Early Offer or Delayed Offer. Best Effort Early Offer SIP trunks support voice, video, and encrypted calls.

Best Effort Early Offer SIP trunks send outbound calls with an Early Offer (INVITE with SDP content) in the following situations:

An inbound call to Unified CM or SME is received over a SIP trunk using Early Offer.
An inbound call to Unified CM or SME is received over an H.323 trunk using Fast Start.
An inbound call to Unified CM or SME is received over an MGCP trunk.
A call is initiated from a SIP-based IP phone registered to Unified CM.
A call is initiated from a newer model SCCP-based Cisco Unified IP Phone registered to Unified CM.
Best Effort Early Offer trunks send outbound calls with a Delayed Offer (INVITE without SDP content) in the following situations:

An inbound call to Unified CM or SME is received over a Delayed Offer SIP trunk.
An inbound call to Unified CM or SME is received over an H.323 Slow Start trunk.
A call is initiated from an older model SCCP-based IP phone registered to Unified CM.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab11/collab11/trunks.html#pgfId-1342241

HTH

Rajan
Pls rate all useful posts

Hi Team

ı have a smilar case with our provider we need to send multiple codec with re-invite that mean cube is sending only g711alaw but we want to send two codec with sdp (g711alaw and ulaw) How can we do that ?

Is it possible to send two codec with re-invite

 

By the way I have configured

 

sip
midcall-signaling passthru media-change

 

 

Thanks

Have you done that ?

 Hi Redash

 

I have do like this then  it worked for me. The only these two codec will be send to itsp please apply this outbound direction to itsp call leg.

 

voice class-codec 2
codec preference 1 G711alaw
codec preference 1 G711ulaw

Thanks