Cannot resume audio after failed call-transfer

I've found a major problem when doing SIP REFER call transfer between two gateways.

Gateway A has a call (actually from FXS port) with gateway B, which runs CME.

Now gateway B wants to blind transfer this call, and attempts a call setup with callInfo(mode) set to redirect.

If the destination number is invalid, the transfer setup fails with ls_054.

That is fine but when re-conferencing the call to FXS port, there is one way audio, that is user on B cannot hear user on A.

That happens because in the early stage of the call transfer, gateway A sends SIP INVITE with SDP a=recvonly to B,

as confirmed by receiving  an undocumented event ev_suspend_ack, and never sends a=sendrecv to resume two way audio.

When this happens, the leg state is lg_005.

If the call to be transferred is between users on GW A, there is no problem, as in fact there is no SIP at all.

How a script can resume audio in this scenario ?

I have tried few things to no avail, including a new transfer request toward the original endpoint, but it seems that IOS still consider the leg in transfer state:

%SIP-3-BADPAIR: Unexpected event 27 (SIPSPI_EV_CC_CALL_TRANSFER) in state 20 (SIP_STATE_INIT_XFER) substate 0 (SUBSTATE_NONE)

Can we do something on GW A ? Like changing sip-profile audio attribute to sendrecv ?

Thanks, will try that.

Need to correct myself: it's GW A that tries to transfer.

Tried that, doesn't work. It appears that SIP profiles are not applied to the "susped audion" INVITE.

Any input from Cisco ?

Could you please collect the logs with below debugs and let us know which IOS version you have an issue.

debug voip app
debug ccsip all
debug voip ccapi inout

Thanks,
Raghavendra

Find attached the trace. Blind transfer to '26' fails, the incoming call (from 203) is resume, there is no audio, you can see some DTMF digits that are not heard at destination.

IOS is 15.1(4)M9, but it happes with any IOS version including 15.4.

It was not possible to take "debug ccsip all" because that causes the script to not work at all, so  "debug ccsip message" has been used instead.

Thanks, Paolo.

From the logs found that you are issuing leg setup with incoming leg  and doing connection create, you dont need to connection create.

Jul 31 19:36:16.050: //1589//TCL :/tcl_LegObjCmd:  leg setup 26 callInfo 1589
Jul 31 19:36:16.050: //1589//CSPK:/tcl_LegSetupObjCmd: leg setup 26 callInfo 1589

Jul 31 19:36:19.910: //1589//AFW_:/AFW_FSM_Drive: ACTION BEGIN: ------(RECALL[3],ev_setup_done[219])---[recallSetupDone]------
Jul 31 19:36:19.914: //1589//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
Jul 31 19:36:19.918: //1589//TCL :/tcl_ConnectionObjCmd:  connection create 1593 1589
Jul 31 19:36:19.918: //1589//TCL :/tcl_ConnectionCreateObjCmd: create 1593 1589

Thanks,
Raghavendra

As explained before, the failure is in conjunction with a SIP call transfer. In this scenario in order to transfer a leg that is part of a connection one needs to issue "connection destroy" first, then after the transfer failure it is necessary to re-conference the original legs with "connection create". That is why you see the connection create command, it is issued after the "connection setup" command has failed. Without this commend there would be no audio path at all.

As per the log script got ls_000, what do you mean by transfer failure. Could you please share your script.

Jul 31 19:36:19.910: //1589//AFW_:/AFW_FSM_Drive: ACTION BEGIN: ------(RECALL[3],ev_setup_done[219])---[recallSetupDone]------

Jul 31 19:36:19.910: //1589//TCL :/tcl_InfotagObjCmd:  infotag get evt_status

Jul 31 19:36:19.910: //1589//TCL :/tcl_InfotagGetObjCmd: infotag get evt_status

Jul 31 19:36:19.910: //1589//AFW_:/vtr_ev_status: argc 2 argindex 2

Jul 31 19:36:19.914: //1589//TCL :/tcl_InfotagObjCmd:  infotag get evt_legs

Jul 31 19:36:19.914: //1589//TCL :/tcl_InfotagGetObjCmd: infotag get evt_legs

Jul 31 19:36:19.914: //1589//AFW_:/vtr_ev_legs: argc 2

Jul 31 19:36:19.914: //1589//AFW_:/vtr_ev_legs: EVCALLID [1593]

Jul 31 19:36:19.914: //1589//TCL :/tcl_PutsObjCmd: dsapp-mlpp: recallSetupDone ls_000 legs 1593 legIDs: standby 1589

Thanks,

Raghavendra

The script prints all status with puts, but for some reason when the debugs above are enabled, some output is missing. So you did not see ls_054 for transfer failure. To see it,  enable "debug voice application script" only.

Below the simplest script that reproduces the problem. Destination is supposed to be an FXS port. As soon the call is answered, a blind transfer is attempted to the number configured with param xferTo. When it fails, leg are re-conferenced but there is one way audio because the remote gateway is still place in recvonly mode.

proc setup {} {leg setup [infotag get leg_dnis] callInfo leg_incoming}

proc iSetupDone {} { connection destroy con_all }

proc destroyDone {} {

  set callInfo(mode) redirect

  leg setup [infotag get cfg_avpair xferTo] callInfo leg_incoming

}

proc xSetupDone {} {

  puts -nonewline "[infotag get evt_status]"

  if {[infotag get evt_status] != "ls_041"} {connection create leg_incoming leg_outgoing}

}

proc disc {} {call close}

set fsm(I,ev_setup_indication) {setup same_state}

set fsm(I,ev_setup_done) {iSetupDone I}

set fsm(I,ev_destroy_done) {destroyDone X}

set fsm(X,ev_setup_done) {xSetupDone same_state}

set fsm(any_state,ev_disconnected) {disc same_state}

fsm define fsm I

Thanks for sharing the script, let me check with Dev team and get back to you.

Thanks,

Raghavendra

Thank you for your attention.

I've made progress on this issue. I've changed callInfo(mode) from redirect to redirect_rotary. Doing so causes two important things for a transfer failure, first ls_003 code is returned instead of ls_05xx.

And second, if the transfer is a SIP REFER, audio is resumed, with and ev_resume_ack received by the script, so re-conferencing works fine.

Now I'm not sure if there is a good reason to resume audio only in redirect_rotary mode, but fortunately that works for me

Thanks for Information, good to know that you were able to resolve the issue.

Thanks,

Raghavendra

Can you gather from developers the reason why resume is not performed when callIInfo(mode) is set to rotary, and if shouldn't, a bug be filed as isn't ?

I am yet to get answer from Dev Team, once i got the response i will share.Any issues with redirect_rotary mode.

Thanks,
Raghavendra

Raised Bug  (CSCuv73176)  for this issue.

Thanks,

Raghavendra

Thank you Raghavendra.

For which IOS version you have issue is it 12.x , because from logs I saw below message.

User-Agent: Cisco-SIPGateway/IOS-12.x

Thanks,

Raghavendra

For which IOS version you have issue is it 12.x , because from logs I saw below message.

User-Agent: Cisco-SIPGateway/IOS-12.x

As mentioned before, the problem happen with any IOS version, and the traces were taken with the script running under IOS 15.1

The remote gateway was running 15.2 but that is immaterial, because the bug is in the router running the script.