Whats the ideal way to prevent SIP Re-invite options when CUC transfers calls

[sam saeed]

ITSP SIP->SIP TRUNK>CUBE>SIP TRUNK>CUCM>SCCP TRUNK>CUC AA

I have been having a one-way audio issue when the originating call is from an outbound caller intiates a transfer through the Auto Attendant. I took a look at the debug ccsip messages and see that the CUCM is sending a re-invite to the SIP provider once CUC transfers the call back to CUCM. Which ends up as the CUCM sending an inactive sdp status back to the provider and the providre replying with an OK still in an inactive state. I know that this call flow is not correct as the call transfers should not need to be handled with the provider.

I did some reading and I found by configuring MTP on the IOS CUBE it should consume the re-invite.

I also found an article that mentioned using this method when using a 3rd party SIP PBX passing through CUBE which used these commands:

sip
        midcall-signaling block
        <blocks all midcall media from passing through>
        or
        midcall-signaling passthru media-change
         <if any dsp transcoding is done then a dsp may be used only sends video or fax media>

 no supplementary-service sip refer
supplementary-service media-renegotiate

Which from my understanding can be used to consume and/or block the re-invite from the CUCM. This is my first deployment with a CUCM platform so I am not 100% sure which is the best way to take to address the re-invite issue. I know I had a similar issue with CME when AA in CUE transfers. This issue was resolved with the command:

no supplementary-service sip refer

Is this a common problem with CUBE,CUCM,SIP trunk deployments? Which method is traditionally used for CUCM, CUBE, Sip trunk deployments?

Thanks

[sam saeed]

To add I confirmed that the one-way audio issue is resolved when midcall-signaling passthru media-change or midcall-signaling block is entered on the CUBE router. I am just curious to see if this is a common issue people run into and is entering those commands the best way to get the CUBE to prevent sending a SIP invite mid call to the provider.

[Nadeem Ahmed]

did you tried configuring the below command under voice service voip >sip

#voice service voip

# sip

#mid-call signaling block

you can perform the same at dial-peer level

Blocking SIP Messages at Dial Peer Level

Perform this task to block SIP messages at dial peer level.

Note	If the Cisco UBE Mid-call Re-INVITE/UPDATE consumption feature is configured on global and dial-peer level, dial-peer levels takes precedence.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    dial-peer voice dial-peer tag voip

4.    mid-call signaling block

5.    exit

Br,

nadeem

PS: Please rate all useful post.

[Jorge Armijo]

David,

The commands you mentioned will actually prevent the mid-call reINVITE to change the media status (inactive, sendonly, receiveonly, inactive). Hoewver, it does not neccesarily means it is a problem with the CUBE, CUCM, etc. Most of the time, the Carrier is not capable to renegotiate the media attributes correctly and hence we have one way or no audio at situations.

The commands can be added, however, without the proper logs we cannot identify what the actual cause of the issue is and provide a good RCA + a solution/workaround.

Mid-call reINVITEs are perfectly fine and expected on transfers or HOLD/RESUME scenarios, the problem appears when one of the devices in the flow cannot process the requests properly.

HTH

~jorge

[sam saeed]

Hi attached the debug with break down of SIP flow. While the media-signaling did remedy the one-way audio issue I noticed the moh was playing at the same time while the call was active. Seems like that solution may be preventing it from seeing the call transfer actually happening to let go of the moh audio stream.

Before my "fix" the provider got back with me saying that all I need to do is send a re-invite which included SDP it will prompt them to send a 200 OK with SDP. That sounds like it'll be some customizing with the voice sip profile on the cube.

I found an article which mentioned these which sounds like my exact issue. Are these 2 request lines all I need to get it working?

One-way / No-way Audio Interoperability Issues with Provider

voice class sip-profiles 200
request ANY sdp-header Audio-Attribute modify "a=inactive" "a=sendrecv"
request ANY sdp-header Audio-Connection-Info modify "0.0.0.0" "CUBE's IP"

[pradorobin]

Thanks for the helpful information in this post! I've had intermittent one-way audio problems on inbound calls for the past several weeks since moving to new SIP trunks for all call traffic in and out. Being new to SIP traces, I've had my head swimming with all the details contained in a trace. After reading many posts on the topic of one-way audio (along with many other things), and capturing many sample traces, I tried applying "midcall-signaling passthru media-change" to global commands on CUBE, but that immediately increased our issues, taking the calls from intermittent one-way audio to No audio, and immediately reversed the commands!
I searched more, and came across this post. Additional review of call traces revealed that the issue described here was our exact situation, where the midcall Re-INVITE showed c=IN IP4 0.0.0.0 and a=inactive statements. Epiphany!

I applied the changes noted here, and my issues appear to be fixed! Thank you SOOOO much.

voice class sip-profiles 1
request ANY sdp-header Audio-Attribute modify "a=inactive" "a=sendrecv"
request ANY sdp-header Audio-Connection-Info modify "0.0.0.0" "CUBE's IP"

[Theofilos Tzachristas]

That worked for me. Thanks for sharing

[sam saeed]

Hi Jorge,

Have you been able to take a look at my logs?

[sam saeed]

Update:

Issue seemed to be resolved by combination of changes. I first removed the midcall-signaling command to prevent any intervention of the call state. I changed the sdp-headers I mentioned earlier to see if it was the fix I applied these commands:

voice class sip-profiles 1
 request ANY sdp-header Audio-Attribute modify "a=inactive" "a=sendrecv"
 request ANY sdp-header Audio-Attribute modify "a=sendonly" "a=sendrecv"
 request ANY sdp-header Audio-Attribute modify "a=recvonly" "a=sendrecv"
 request ANY sdp-header Audio-Connection-Info modify "c=IN IP4 0.0.0.0" "c=IN IP4 10.10.10.1"

