'leg progress' has no effect

[cdnadmin]

Subject: RE: 'leg progress' has no effect
Replied by: Tomas Ussher on 27-04-2012 02:58:30 PM

Have u try this ? Not quite remember, long long time ago people talking about issue with or without -p

leg progress leg_incoming 1

Apr 27 20:55:44.056 CEST: //3076//TCL :/tcl_PutsObjCmd: leg state lg_001
Apr 27 20:55:44.056 CEST: //3076//AFW_:/AFW_FSM_Drive: Tcl_Eval to drive FSM inside Tcl modulespace. code=1 code=ERROR
Apr 27 20:55:44.056 CEST: TCL script failure
        Result:
                         Illegal Option `?'
Apr 27 20:55:44.056 CEST:       TCL script failure errorInfo:
                        Illegal Option `?'
    while executing
"leg progress leg_incoming $stringPI
 
Is there anybody from Cisco will to verify this problem ?

Subject: RE: 'leg progress' has no effect
Replied by: Tomas Ussher on 27-04-2012 03:44:27 PM
interface BRI0/0/0
no ip address
isdn switch-type basic-net3
isdn tei-negotiation preserve
isdn point-to-point-setup
isdn incoming-voice voice
isdn outgoing ie progress-indicator

dial-peer voice 686327991 pots
service test
incoming called-number 686327991

vg-bws-rome-1a#sh deb
The following ISDN debugs are enabled on all DSLs:
debug isdn error is             ON.
debug isdn q931 is              ON.   (filter is OFF)
CCAPI:
  debug voip ccapi inout is ON (filter is OFF)
  debug voip application tcl commands is ON (filter is OFF)

Apr 27 21:42:21.296 CEST: ISDN BR0/0/0 Q931: RX <- SETUP pd = 8  callref = 0x6E
        Bearer Capability i = 0x9090A3
                Standard = CCITT
                Transfer Capability = 3.1kHz Audio
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0x89
                Exclusive, B1
        Calling Party Number i = 0x2183, '21111'
                Plan:ISDN, Type:National
        Called Party Number i = 0xA1, '686327991'
                Plan:ISDN, Type:National
        Sending Complete
Apr 27 21:42:21.296 CEST: //-1/F0780581819B/CCAPI/cc_api_display_ie_subfields:
   cc_api_call_setup_ind_common:
   cisco-username=
   ----- ccCallInfo IE subfields -----
   cisco-ani=021111
   cisco-anitype=2
   cisco-aniplan=1
   cisco-anipi=0
   cisco-anisi=3
   dest=686327991
   cisco-desttype=2
   cisco-destplan=1
   cisco-rdie=FFFFFFFF
   cisco-rdn=
   cisco-rdntype=-1
   cisco-rdnplan=-1
   cisco-rdnpi=-1
   cisco-rdnsi=-1
   cisco-redirectreason=-1   fwd_final_type =0
   final_redirectNumber =
   hunt_group_timeout =0

