Early media call fails if remote party answers during media streaming

[Jonathan Els]

Hi,

I have written an IVR script to handle a requirement to support playing prompts to either play prompt then handoff call, drop a call after playing, or stream a prompt as early media.

• Platform: ISR4331/K9
• Firmware: 15.5(1)S
• Call scenario:  CUBE call

I have hit one issue with the early media scenario.  I am using the following approach to initiate the playback:

proc playEarlyMedia { prompt dnis } {

    leg progress leg_incoming -p 8

    media play leg_incoming $prompt

    leg setup $dnis callInfo leg_incoming

    # proceed directly to outbound calling

    fsm setstate PLACECALL

}

The full script is attached.

With this, the media file is streamed successfully.  However, what I find is that, if the remote user answers the call while the prompt is still playing, the call fails.  However, if the prompt finishes played, the call is set up successfully.

I have attached comparative traces for successful and fails scenarios.  Can anyone suggest what I need to modify to prevent the call drop?  I'm quite sure that my requirement is contained in the CVP ringback.tcl script, but sadly I don't have access to this for reference.

Any assistance is greatly appreciated.

[Jonathan Els]

Hi Raghavendra,

Thanks, your last suggestion works, but as I mentioned, this is not meeting the requirement (I don't want to come across as ungrateful - this is progress! ) as I would like to stream this as early media, not after a connect.

I added a switch to support the scenarios where I do need the handoff:

   if { $status == "ls_000"} {

        puts "Call Setup Successful"

        switch $activeCallArray(prompt-behaviour) {

            "early-media" {

                media stop leg_incoming

                connection create leg_incoming leg_outgoing

            }

            default {

                handoff appl leg_all default

            }

        }

    } else {

        act_Abort

    }

Now, instead of 183 with media, I'm seeing the media played after a 200 OK.  However, at least this is working.

I've tested all my call flows with this change, and the only remaining issue I see is that the ANI is stripped during the process:

127389: Sep 21 15:24:46.269: //-1//AFW_:/AFW_Leg_IncomingTranslate: Tag(888) calling[+43577333030] redirect[] called[888]

127535: Sep 21 15:24:46.293: //-1//Dest:/DestOutboundCallUsingPeer: Outgoing Tag(88812) calling[] called[888]

Seems to be stripped during the process.  There are no translations applied to either of the matched dial-peers:

I presume that it's due to your suggestion for an unspecified call leg in the setup message:

leg setup $dnis callInfo

Is there a better solution than being forced to do store the ANI from the incoming leg?

proc playEarlyMedia { prompt dnis } {

    set ani [infotag get leg_ani]

    leg connect leg_incoming

    media play leg_incoming $prompt

    set callInfo(originationNum) $ani

    leg setup $dnis callInfo

    # proceed directly to outbound calling

    fsm setstate PLACECALL

}

It works, but it's ugly.   I've also lost other information in the SIP headers as this isn't preserved with this approach.

Do you have any suggestions?

[Raghavendra G V]

try with -l option you can pass incoming leg,

leg setup $dnis callInfo -l leg_incoming

Thanks,

Raghavendra

[Jonathan Els]

It didn't work.  First logged this:

130567: Oct  3 10:09:54.038: //96915//TCL :/tcl_LegObjCmd: leg setup 888 callInfo -l leg_incoming

130568: Oct  3 10:09:54.038: //96915//CSPK:/tcl_LegSetupObjCmd: leg setup 888 callInfo -l leg_incoming

130569: Oct  3 10:09:54.038: //96915//AFW_:/vtd_lg_incoming: argc 5

130570: Oct  3 10:09:54.038: //96915//AFW_:/vtd_lg_incoming: Legs [96915 ]

130571: Oct  3 10:09:54.038: //96915//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1

130572: Oct  3 10:09:54.038: //96915//CSPK:/tcl_LegSetupObjCmd: -l option is deprecated. Reference leg will be used for dial-peer matching only.

130573: Oct  3 10:09:54.038: //96915//CSPK:/C_CallSetup_Start: ControlInfo = 0x7FE696198110, callInfo = 0x7FE696093398, destination[0]=888

130574: Oct  3 10:09:54.038: //96915//CSPK:/C_CallSetup_Start: configured mode=rotary (1)

130575: Oct  3 10:09:54.038: //96915//CSPK:/C_CallSetup_Start: configured reroutemode=rotary (1)

130576: Oct  3 10:09:54.038: //-1//Call:/AFW_CallSetup_New:

And later, confirmed that it stripped ANI:

130619: Oct  3 10:09:54.040: //96915//Dest:/DestAddTransferSetupInfo:

130620: Oct  3 10:09:54.040: //-1//AFW_:/AFW_Util_CopyCallDataToCallInfo: copied 888

130621: Oct  3 10:09:54.040: //96915//Dest:/DestMatchDialPeer:

130622: Oct  3 10:09:54.040: //96915//Dest:/DestMatchDialPeer: src carrier id:, tgt carrier id:

130623: Oct  3 10:09:54.040: //96915//Dest:/DestQueuePeers: Matched peers:

130624: Oct  3 10:09:54.040: //96915//Dest:/DestPeerItemUpdatePreemptInfo:

130625: Oct  3 10:09:54.040: //96915//Dest:/DestPeerItemResetLPCORInfo:

130626: Oct  3 10:09:54.040: //-1//Dest:/DestQueuePeers:  88812

130627: Oct  3 10:09:54.040: //96915//Dest:/DestPeerItemUpdatePreemptInfo:

130628: Oct  3 10:09:54.040: //96915//Dest:/DestPeerItemResetLPCORInfo:

130629: Oct  3 10:09:54.040: //-1//Dest:/DestQueuePeers:  88813

130630: Oct  3 10:09:54.040: //-1//Dest:/DestQueuePeers: , Total(2)

130631: Oct  3 10:09:54.040: //96915//Dest:/DestDialPeerRotary:

130632: Oct  3 10:09:54.040: //96915//Dest:/DestOutboundCallUsingPeer: dest(888), numexpDest(888), numDestDigits(5)

130633: Oct  3 10:09:54.040: //96915//Dest:/DestOutboundCallUsingPeer:    prefix(44.113.14), peer tag(88812)

130634: Oct  3 10:09:54.041: //96915//Dest:/DestUpdatePreemptSetupInfo:

130635: Oct  3 10:09:54.041: //-1//AFW_:/AFW_Util_RemovePreemptInfoFromContainer: Failed to remove mlppSetupInfo from TD container

130636: Oct  3 10:09:54.041: //96915//Dest:/DestDialPeerFilter:

130637: Oct  3 10:09:54.041: //96915//Dest:/DestDialPeerFilter: Checking peer [88812]

130638: Oct  3 10:09:54.041: //96915//Dest:/DestPeerFilterRouteCode: Route Code not available

130639: Oct  3 10:09:54.041: //-1//Dest:/DestOutboundCallUsingPeer: Outgoing Tag(88812) calling[] called[888]

130640: Oct  3 10:09:54.041: //96915//Dest:/DestOutboundCallUsingPeer: Using script specified canGatewayCallID 96915 for ccCallCanGateway checking.

Guess I'll have to go back to my original workaround.  Sad to see so many gaps in this API - particularly that we can't get early media working - but at least I have a semi-working solution now.

I'd really like to have this call flow work without needing to connect the call prior to stream a media stream.  In your opinion, is this possible with the current API capabilities?

[Raghavendra G V]

Please share full logs with below debugs for original script.I belive you need to issue leg connect command before call is established.
debug ccsip all
debug voip app
debug voip ccapi inout

Early media working with your original script correct ? only issue your facing is call is failing after call handoff?

Thanks,
Raghavendra

[Jonathan Els]

Thanks for coming back to me.  I will collect everything and together for you.  As a summary on the behaviour with the original script...

When using:

leg progress leg_incoming -p 8

media play leg_incoming $prompt

leg setup $dnis callInfo

The following is observed:

• SIP call sends early media in 183 message with SDP. 
• Media is streamed.
• However, when user answers the call the prompt is still playing, the call fails.
• If the prompt completes, and the user answers the call after this, call setup is successful.
• "media stop" does not seem to work, or not at least not if invoked after matching $status == "ls_000"

Will update within the next few days as soon as I have time.

[Raghavendra G V]

In your original script you are using below code with leg_incoming
    leg progress leg_incoming -p 8
    media play leg_incoming $prompt
   leg setup $dnis callInfo leg_incoming

please collect the logs with and without handoff, act_cleanup code in below procedure.

proc act_CallSetupDone { } {

    puts "Entering act_CallSetupDone"
    set status [infotag get evt_status]

    if { $status == "ls_000"} {
        puts "Call Setup Successful"
       # handoff appl leg_all default      
       # act_Cleanup
    } else {
        act_Abort
    }
}

Thanks,
Raghavendra

[Jonathan Els]

This breaks my requirement to play early media.  I don't want to answer the call while ringing.  But I will test and share the results.  I am collecting logs for the original call where I see the software error.