Ringback Issue with Blind Call Transfer

[Suresh Subramanian]

Hello,

we are facing ringback issue when inbound external call to the cisco phone is transferred back to another extenal number.

Call Flow: Cisco phone----CUCM-----SIP-----CUBE----SIP----ITSP.

Investigation done:

- if both PRACK & EO are disabled, we hear the ringback on blind call transfer. In fact it is continuous ringback tone. Though the other end rejects the call, we hear this continuous ringback. Also, we don't hear any announcement played from provider side.

- If PRACK enabled & EO Disabled, same as above

- if PRACK disabled & EO enabled, same as above

- if both either PRACK and Early Offer are enabled, we don't hear the ringback during blind call transfer but we hear announcement from provider

To address both the continuous ringback & provider announcement issues, we enabled the MTP on the SIP Trunk in CUCM to CUBE.

Is there anything we can do to address these issues instead of enabling MTP on the sip trunk for all calls?

I also tried resetting the ANN and assigning dedicated ANNs in the SIP Trunk MRGL.

any help would be much appreciated. Thanks.

[Ayodeji Okanlawon · Accepted solution]

Suresh,

This appears to be a provider issue from the description. However you can do MIDCALL INVITE/UPDATE consumption, so you do not send re-INVITE to your provider which somehow is allowing them to play announcements..(your CUBE IOS needs to support this feature)

voice service voip

sip

mid-call signaling passthru media-change

Test this and let us know how it goes.

[Suresh Subramanian]

Thanks Deji, I'll try that command. 

What would be the settings (PRACK & EO) in the SIP profile? 

[Ayodeji Okanlawon]

Ideally you should enable PRACK and enable early offer support for voice and video (insert mtp if needed)

[Suresh Subramanian]

You are the SIP master Deji. Thanks a ton. That worked :)

[George Thomas]

He definitely is. :)

[Suresh Subramanian]

Undoubtedly ;-) 

[Ayodeji Okanlawon]

George,

I am in your shadows!!! ( Still read a thread of yours today..) :)

[George Thomas]

LOL, here I was thinking where you were. :)

[Ayodeji Okanlawon]