dial-peer voice 9 voip
voice-class sip profile 20
!

Issued debug ccsip messages

Tested call: still same results

I noticed that the sdp-headers were changed but media was still not sent from the cucm. I came across this posting with a similar issue.

https://supportforums.cisco.com/discussion/12262941/one-way-audio-after-call-put-hold

It mentioned two changes needed to be made. It required enabling a duplex streaming in service parameters and changing some sip profile options to send the media during midcall.

Under Service Parameters:

On CUCM go to System--- Service Parameters and look for "Duplex Streaming Enabled" set this to TRUE and restart the CCM service.

Under SIP Profile:

Early Offer support for voice and video calls (insert MTP if needed)

 Send send-receive SDP in mid-call INVITE

I applied both, assigned it Device SIP trunk and restarted the trunk and cm service.

On the CUBE I removed the voice sip profile that I previously configured and issued debug ccsip messages.

Tried test call

Result: Same issue-one way audio

I looked at the debug and see the media was being sent as either send only or receive only. Which shows the one way audio in action.

Excerpt of debug:

v=0
o=CiscoSystemsSIP-GW-UserAgent 9478 9042 IN IP4 10.10.10.1
s=SIP Call
c=IN IP4 10.10.10.1
t=0 0
m=audio 16534 RTP/AVP 0 101
c=IN IP4 10.10.10.1
a=recvonly
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

o=CiscoSystemsCCM-SIP 12201 6 IN IP4 10.10.10.231
s=SIP Call
c=IN IP4 10.10.10.14
b=TIAS:64000
b=CT:64
b=AS:64
t=0 0
m=audio 4000 RTP/AVP 0 101
a=ptime:20
a=rtpmap:0 PCMU/8000
a=sendonly
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

I added the voice sip profile back into cube to send headers as sendrecv to maintain bidirectional state:

voice class sip-profiles 1
 request ANY sdp-header Audio-Attribute modify "a=inactive" "a=sendrecv"
 request ANY sdp-header Audio-Attribute modify "a=sendonly" "a=sendrecv"
 request ANY sdp-header Audio-Attribute modify "a=recvonly" "a=sendrecv"
 request ANY sdp-header Audio-Connection-Info modify "c=IN IP4 0.0.0.0" "c=IN IP4 10.10.10.1"

dial-peer voice 9 voip
voice-class sip profile 20
!

debug ccsip messages

Test call

Result: Bidirectional call is successful after transfer.

[Ayodeji Okanlawon · Accepted solution]

Hi David, Yes this is an issue with some providers who cannot process the re-INVITE that CUBE sends for change in media properties. I have worked an an exact same issue and it was resolved by using midcall-signalling passthru media-change

Here is a little analysis I did when I worked on a similar issue..

Call flow:

ITSP----SIP—CUBE---sip—CUCM—sip—Unity connection

 Midcall—Consumption VS Normal Re-INVITE

The sip ladder below shows the graph for a normal RE-INVITE. In this flow the ff happens

1.        CUCM sends a re-INVITE to break media path, CUBE sends this re-INVITE to ITSP
2.        CUCM sends a re-INVITE to play ring back/moh, CUBE sends this to ITSP
3.        CUCM sends a DO re-INVITE to connect CUBE to the transferred party, CUBE DO re-INVITE to ITSP

The sip ladder below is for a call with mid call INVITE consumption configured

voice service voip

sip

midcall-signaling passthru media-change

In this call flow, CUBE doesn’t send a re-INVITE until the call has been transferred to the destination to connect to the transferred party ( this is the only time the media has changed, because CUBE has received a new connection parameter in the SDP from CUCM (c=ip address of transferred phone, this parameter was ip of unity connection ). All the other re-INVITE for media break, ringback is held between CUBE and CUCM and never sent to the ITSP

I personally prefer to use the midcall/re-INVITE consumpption rather than using sip profiles.

[sam saeed]

Thank you for your detail graphs!

Why do you prefer to use midcall/re-INVITE consumption rather than using sip profiles?

Technically I could've called it case closed on Monday when I found the midcall-signaling passthru media-change commands to get it working but I was hesitant using it since its a disclaimer that I read when using these options.

Note	This feature should be used as a last resort only when there is no other option in CUBE.

After reading your explanation it definitely gave me piece of mind and I think I may use the mid-call method versus the other method with sip profiles. I do find it cool that I found alternatives to solve the same issue.

In the call flow diagram are you using the sip messages from CUBE? Or is that the cucm traces placed into translator X? Mind sharing what you used and how you did it if those are from the CUBE debugs.

Thanks

[Ayodeji Okanlawon]

It is nice to have multiple options. So I totally agree. The sip profile solution just looks a little cumbersome to me. 

It's the cube logs I used. It's pretty simple to do. Just import your logs into translatorX and filter based on either call Id, calling number etc. Then generate the graph. 

[sam saeed]

Wow did not know I could've sorted through the debugs from CUBE much easier! Thanks again I reference your different posts quite often you really know your stuff. 

[Ayodeji Okanlawon]

David,

Its my pleasure and thanks for the compliment. We learn from each other.

If you interested I wrote a new document on dissecting CUCM traces and I did mention a few things about translatorX ( you can do more than you think with it). So have a peep when you get a chance.

https://supportforums.cisco.com/document/12724111/understanding-cucm-traces-end-end

[sam saeed]

I just took a look at your write up and dude this is like the holy grail of troubleshooting!  You had me at:

catapult yourself into another realm of knowledge, passion and ecstasy with CUCM traces :)

This alone will help me bring my troubleshooting skills to where it needs to be.

Thanks again!