Apr 27 21:42:21.300 CEST: //-1/F0780581819B/CCAPI/cc_api_call_setup_ind_common:
   Interface=0x31869A7C, Call Info(
   Calling Number=021111,(Calling Name=)(TON=National, NPI=ISDN, Screening=Network, Presentation=Allowed),
   Called Number=686327991(TON=National, NPI=ISDN),
   Calling Translated=FALSE, Subscriber Type Str=RegularLine, FinalDestinationFlag=TRUE,
   Incoming Dial-peer=686327991, Progress Indication=NULL(0), Calling IE Present=TRUE,
   Source Trkgrp Route Label=ti, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=-1
Apr 27 21:42:21.300 CEST: //-1/F0780581819B/CCAPI/ccCheckClipClir:
   In: Calling Number=021111(TON=National, NPI=ISDN, Screening=Network, Presentation=Allowed)
Apr 27 21:42:21.300 CEST: //-1/F0780581819B/CCAPI/ccCheckClipClir:
   Out: Calling Number=021111(TON=National, NPI=ISDN, Screening=Network, Presentation=Allowed)
Apr 27 21:42:21.300 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Apr 27 21:42:21.300 CEST: :cc_get_feature_vsa malloc success
Apr 27 21:42:21.300 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Apr 27 21:42:21.300 CEST:  cc_get_feature_vsa count is 1
Apr 27 21:42:21.300 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Apr 27 21:42:21.300 CEST: :FEATURE_VSA attributes are: feature_name:0,feature_time:729184312,feature_id:3491
Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/cc_api_call_setup_ind_common:
   Set Up Event Sent;
   Call Info(Calling Number=021111(TON=National, NPI=ISDN, Screening=Network, Presentation=Allowed),
   Called Number=686327991(TON=National, NPI=ISDN))
Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/cc_process_call_setup_ind:
   Event=0x2C0167C8
Apr 27 21:42:21.300 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
   Try with the demoted called number 686327991
Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/ccCallSetContext:
   Context=0x2B768D84
Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/cc_process_call_setup_ind:
   >>>>CCAPI handed cid 3081 with tag 686327991 to app "_ManagedAppProcess_test"
Apr 27 21:42:21.300 CEST: //3081//TCL :/tcl_LegObjCmd:  leg progress leg_incoming -p 1
Apr 27 21:42:21.300 CEST: //3081//TCL :/tcl_LegProgressObjCmd: progress leg_incoming -p 1
Apr 27 21:42:21.300 CEST: //3081//AFW_:/vtd_lg_incoming: argc 4
Apr 27 21:42:21.300 CEST: //3081//AFW_:/vtd_lg_incoming: Legs [3081 ]
Apr 27 21:42:21.300 CEST: //3081//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
Apr 27 21:42:21.300 CEST: //3081//TCL :/tcl_LegProgressObjCmd: prog ind=1
Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/ccCallCutProgress:
   Progress Indication=NOT END TO END ISDN(1), Signal Indication=SIGNAL RINGBACK(1), Cause Value=0
   Voice Call Send Alert=FALSE, Call Entry(Alert Sent=FALSE)
Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/ccCallCutProgress:
   Call Entry(Responsed=TRUE)
Apr 27 21:42:21.300 CEST: //3081//TCL :/tcl_CallObjCmd:  call close
Apr 27 21:42:21.300 CEST: //3081//TCL :/tcl_CallCloseObjCmd:  close
Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/ccCallDisconnect:
   Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/ccCallDisconnect:
   Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/cc_api_get_transfer_info:
   Transfer Number Is Null
Apr 27 21:42:21.304 CEST: //3081/F0780581819B/CCAPI/cc_api_call_disconnect_done:
   Disposition=0, Interface=0x31869A7C, Tag=0x0, Call Id=3081,
   Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)
Apr 27 21:42:21.304 CEST: //3081/F0780581819B/CCAPI/cc_api_call_disconnect_done:
   Call Disconnect Event Sent
Apr 27 21:42:21.304 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Apr 27 21:42:21.304 CEST: :cc_free_feature_vsa freeing 2B767830
Apr 27 21:42:21.304 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Apr 27 21:42:21.304 CEST:  vsacount in free is 0
Apr 27 21:42:22.188 CEST: ISDN BR0/0/0 **ERROR**: L3_Go: Multi nlcb DL_EST, cid 0x41E cr 0xEE ev 0x300 ces 1
Apr 27 21:42:22.188 CEST: ISDN BR0/0/0 Q931: TX -> RELEASE_COMP pd = 8  callref = 0xEE
        Cause i = 0x8090 - Normal call clearing
This document was generated from CDN thread

Created by: Tomas Ussher on 27-04-2012 12:27:57 PM
I'm trying to play a message to an ISDN caller before conection to avoid caller being billed.
 
For that I'm using ' leg progress' as per documentation.
However, observing debug isdn q931, no progress message is ever sent, I have tried many combinations of code and router configuration.
I can send and set PI of choice with any ISDN message type, but cannot send PROGRESS at all.
Why ?
 
This is the minal script that reproduces the problem:
 
proc setup {}{
  leg progress leg_incoming -p 1
 call close
}
set fsm(INIT,ev_setup_indication)  "setup same_state"
fsm define fsm INIT

Subject: RE: 'leg progress' has no effect
Replied by: Yaw-Ming Chen on 27-04-2012 12:56:39 PM
Document also says that:
If a call proceeding message has already been sent, this command is ignored. If IVR debugging is
on (see the “Testing and Debugging Your Script” section on page 2-8), the command that has been
ignored is displayed.

Check leg state
set legState [infotag get leg_state $legID]

http://developer.cisco.com/web/vgapi/blogroll/-/blogs/tcl-ivr-api-undocumented-status-code?_33_redirect=http%3a%2f%2fdeveloper.cisco.com%2fweb%2fvgapi%2fblogroll%2f-%2fblogs%3f_33_advancedSearch%3dfalse%26_33_cur%3d3%26_33_keywords%3d%26_33_delta%3d5...

Subject: RE: 'leg progress' has no effect
Replied by: Tomas Ussher on 27-04-2012 12:59:55 PM
In my case, as the code example shows, no call proceeding message has already been sent.
 
leg_state is lg_001 (LEG_INCOMING_FIRST)
 
Can you try my example script on you system, anvd verify if PROGRESS is being sent or not ?

