Troubleshoot Session Refresh Timer with Cisco Customer Voice Portal

Introduction

This document describes Cisco Customer Voice Portal's (CVP) role and limitations with respect to Session Refresh parameter of the call.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on these software and hardware versions:

• CVP 11.6

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background Information

CVP acts as a Back to Back User Agent(B2BUA) between Ingress and VoiceXML (VXML) gateway, Cisco Unified Communications Manager (CUCM) or any other Egress endpoint. Session timer is negotiated between two end-points on either side of CVP. It passes all headers from one leg to another.

There are three points in a call where CVP initiates REINVITE towards ingress leg on its own:

1. After IVR is done, CVP sends REINVITE to caller side for ringback.
2. After Agent (or subsequent agent leg due to re-query) answers, CVP sends REINVITE towards ingress leg
3. After Whisper is done, CVP sends REINVITE towards ingress leg.

Problem

If there was previous session timer negotiated between ingress and IVR end-point (with CVP in-between), if CVP skips session timer related headers in the REINVITE, endpoints can assume other endpoints as Refresher. As a result, call gets dropped because of old session expires (Eg: Call drops at 30 min). This diagram depicts the scenario:

With CVP 11.6, CVP takes care of session headers in the listed cases. In all other cases, CVP can transfer these headers from one leg to another leg. 

 case   Ingress-UAC           refresher parameter      refresher parameter

         support              in request               in response

  ------------------------------------------------------------------

  1          Y                  none                  uas or uac

  2          Y                  uac                    uac

  3          Y                  uas                    uas

These are the changes incorporated when agent answers:

1. CVP determines what agent leg is answering with and based on what is in the answer request, it determine what must be sent to ingress within the header.
2. When CVP reinitiates the REINVITE towards Ingress (CVP initiated for agent-transfer or after whisper done), it assigns the role to ingress based on what is received in the 200 OK from CUCM. Details in table 1.1.
3. For the INVITE sent to whisper leg, you can either ignore or set the refresher based on what is received in 200 OK from CUCM.  Whisper leg has 15s timer on the VXML gateway. Hence it is not an issue.

Here are the various cases when agent leg answers the call (without whisper):

Table 1.1

From table 1.1, CVP can determine role of agent-side when it receives 200 OK. For all cases, the REINVITE towards ingress flip the role to ensure refresher is taken care of.

When whisper is enabled, Agent leg is already answered (INVITE/200/ACK exchanged), CVP sends REINVITE towards ingress and once 200 OK received, REINVITE is sent to agent. 

For REINVITE towards ingress, use table 1.1 and for the REINVITE towards agent, use this table:

Solution

Initial INVITE from ingress can be received with any of the options:

Session-Expires: <value>

Session-Expires: <value>;refresher=uac

Session-Expires: <value>;refresher=uas

Ideally, in order to keep configuration simple, the solution level recommendation is to have ingress gateway be configured for refresher=uac so that INVITE received by CVP has the role defined, else 200 OK from IVR determines the role.

This work around is addressed in documentation bug.

Session-Expires configuration needed on Ingress

Specific use can handled here:

1. There is a discrepancy in both legs for session refresh negotiation, that resultsin a call to drop at 30 mins. mark when CUCM sends BYE with cause=41.
2. The discrepancy is that Telco does not the session refresh and CUCM wants session refresh as a mandatory parameter (require: timer) in this call flow (Telco-----CUBE----CVP----CUCM).
3. In this case either CVP or Ingress Gateway (CUBE) needs to take the role of Session refresher to send refresh INVITE to CUCM.
4. But CVP cannot not generate refresh INVITEs. It only passes between CUBE and CUCM.
5. Hence you need to make CUBE as refresher here.
6. To make CUBE as refresher, you can apply this config on CUBE and monitor the calls for 30 mins. drop. This has no production impact and configuration change applies right away.

conf t

 voice service voip
   sip
     min-se 1800 session-expires 1800
     session refresh
end

Common questions in specific scenarios:

1.Who is the Refresher when Agent hears whisper announcement.  In this case CVP is the UAC for Agent and Whisper Leg and what is the Session-Expires value?

In this case Caller/Ingress Gateway would be designated as refresher.

2.Why must CVP store the Refresher from ingress when CVP already knows when it initiats a client transaction or server transaction. CVP does not support session-refresh, it can always modify/add the header on the fly while it sends REINVITE to ingress as refresher ?

For now, CVP does not support the third combination, where CUCM/VXML gateway takes the role of refresher. Either way, CVP needs to save the information about who takes care of refresher role, either GW or CUCM. Accordingly, it includes the refresher parameter in the outbound request & response.