Reading the Facility Callername from a tcl script

kevinbadeen · ‎10-15-2009

I am looking for a way to read the Callingname in the facility message so that I can pass into

set callInfo(displayInfo)

Basically I'm trying to pass Callername to an ip phone through a TCL script on the gateway during callsetup. This normally gets dropped.

Is there a way to parse these fields in the Facility message?

Thanks ahead of time for any help.

Oct 14 21:59:58.274: ISDN Se0/0/0:23 Q931: RX <- FACILITY pd = 8 callref = 0x03BB

Facility i = 0x9F8B0100A117020101020100800F5452494F4E20574F524C44204E4554

Protocol Profile = Networking Extensions

0xA117020101020100800F5452494F4E20574F524C44204E4554

Component = Invoke component

Invoke Id = 1

Operation = CallingName

Name Presentation Allowed Extended

Name = MY CALLINGNAME

paolo bevilacqua · ‎10-16-2009

---

kevinbadeen · ‎10-16-2009

Well.. I'm having to alter an existing script that parsers the calls for fax service before they are being sent to callmanager.

So far I think im in the right direction but I don't know how to use the "object get gtd" properly, if that's even the right approach. Im trying to parse

GEN,y,y,0,JOE BLOW

from the gtd debug below...

Oct 15 16:32:26.543: CNG tone sent

Oct 15 2009 11:32:26 CDT: %ISDN-6-CONNECT: Interface Serial0/0/0:0 is now connected to XXXXXXXXXX N/A

Oct 15 16:32:27.231: ISDN Se0/0/0:23: Built a GTD of size 110 octets for ISDN message type 0x62

Oct 15 16:32:27.231: tsp_ccrawmsg_encap: calling cdapi_find_tsm

Oct 15 16:32:27.231: cdapi_find_tsm: Found Tunnelled Signaling Msg with GTD: PROT_PTYPE_GTD

Oct 15 16:32:27.231: cdapi_find_tsm: Found a gtd msg of length 110:

Oct 15 16:32:27.231: gtd msg = "FAC,

PRN,isdn*,,NI***,

GEN,y,y,0,JOE BLOW ïƒŸ----------------Caller NAME

UFC,GEN,5,fachd,9f8b0100

UFC,GEN,5,inpdu,020101020100"

This is what I have so far...

set DestNum [infotag get evt_dcdigits]

set callInfo(destinationNum) $DestNum

infotag set evt_facility_report gtd

infotag get evt_gtd CallerID

set CallerName [object get gtd CallerID FAC,4,GEN]

set DestNum [infotag get evt_dcdigits]

put "$CallerName"

put "$DestNum"

set callInfo(displayInfo) $CallerName

set callInfo(destinationNum) $DestNum

leg setup $DestNum callInfo leg_incoming

paolo bevilacqua · ‎10-18-2009

Not sure why you are using GTD.

If you're connecting to a regular PRI the command I've indicated above is all what is needed to populate leg_display_info.

At least that is my understanding.

kevinbadeen · ‎10-19-2009

I've copied some of my config on the gateway.. So what I've been told is that the Calling Name isnt being populated due to the application parsing of the inbound call from the PRI. Is this not accurate?

application

service fax_detect flash:app_fax_detect.2.1.2.3.tcl

dial-peer voice 2 pots

service fax_detect

incoming called-number 7...

direct-inward-dial

voice service voip

fax protocol pass-through g711ulaw

h323

h225 timeout ntf 500

h225 display-ie ccm-compatible

call preserve limit-media-detection

paolo bevilacqua · ‎10-19-2009

Sorry, I don't follow your line of thinking.

In my first reply I've indicated the command needed to decode calling name, you do not have that in the config above.

kevinbadeen · ‎10-19-2009

Ha :)

From what I've been told and can tell in the traces this is what is happening in my scenario.

PSTN->VG->Application/fax-detect->CM

PSTN and VG sees the calling name come through.. when it gets to CM its missing. I have to read the calling name in from the application and pass it to CM during the leg setup within the application.

Your saying that if I enable qsig it will pass the calling name in the leg setup?

paolo bevilacqua · ‎10-20-2009

It will populate the infotag mentioned above, I'm saying that for the fourth time now.

jsteinberg · ‎06-07-2010

anyone figure this one out? I am having the same problem. I have tried the suggestion 'qsig decode' and it doesn't work for me.

paolo bevilacqua · ‎06-08-2010

Take "debug isdn q931" with "term mon" and post it here.

jsteinberg · ‎06-09-2010

I don't think you understand our problem.

The problem is that we need to use a TCL script for something else (not caller id name) and when we use the TCL script, it breaks the caller id name (which was working for us before needing to use the TCL script).

I found this link:

http://developer.cisco.com/web/vgapi/forums/-/message_boards/message/1693754

Which confirms the OP's reference to needing to use GTD to map the facility message in the TCL script.

The relevent CNAM config needed is:

set cname [object get gtd gtd_fac gen.-1.name]

and then:

set callInfo(displayInfo) $cname

when you setup the call transfer.

Adding these lines to the TCL script passes the caller id name from the 2nd facility message into the h323 leg which is what is needed to display the name on the IP phone screen.

paolo bevilacqua · ‎06-09-2010

My understanding is that no matter the protocol, the calling name should be accessed directly by the infotag I have referenced above, as IOS does most of the work for you when configured correctly.

Using GTD as you mentioned to access the facility field is undocumented other than in the link you posted, beside if it's not working why complaining here instead to the person that suggested the tecnique ?

I will confirm my supposition when I will have a chance to lab it.

sscdvp2010 · ‎09-14-2010

Are you sure this script is really working?

I believe you should use

set cname [object get gtd gtd_fac GEN.-1.name]

instead of

set cname [object get gtd gtd_fac gen.-1.name]

paolo bevilacqua · ‎12-19-2010

sscdvp2010 wrote:

Are you sure this script is really working?

I believe you should use

set cname [object get gtd gtd_fac GEN.-1.name]

instead of

set cname [object get gtd gtd_fac gen.-1.name]

In TCL/IVR, GTD parameter names are not case sensitve.

paolo bevilacqua · ‎06-08-2010

To put a closure on this.

As I had initially suggested, the calling name is normally available accessing the infotag mentioned above.

However, the serial interface must be configured with " isdn supp-service name calling".