Subject: RE: 'leg progress' has no effect
Replied by: Yaw-Ming Chen on 27-04-2012 01:05:22 PM
Can you please try to get leg state ? In this case we can know what IOS should respond.
Sorry I don't have ISDN line to try.

Subject: RE: 'leg progress' has no effect
Replied by: Tomas Ussher on 27-04-2012 01:07:55 PM
Leg state added in my post above.

Anybody from Cisco able to test this ? Can use routers back-to-back, no need for actual circuits.

Subject: RE: 'leg progress' has no effect
Replied by: Yaw-Ming Chen on 27-04-2012 01:14:59 PM
In this case proceeding is not sent and usually we want to do
leg setupack leg_incoming
leg proceeding leg_incoming
before doing
  leg connect leg_incoming

Did you try
leg setupack leg_incoming
before progress ?

Subject: RE: 'leg progress' has no effect
Replied by: Tomas Ussher on 27-04-2012 01:38:37 PM
In this case proceeding is not sent and usually we want to do
leg setupack leg_incoming
leg proceeding leg_incoming
before doing
  leg connect leg_incoming

Did you try
leg setupack leg_incoming
before progress ?


 
I cannot do leg setupack, because from documentation and also verified:
 
Note The ISDN state machine actually connects the incoming call on a setup acknowledgement
 
furthermore, PROGRESS after CONNECT is not allowed in ISDN.
I do not want connection to complete. I want to send a PROGRESS message as per documentation.
 
Can you tell me how to do that ?

Subject: RE: 'leg progress' has no effect
Replied by: Yaw-Ming Chen on 27-04-2012 02:03:24 PM
Is there a the following CLI in dialpeer ?

progress_ind alert enable ...

Subject: RE: 'leg progress' has no effect
Replied by: Tomas Ussher on 27-04-2012 02:11:56 PM
The progress_ind commands ONLY apply to outgoing dial-peer.
This command sets the progress indicator only in messages from outbound dial peers that have a set destination pattern, configured by using the destination-pattern command

Since scripts are triggered from incoming dial-peers, the command is not available and not applicable.

Furthermore, I am able to generate ALERT message no problem, and attach a PI to it.

Subject: RE: 'leg progress' has no effect
Replied by: Yaw-Ming Chen on 27-04-2012 02:25:12 PM
Have u try this ? Not quite remember, long long time ago people talking about issue with or without -p

leg progress leg_incoming 1

Subject: RE: 'leg progress' has no effect
Replied by: Yaw-Ming Chen on 27-04-2012 03:21:39 PM
Can you please collect
deb voip app tcl
deb voice ccapi inout

will ask someone take a look

Subject: RE: 'leg progress' has no effect
Replied by: Tomas Ussher on 04-05-2012 02:16:48 PM

Can you please collect
deb voip app tcl
deb voice ccapi inout

will ask someone take a look

 
Any update?
Any hope to be able to do what the documentation promises ?

Subject: RE: 'leg progress' has no effect
Replied by: Yaw-Ming Chen on 07-05-2012 01:01:56 PM
I haven't received any response, from the log looks like you're using BRI is that right ?

Subject: RE: 'leg progress' has no effect
Replied by: Yaw-Ming Chen on 07-05-2012 01:19:20 PM
Just Got some feedback:

Application is sending progress to underlying signaling stack:

Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/ccCallCutProgress:
   Progress Indication=NOT END TO END ISDN(1), Signal Indication=SIGNAL RINGBACK(1), Cause Value=0
   Voice Call Send Alert=FALSE, Call Entry(Alert Sent=FALSE)

We don’t know if signaling stack ignores it.

Adding signaling team to this thread.


So at least from API point of view there is not thing wrong, let's wait for more feedback

Subject: RE: 'leg progress' has no effect
Replied by: Yaw-Ming Chen on 07-05-2012 03:04:16 PM
Another feedback:


"I think the general order is

leg proceeding leg_incoming
leg setupack leg incoming


If setupack and progress does not work  for them, please try

leg alert leg_incoming –p <prog_ind>"
 
Instead of progress, please try alert

Subject: RE: 'leg progress' has no effect
Replied by: Tomas Ussher on 10-05-2012 02:47:08 AM

Another feedback:


"I think the general order is

leg proceeding leg_incoming
leg setupack leg incoming


If setupack and progress does not work  for them, please try

leg alert leg_incoming –p <prog_ind>"
 
Instead of progress, please try alert

 
I did try, the PI is actually sent, however the calling party hears ringback and not the prompt being played to leg_incoming.
I'm sure that to open the audio channel, progress has to be sent.
 
Again: cannot use leg setup_ack as it would connect the call and I don't want that.