Glad to help Suresh :) (don't make my head swell too much)

[Suresh Subramanian]

Hi Deji, I think I made a mistake when testing the call day before yesterday. seems I missed out to uncheck the MTP in the SIP Trunk and made changes only to SIP Profile (EO & PRACK enabled).

When I crosschecked this today, I found the MTP was checked. when I unchecked and tried the test calls, found that the ringback issue still persists. Sorry about the wrong update.

any idea how to proceed further?

[Ayodeji Okanlawon]

This suggests that the re-INVITE consumption is not working well or has not been configurd properly. It does similar thing as the MTP does. Stops re-INVITE from going out to ITSP.

Please do a test call and send us

debug ccsip messages (include calling and called number and describe what you get) Also send sh run of your cube

[Suresh Subramanian]

Yes, I see the midcall invites are going out to ITSP. I had the midcall-signaling passthru media-change configured in global level first that didn't help. also configured it on the dial-peer level, still no luck.

I also tried midcall-signaling block in the dial-peer level that is also not working.

CUBE is 2921 with  Version 15.3(3)M.

voice service voip

 mode border-element
 allow-connections sip to sip
 redirect ip2ip
 fax protocol pass-through g711ulaw
 sip
  header-passing
  asserted-id pai
  asymmetric payload dtmf
  midcall-signaling passthru media-change
  early-offer forced
  g729 annexb-all
  sip-profiles 1

!
voice class codec 1
 codec preference 1 g711ulaw
!
voice class sip-profiles 1
 request INVITE sip-header Min-SE remove
 request INVITE sip-header Unsupported modify "Unsupported:" "timer"
 request INVITE sip-header Remote-Party-ID remove
 response 200 sip-header Remote-Party-ID remove
 request INVITE sip-header P-Asserted-Identity modify ">" ";user=phone>"
 request INVITE sip-header From modify ">" ";user=phone>"
 request INVITE sip-header Min-SE remove
 request ANY sip-header Allow-Header modify "UPDATE, " ""
 response ANY sip-header Allow-Header modify "UPDATE, " ""
!

!
dial-peer voice 100 voip
 description ** Incoming Calls From CUCM **
 answer-address .T
 voice-class codec 1
 voice-class sip g729 annexb-all
 voice-class sip early-offer forced
 voice-class sip profiles 1
 no voice-class sip midcall-signaling passthru media-change
 voice-class sip midcall-signaling block
 dtmf-relay rtp-nte
 dtmf-interworking standard
 fax-relay ecm disable
 fax-relay sg3-to-g3
 fax protocol pass-through g711ulaw
 ip qos dscp af21 signaling
 no vad
!
dial-peer voice 101 voip
 description ** International Outbound Calls to TELUS **
 destination-pattern 011T
 session protocol sipv2
 session target ipv4:172.27.50.23
 voice-class codec 1
 voice-class sip g729 annexb-all
 voice-class sip early-offer forced
 voice-class sip profiles 1
 voice-class sip bind control source-interface GigabitEthernet0/1
 voice-class sip bind media source-interface GigabitEthernet0/1
 no voice-class sip midcall-signaling passthru media-change
 voice-class sip midcall-signaling block
 dtmf-relay rtp-nte
 fax-relay ecm disable
 fax-relay sg3-to-g3
 fax protocol pass-through g711ulaw
 ip qos dscp af21 signaling
 no vad
!
dial-peer voice 102 voip
 description ** National Outbound Calls to TELUS **
 destination-pattern 1..........
 session protocol sipv2
 session target ipv4:172.27.50.23
 voice-class codec 1
 voice-class sip g729 annexb-all
 voice-class sip early-offer forced
 voice-class sip profiles 1
 voice-class sip bind control source-interface GigabitEthernet0/1
 voice-class sip bind media source-interface GigabitEthernet0/1
 no voice-class sip midcall-signaling passthru media-change
 voice-class sip midcall-signaling block
 dtmf-relay rtp-nte
 fax-relay ecm disable
 fax-relay sg3-to-g3
 fax protocol pass-through g711ulaw
 ip qos dscp af21 signaling
 no vad
!
dial-peer voice 103 voip
 description ** Local Outbound Calls to TELUS **
 destination-pattern [2-9].........
 session protocol sipv2
 session target ipv4:172.27.50.23
 voice-class codec 1
 voice-class sip g729 annexb-all
 voice-class sip early-offer forced
 voice-class sip profiles 1
 voice-class sip bind control source-interface GigabitEthernet0/1
 voice-class sip bind media source-interface GigabitEthernet0/1
 no voice-class sip midcall-signaling passthru media-change
 voice-class sip midcall-signaling block
 dtmf-relay rtp-nte
 fax-relay ecm disable
 fax-relay sg3-to-g3
 fax protocol pass-through g711ulaw
 ip qos dscp af21 signaling
 no vad
!

we have 2 cubes with active-active connection. so in the nonworkingscr.txt is the one receives the call first from provider and nonworkingsteu.txt is the one you can see the 2nd call sent back to provider.

calling: 918066914754

called: 5816280216 (mask: 6048959000)

Transferred to 918066914714.

Note: These logs are captured when midcall signalling passthrough is configured only on global level. not in dial-peers.

keeping the global config, I tried the passthrough in dial-peer level, that didn't work, so removed it and added the blocking command in the same dial-peers. so you will see both in the config pasted above.

[Ayodeji Okanlawon]

Your MIDCALL consumption is definitely working. If you look at the logs, there are several re-INVITEs between 157.171.4.27 and 153.112.89.13, which were not sent to the ITSP. There is only one re-INVITE sent to the ITSP which is the final part to connect the transferred endpoint.

So what do you get with the mid call consumption in place? Do you still get announcement from the provider?

[Suresh Subramanian]

We are still not getting the ringback when transferring the call back to ITSP. That's the issue.