Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Ringback Issue with Blind Call Transfer

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.

 

//Suresh Please rate all the useful posts.
1 ACCEPTED SOLUTION

Accepted Solutions
VIP Super Bronze

Suresh,This appears to be a

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.

 

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
23 REPLIES
VIP Super Bronze

Suresh,This appears to be a

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.

 

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Thanks Deji, I'll try that

Thanks Deji, I'll try that command. 

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

//Suresh Please rate all the useful posts.
VIP Super Bronze

Ideally you should enable

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

 

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

You are the SIP master Deji.

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

//Suresh Please rate all the useful posts.

He definitely is. :)

He definitely is. :)

Please rate useful posts.

Undoubtedly ;-) 

Undoubtedly ;-) 

//Suresh Please rate all the useful posts.
VIP Super Bronze

George,I am in your shadows!!

George,

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

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

LOL, here I was thinking

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

Please rate useful posts.
VIP Super Bronze

Glad to help Suresh :) (don't

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

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Hi Deji, I think I made a

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?

//Suresh Please rate all the useful posts.
VIP Super Bronze

This suggests that the re

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

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Yes, I see the midcall

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.

//Suresh Please rate all the useful posts.
VIP Super Bronze

Your MIDCALL consumption is

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?

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

We are still not getting the

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

//Suresh Please rate all the useful posts.

When looking at the logs

When looking at the logs which was collected with MTP checked, I don't see the Reinvites coming to CUBE from CUCM for Call Hold & MoH and we heard the ringback when the call was transferred. but the calling party still heard the MoH. I couldn't understand this behaviour.

 

 

 

calling: 918066914754

called: 5816280216 (mask: 6048959000)

Transferred to 919886001322

 

 

//Suresh Please rate all the useful posts.
VIP Super Bronze

This is perfectly normal.

This is perfectly normal..

When MTP is involved, CUCM keeps the media leg between MTP and CUBE from beginning to end; when necessary, it just updates another leg of MTP between MTP and CUBE. However it looks like you have disabled UPDATES on your sip profile, so you wont even see that in the logs.

The called party should generate ring back. So that means itsp in this case.Yes packet captures will tell us if Cube is receiving ring back or not. I looked at a similar issue a few weeks back.

Does ring back work, if the transferred destination is an internal extension?

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

yes, when transferring the

yes, when transferring the external call from one ip phone to another ip phone, we hear the ringback at the original calling party phone.

 

We've blocked the update for an external voicemail issue.

//Suresh Please rate all the useful posts.
VIP Super Bronze

Okay please send the captures

Okay please send the captures once you have done them

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
VIP Super Bronze

Okay..You didn't mention what

Okay..You didn't mention what you get when you transfer the call though (silence)? or announcement from ITSP?

We will need to enable packet capture on CUBEs..

Packet capture from cube.


1. Configure capture profile

               !
               ip traffic-export profile TAC mode capture
               bidirectional
               !

               interface fa0/0  ----> Interface which routes the traffic to ITSP
               ip traffic-export apply TAC 99999999


2. Capture traffic with these exec (enable) level commands

Note: The exec cmds don’t appear until a profile has been configured

router#traffic-export interface fa0/0 clear
router#traffic-export interface fa0/0 start

Do your test and after test is complete

router#traffic-export interface fa0/0 stop

 

3. Export the pcap file to a server

router#traffic-export interface fa0/0 copy ftp://x.x.x.x/capture.pcap

 

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

ah ok, it was complete

ah ok, it was complete silence on the original calling party when the final destination was actually alerting.

 

when the transfer is completed and the destination is being alerted, is it ITSP responsibility to provide the ringback to original calling party?

if so, will we able to hear it with the CUBE packet captures?

Also I'm wondering who is generating the ringback when MTP is checked. the same ITSP or the ANN in the trunk?

//Suresh Please rate all the useful posts.

Here are the pcap & debug

Here are the pcap & debug collected for the nonworking call.

calling: 918066914754

CIPC_called: 5816280216 (mask: 6048959000)

Transferred to 919886001322

 

when the CIPC put the first call on hold, the calling party heard the MoH. when the CIPC calls the 2nd number, it hears the ringback song but when the transfer is completed, the calling party didn't hear the same song. Please check.

Renamed the pcap file extension to steu2.pps. please change the extension back.

 

 

//Suresh Please rate all the useful posts.
VIP Super Bronze

Suresh,Its been a long day.

Suresh,

Its been a long day..so sorry for the late reply. Been busy.

I have looked at the captures. Can you confirm the (I love you my sweet heart song) is the ring back that should be played during the final transfer?

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Hey Deji, same here.

Hey Deji, same here. Exhausted. 

 

Yes, you are right, that is the song should be heard by original calling party. 

//Suresh Please rate all the useful posts.
695
Views
5
Helpful
23
Replies
CreatePlease login to create content