Application service problem

[marco]

Hello,

For night service we have created a loopback voip dial-peer to with an application service that prompts a message during after hours.

During working hours the same DP will prompt a waiting message.

So the DP is called by setting up a "call-forward noan 5500 timeout 20" where 5500 is the number associated to the loopback voip DP.

Here is the DP configuration:

!

dial-peer voice 500 voip

service script1

destination-pattern 5500$

session target ipv4:192.168.1.1 <-- this is the router ip address (IF Gi0/0)

incoming called-number 5500$

dtmf-relay h245-alphanumeric

codec g711ulaw

no vad

!

The voice service voip is configured as follows:

!

voice service voip

allow-connections h323 to h323

allow-connections h323 to sip

allow-connections sip to h323

allow-connections sip to sip

supplementary-service h450.12

h323

h450 h450-2 timeout T4 10000

h450 h450-3 timeout T1 10000

h245 caps mode restricted

modem passthrough nse codec g711alaw

sip

!

When the call starts from internal ephone or from outside mobile phones, the prompt is regularly played.

But when the call comes from an outside fixed phone, the call is disconnected just after the timeout for call-forward is expired.

We have also tried to configure a number expansion to call directly the DP 500 adding the following command to the configuration:

num-exp 2xxxxxx98 5500

but obviously the behavior does not change.

With "debug q931" we see that the call is disconnected with Disconnect Cause 10 (normal call clearing):

Apr 27 18:45:09.361: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x2500

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA18387

Preferred, Channel 7

Progress Ind i = 0x8083 - Origination address is non-ISDN

Calling Party Number i = 0x2183, '2xxxxxxx'

Plan:ISDN, Type:National

Called Party Number i = 0xA1, '2xxxxxx98'

Plan:ISDN, Type:National

Apr 27 18:45:09.365: ISDN Se0/0/0:15 Q931: TX -> SETUP_ACK pd = 8 callref = 0xA500

Channel ID i = 0xA98387

Exclusive, Channel 7

Apr 27 18:45:09.393: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0xA500

Cause i = 0x8090 - Normal call clearing

Apr 27 18:45:09.461: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x2500

Apr 27 18:45:09.461: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0xA500

Any ideas?

Thanks a lot.

Marco.

[paolo bevilacqua]

Hi Marco,

It may be a problem with the script. When I set my ephone CFA to a AA-BACD in lookpback, and I call from pstn, I'm correctly routed to it.

What the script does for handling the call/ Just leg_incoming ?

[marco]

Hello Paolo,

First of all sorry, but I've duplicated my request by mistake in the "IP Telephony" section:

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Unified%20Communications%20and%20Video&topic=IP%20Telephony&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.1dde5286

The script accepts the call

leg setupack leg_incoming

leg proceeding leg_incoming

leg connect leg_incoming

and then recalls media play to play the prompt, repeat the prompt another time and after the second play it closes the call with "leg disconnect leg_incoming".

In the tests we?ve done we have enabled the "debug voip app tclcommnads". When a call comes from a mobile phone the script was called and proceed successfully.

But when the call comes from the fixed phone number the debug print messages up to the "leg setupack" statement. The call is disconnected with a "clear disconnect cause".

Here is the debug output for a fixed phone call:

Apr 28 17:15:20.391: //6699//TCL :/tcl_InfotagObjCmd: infotag get leg_ani

Apr 28 17:15:20.391: //6699//TCL :/tcl_InfotagGetObjCmd: infotag get leg_ani

Apr 28 17:15:20.391: //6699//AFW_:/vtr_lg_ani: argc 2 argindex 2

Apr 28 17:15:20.391: //6699//TCL :/tcl_InfotagObjCmd: infotag get leg_dnis

Apr 28 17:15:20.391: //6699//TCL :/tcl_InfotagGetObjCmd: infotag get leg_dnis

Apr 28 17:15:20.391: //6699//AFW_:/vtr_lg_dnis: argc 2 argindex 2

Apr 28 17:15:20.391: //6699//TCL :/tcl_InfotagObjCmd: infotag set med_language 1

Apr 28 17:15:20.391: //6699//TCL :/tcl_InfotagSetObjCmd: infotag set med_language 1

Apr 28 17:15:20.391: //6699//AFW_:/vtw_ms_language: argc 3 argindex 2

Apr 28 17:15:20.391: //6699//TCL :/tcl_LegObjCmd: leg setupack leg_incoming

Apr 28 17:15:20.391: //6699//TCL :/tcl_LegSetupAckObjCmd: setupack leg_incoming

Apr 28 17:15:20.391: //6699//AFW_:/vtd_lg_incoming: argc 2

Apr 28 17:15:20.391: //6699//AFW_:/vtd_lg_incoming: Legs [6699 ]

Apr 28 17:15:20.391: //6699//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1

From a mobile phone call we got the same debug as above and:

Apr 28 17:15:39.891: //6702//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1

Apr 28 17:15:39.891: //6702//PACK:/tcl_MediaObjCmd: media play leg_incoming _night-tmp-msc.au

Apr 28 17:15:39.891: //6702//PACK:/tcl_MediaPlayObjCmd: play leg_incoming _night-tmp-msc.au

Apr 28 17:15:39.891: //6702//AFW_:/vtd_lg_incoming: argc 3

Apr 28 17:15:39.891: //6702//AFW_:/vtd_lg_incoming: Legs [6702 ]

Apr 28 17:15:39.891: //6702//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1

Apr 28 17:15:39.895: //6702//PACK:/Media_Play_Start:

Apr 28 17:15:39.967: %ISDN-6-CONNECT: Interface Serial0/0/0:0 is now connected to 3xxxxxxxxx N/A

Apr 28 17:15:42.067: %ISDN-6-DISCONNECT: Interface Serial0/0/0:0 disconnected from 3xxxxxxxxx , call lasted 2 seconds

Apr 28 17:15:42.075: Potential Mute Call:

Apr 28 17:15:42.075: CallID1=6700; CallID2=6701; ConfID=2212

Apr 28 17:15:42.075: Leg 1: CallID=6700; TX packets: 106; RX packets: 107

Apr 28 17:15:42.075: Leg 2: CallID=6701; TX packets: 107; RX packets: 106

Apr 28 17:15:42.079: //6702//TCL :/tcl_CallObjCmd: call close

Apr 28 17:15:42.079: //6702//TCL :/tcl_CallCloseObjCmd: close

Attached there is the act_Setup procedure.

The script failed even if it is configured under the DP associated to the serial voice port, or it is reached directly from the PSTN not with CFA, with num-exp, as specified in original post, or configuring the E.164 number as "destination-pattern" and "incoming-called number" under loopback DP 500.

Thanks a lot.

Marco.

[paolo bevilacqua]

Hi,

Actually, I would need to see the entire script. I suppose it handles ev_media_done to wait for the message to be played before closing the call, but without seeing it, I can't tell.

As I said, if you attach, for example, aa-bacd to CF numbers, it works OK.

[marco]

Hello Paolo,

Yes, the FSM machine is set up for ev_media_done in order to wait for the message to be played before closing the call, as you can see in the attached script.

Thanks.

[paolo bevilacqua]

Hi Marco,

I will look at this as I have the time, good luck!

[marco]

Hello Paolo,

While I'm waiting for your results, can I ask if you are almost sure that it's a script problem?

Thanks a lot as usual!

Marco.