About Alfred Johnson

Alfred Johnson · ‎11-09-2016

Does this mean that Cisco does not support the use of the C-Scripts by customers? If so, why do they appear in customer-facing displays like show call application?

Alfred Johnson · ‎11-08-2016

bctrunks-2431-4#show call application voice RetrProxy Script Name : RetrProxy URL : builtin:RetrievalProxy_Service.C Type : Service State: Registered Life : Builtin Exec Instances: 0 Script Code Begin: -------------------------------- Built in C Package implementing the Service RetrievalProxy functionality -------------------------------- To me this is inadequate description for someone to make any use of

Alfred Johnson · ‎09-26-2016

Sorry, but I found a typograhical error that was the cause. I typed BackSecs as Backsecs in one of my global statements. I deleted my comment after I found the typo, but I guess you saw my comment before I erased it. Thanks.

Alfred Johnson · ‎09-22-2016

You may be able to use either SNMP or CLI commands to monitor a trunk, but I am not familiar enough with CUBE to say for sure. SNMP is attractive, because EEM can go some of the work by polling the SNMP OID(s) and starting up an EEM script or applet when the OID is incremented. But you will have to research what MIBs are supported on CUBE. You may have to use indirect inference on the state of the trunk, since the SIP MIBs I have seen don't always have an OID for the up/down status of objects, but usually seem to have counts of various messages, that can be used to infer the state. But I am sure you can use some CLI show commands to see the trunk state, but you will have to find a way to trigger EEM periodically and use its CLI capability to do the show command you need. Then you can use the various string and/or regular expression functions to parse the CLI response to determine if the trunk is up or down. I don't know why I just now got an email from Cisco on this issue, when your post was 6 months ago. I hope you have already found a solution.

Alfred Johnson · ‎09-06-2016

I just googled 'eem applet reboot' and the 2nd result was: Cisco – how to schedule an unattended reload with EEM – yurisk.info yurisk.info/2011/06/22/cisco-how-to-schedule-an-unattended-reload-with-eem/ Cisco – how to schedule an unattended reload with EEM · June 22, 2011 / Yuri / metr�Q�I� This link shows the 'action nnn reload' command. Of course you need to use the appropriate 'if' or other condition testing command to determine when/whether to reboot. From my applet above, you could use: action 700 cli command "show sip-ua register status | include yes" action 710 string first "yes" "$_cli_result" action 730 if $_string_result gt 0 goto nnn Of course the details of these and other commands are documented in the EmbeddedEventManagerCommandReference-eem-cr-book.pdf and the Writing-EEM-Policies-Using-CLI-15.0-nm_eem_policy_cli.pdf documents, both available on the Cisco web site.

Alfred Johnson · ‎08-17-2015

I found a detailed example in the 15M & T SIP Config Guide, starting on page 213. However, I am still looking for the TCL code that implemented it. If anyone has access to that, please let me know where I can find it.

Alfred Johnson · ‎08-16-2015

I have been able to use TCL IVR application to send a SIP SUBSCRIBE to a SIP proxy on an IMS for SIP registration events and see the proxy return a 200 OK followed by a NOTIFY using debug ccsip messages. But so far I have been unable to get my TCL IVR script to successfully receive an ev_notify event or other any other event when the Proxy sends either the initial NOTIFY or a subsequent NOTIFY in the case where the Proxy needs my SIP User agent to re-register after some change to the Proxy's configration or state, such as an account provisioning event, or expiration of the Proxy's subscription timer. Does anyone know if such an example exists? I have searched this forum and various internet sites but I have found nothing helpful. The TCL IVR App Guide describes the feature for SIP Subscribe/Notify support but I have yet to find any details on how exacthis works. If there are any specific requirements on the content of the received NOTIFY, such as its Call-ID, From:, To:, I 'd appreciate any information anyone could send me. Please do not reply asking me if I have read the Cisco TCL IVR Programmers guide 2.0 or the Cisco TCL IVR/VXML Applications Guide docs, unless you can point me to a specific example in them. I have read and searched them closely, but I have found none.

Alfred Johnson · ‎06-01-2015

I have spent a little more time fleshing out my Subscribe/Notify state machine, and I was trying to use the ev_notify event to detect receipt of the Notify, but I was never able to receive it. So I tried using ev_notify_done instead, and I was able to get the state machine to receive this event. I have not done much else, because I have some other fires I am fighting on a different front, but I hope to get back to this in a week or two. In my application, I want to respond to the receipt of SIP error responses, which I have been detecting via an EEM applet that monitors the SIP message counts in the router's SIP MIB. But I have been struggling with how to communicate between the EEM applet and the Tcl IVR state machine. It is possible to set Tcl IVR parameters from the EEM applet by executing CLI commands in config mode, so I think this will work in one direction. I have not yet figured out how to get the TCL IVR state machine send an indication back to the EEM applet to tell it whether the router's SIP Registration is still active. But there are CLI commands to display the status of a TCL IVR state machine so I am optomistic I can find a way.

Alfred Johnson · ‎05-18-2015

This TCL Subscribe/Notify feature is specifically for the SIP protocol (Session Initiation Protocol, rfc3261) over UDP or TCP which is primarily used as a telephony signalling protocol to set up and tear down calls. SIP can be used for other functions, but I don't think it is used with WSMA, which to my knowledge is SOAP/XML based. The SIP Subscribe/Notify Feature is described in the IOS SIP 15.1 Config Guide. However, that does not mean you can't use TCL. I would look in the TCL applications guide for SOAP examples. But I don't have any knowledge of them.

Alfred Johnson · ‎05-08-2015

I got a very basic TCL IVR application to send a Subscribe to our IMS and receive a notify. You have to add the following to the IOS configuration: application service SubscribeReg flash:SubscribeReg.tcl param redirect-number 8163484000 ! session start SubscribeReg_sess1 SubscribeReg The param statement can be used to pass data to the TCL script, in my case I want to pass the Default IMPU/userid/MainTN of the PBX. Next you have to define a TCL script. Below is mine, which is far from complete. I only wanted to test whether I could send a good Subscribe that our IMS would accept. The 'subscription open' command below is what causes IOS to send the Subscribe. It does more than that, it waits for a response and upon a 407 resends with auth nonce, and then waits for the Notify and responds to it with a 200 OK. # SubscribeReg.tcl #------------------------------------------------------------------ # Script Version 0.1 - 2015-5-5 # # This tcl script # #------------------------------------------------------------------ proc init { } { global param } proc Send_Subscribe { } { set headers(From) "sip:+18163484000@ims.eng.rr.com" set headers(To) "sip:+18163484000@ims.eng.rr.com" set SubscrParams(protoHeaders) headers set SubscrParams(event) reg set SubscrParams(expirationTime) 1210 set mySubID [subscription open sip:+18163484000@ims.eng.rr.com SubscrParams] } proc Check_Response { } { set status [infotag get evt_status] puts status if { $status != "su_000"} { puts "Successful Subscribe" } } proc Timeout { } { puts "Expires Timer Expired" } proc act_Abort { } { puts "Unexpected event - entering act_Abort" call close } init #---------------------------------- # State Machine #---------------------------------- set SubscribeSM(any_state,ev_disconnected) "act_Abort,same_state" set SubscribeSM(SUBSCRIBING,ev_any_event) "Send_Subscribe,WAIT_FOR_RESPONSE" set SubscribeSM(WAIT_FOR_RESPONSE,ev_subscribe_done) "Check_Response,NORMAL" set SubscribeSM(NORMAL,ev_unsubscribe_indication) "Timeout,SUBSCRIBING" fsm define SubscribeSM SUBSCRIBING --------------------------------------------------------------------------------------------- Initially, the Subscribe it generated was not accepted by IMS: Sent: SUBSCRIBE sip:+18163484000@172.17.254.75:5060 SIP/2.0 Via: SIP/2.0/UDP 10.40.208.29:5060;branch=z9hG4bK66D9FC4 From: sip:+18163484000@ims.eng.rr.com;tag=62230F74-1FDF To: sip:+18163484000@ims.eng.rr.com Call-ID: 4B452078-F40511E4-849ADB8F-ECAF76A@10.40.208.29 CSeq: 101 SUBSCRIBE Max-Forwards: 70 Event: reg Expires: 1210 Contact: <sip:10.40.208.29:5060> Content-Length: 0 May 7 11:33:50.295 EDT: //0/000000000000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 403 Forbidden - User Not Registered v:SIP/2.0/UDP 10.40.208.29:5060;branch=z9hG4bK66D9FC4 f:<sip:+18163484000@ims.eng.rr.com>;tag=62230F74-1FDF t:<sip:+18163484000@ims.eng.rr.com>;tag=1127270911 i:4B452078-F40511E4-849ADB8F-ECAF76A@10.40.208.29 CSeq:101 SUBSCRIBE l:0 ------------------------------------------------------------------- The problem was that the Request-URI was sip:+18163484000@172.17.254.75:5060 instead of sip:+18163484000@ims.eng.rr.com, which I put in the 'subscription open', statement. For some reason, TCL or IOS SIP decided to do a dns lookup on the fqdn instead of just using the literal fqdn. Fortunately, IOS did send the Subscribe message to the IP address of the SIP outbound proxy: voice service voip sip outbound-proxy dns:eepcscf-gm.ims.eng.rr.com reuse After talking about this with a co-worker, I remembered the 'voice class sip-profiles' commands, and put the following in to change the Request-URI: voice class sip-profiles 100 request SUBSCRIBE sip-header SIP-Req-URI modify "(.*)@.*" "\1@ims.eng.rr.com;user=phone SIP/2.0" It worked! Below is the debug ccsip messages output: May 8 09:41:03.228 EDT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SUBSCRIBE sip:+18163484000@ims.eng.rr.com;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.40.208.29:5060;branch=z9hG4bK68411986 From: sip:+18163484000@ims.eng.rr.com;tag=66E22814-DA5 To: sip:+18163484000@ims.eng.rr.com Call-ID: B4343033-F4BE11E4-84A6DB8F-ECAF76A@10.40.208.29 CSeq: 101 SUBSCRIBE Max-Forwards: 70 Event: reg Expires: 1210 Contact: <sip:10.40.208.29:5060> Content-Length: 0 May 8 09:41:03.244 EDT: //0/000000000000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 407 Proxy Authentication Required v:SIP/2.0/UDP 10.40.208.29:5060;branch=z9hG4bK68411986 f:<sip:+18163484000@ims.eng.rr.com>;tag=66E22814-DA5 t:<sip:+18163484000@ims.eng.rr.com>;tag=986239153 i:B4343033-F4BE11E4-84A6DB8F-ECAF76A@10.40.208.29 CSeq:101 SUBSCRIBE Proxy-Authenticate:Digest realm="ims.eng.rr.com",nonce="75dddaec554cbcef111cef05ea5c403a2123215769b1379d4fb37d",qop="auth" l:0 May 8 09:41:03.248 EDT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SUBSCRIBE sip:+18163484000@ims.eng.rr.com;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.40.208.29:5060;branch=z9hG4bK68421E92 From: sip:+18163484000@ims.eng.rr.com;tag=66E22814-DA5 To: sip:+18163484000@ims.eng.rr.com Call-ID: B4343033-F4BE11E4-84A6DB8F-ECAF76A@10.40.208.29 Max-Forwards: 70 Event: reg Expires: 1210 Contact: <sip:10.40.208.29:5060> Content-Length: 0 Proxy-Authorization: Digest username="E06F4E57B7BDC175@ims.eng.rr.com",realm="ims.eng.rr.com",uri="sip:+18163484000@172.17.254.75:5060",response="5449f4c2ca85270b40eab3e6b97600ae",nonce="75dddaec554cbcef111cef05ea5c403a2123215769b1379d4fb37d",cnonce="1F86A2C9",qop=auth,algorithm=md5,nc=00000001 CSeq: 102 SUBSCRIBE May 8 09:41:03.272 EDT: //0/000000000000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 200 OK v:SIP/2.0/UDP 10.40.208.29:5060;branch=z9hG4bK68421E92 f:<sip:+18163484000@ims.eng.rr.com>;tag=66E22814-DA5 t:<sip:+18163484000@ims.eng.rr.com>;tag=1254025593 i:B4343033-F4BE11E4-84A6DB8F-ECAF76A@10.40.208.29 CSeq:102 SUBSCRIBE Expires:1210 m:<sip:abrscscf.ims.eng.rr.com:5090;lskpmc=S11> Record-Route:<sip:172.17.254.170;routing_id=pcscf_a_side;lskpmc=P11;lr;serv_user=10.40.208.29:5060> l:0 May 8 09:41:03.288 EDT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: NOTIFY sip:10.40.208.29:5060 SIP/2.0 v:SIP/2.0/TCP 172.17.254.170:5060;branch=z9hG4bKc96ca3c2c2e7da83fb9759288d008de5;lskpmc=P11 Record-Route:<sip:172.17.254.170;routing_id=pcscf_a_side;lskpmc=P11;lr> v:SIP/2.0/TCP 172.17.254.75:5090;branch=z9hG4bK93a8447a0d8890d6e32d6205611029d1;lskpmc=S11 f:<sip:+18163484000@ims.eng.rr.com>;tag=1254025593 t:<sip:+18163484000@ims.eng.rr.com>;tag=66E22814-DA5 o:reg i:B4343033-F4BE11E4-84A6DB8F-ECAF76A@10.40.208.29 Subscription-State:active CSeq:1 NOTIFY c:application/reginfo+xml m:<sip:abrscscf.ims.eng.rr.com:5090;lskpmc=S11> Max-Forwards:68 l:705 <?xml version="1.0"?><reginfo xmlns="urn:ietf:params:xml:ns:reginfo" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="0" state="full"><registration aor="sip:+18163484000@ims.eng.rr.com" id="7d94aa39111431092326854924" state="active"><contact id="111431092326854924" state="active" event="registered"><uri>sip:+18163484000@10.40.208.29:5060</uri><unknown-param name="audio"/></contact></registration><registration aor="sip:+18163484001@ims.eng.rr.com;end-num=18163484999" id="a9968911111431092326854924" state="active"><contact id="111431092326854924" state="active" event="created"><uri>sip:+18163484000@10.40.208.29:5060</uri><unknown-param name="audio"/></contact></registration></reginfo> May 8 09:41:08.296 EDT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 200 OK Via: SIP/2.0/TCP 172.17.254.170:5060;branch=z9hG4bKc96ca3c2c2e7da83fb9759288d008de5;lskpmc=P11,SIP/2.0/TCP 172.17.254.75:5090;branch=z9hG4bK93a8447a0d8890d6e32d6205611029d1;lskpmc=S11 From: sip:+18163484000@ims.eng.rr.com;tag=1254025593 To: sip:+18163484000@ims.eng.rr.com;tag=66E22814-DA5 Date: Fri, 08 May 2015 13:41:08 GMT Call-ID: B4343033-F4BE11E4-84A6DB8F-ECAF76A@10.40.208.29 CSeq: 1 NOTIFY Record-Route: <sip:172.17.254.170;routing_id=pcscf_a_side;lskpmc=P11;lr> Content-Length: 0

Alfred Johnson · ‎05-08-2015

I was able to get the Subscribe to work using the voice class sip-profiles command to modify the outgoing Subscribe message: bctrunks-2431-4#srs voice class sip-profiles voice class sip-profiles 100 . . . request SUBSCRIBE sip-header SIP-Req-URI modify "(.*)@.*" "\ 1@ims.eng.rr.com ;user=phone SIP/2.0" Below is the output of debug ccsip messages: May 8 09:41:03.228 EDT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SUBSCRIBE sip: +18163484000@ims.eng.rr.com ;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.40.208.29:5060;branch=z9hG4bK68411986 From: sip: +18163484000@ims.eng.rr.com ;tag=66E22814-DA5 To: sip: +18163484000@ims.eng.rr.com Call-ID: B4343033-F4BE11E4-84A6DB8F-ECAF76A@10.40.208.29 CSeq: 101 SUBSCRIBE Max-Forwards: 70 Event: reg Expires: 1210 Contact: <sip:10.40.208.29:5060> Content-Length: 0 May 8 09:41:03.244 EDT: //0/000000000000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 407 Proxy Authentication Required v:SIP/2.0/UDP 10.40.208.29:5060;branch=z9hG4bK68411986 f:<sip: +18163484000@ims.eng.rr.com >;tag=66E22814-DA5 t:<sip: +18163484000@ims.eng.rr.com >;tag=986239153 i:B4343033-F4BE11E4-84A6DB8F-ECAF76A@10.40.208.29 CSeq:101 SUBSCRIBE Proxy-Authenticate:Digest realm="ims.eng.rr.com",nonce="75dddaec554cbcef111cef05ea5c403a2123215769b1379d4fb37d",qop="auth" l:0 May 8 09:41:03.248 EDT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SUBSCRIBE sip: +18163484000@ims.eng.rr.com ;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.40.208.29:5060;branch=z9hG4bK68421E92 From: sip: +18163484000@ims.eng.rr.com ;tag=66E22814-DA5 To: sip: +18163484000@ims.eng.rr.com Call-ID: B4343033-F4BE11E4-84A6DB8F-ECAF76A@10.40.208.29 Max-Forwards: 70 Event: reg Expires: 1210 Contact: <sip:10.40.208.29:5060> Content-Length: 0 Proxy-Authorization: Digest username=" E06F4E57B7BDC175@ims.eng.rr.com ",realm="ims.eng.rr.com",uri="sip:+18163484000@172.17.254.75:5060",response="5449f4c2ca85270b40eab3e6b97600ae",nonce="75dddaec554cbcef111cef05ea5c403a2123215769b1379d4fb37d",cnonce="1F86A2C9",qop=auth,algorithm=md5,nc=00000001 CSeq: 102 SUBSCRIBE May 8 09:41:03.272 EDT: //0/000000000000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 200 OK v:SIP/2.0/UDP 10.40.208.29:5060;branch=z9hG4bK68421E92 f:<sip: +18163484000@ims.eng.rr.com >;tag=66E22814-DA5 t:<sip: +18163484000@ims.eng.rr.com >;tag=1254025593 i:B4343033-F4BE11E4-84A6DB8F-ECAF76A@10.40.208.29 CSeq:102 SUBSCRIBE Expires:1210 m:<sip:abrscscf.ims.eng.rr.com:5090;lskpmc=S11> Record-Route:<sip:172.17.254.170;routing_id=pcscf_a_side;lskpmc=P11;lr;serv_user=10.40.208.29:5060> l:0 May 8 09:41:03.276 EDT: //-1//AFW_:EE6791A580000:/AFW_M_TclModule_Action: May 8 09:41:03.276 EDT: //-1//AFW_:EE6791A580000:/AFW_TclModule_DefaultEvHandling: May 8 09:41:03.280 EDT: //-1//TCL :EE6791A580000:/tcl_InfotagObjCmd: infotag get evt_status May 8 09:41:03.280 EDT: //-1//TCL :EE6791A580000:/tcl_InfotagGetObjCmd: infotag get evt_status May 8 09:41:03.280 EDT: //-1//AFW_:EE6791A580000:/vtr_ev_status: argc 2 argindex 2 May 8 09:41:03.280 EDT: //-1//TCL :EE6791A580000:/tcl_PutsObjCmd: status May 8 09:41:03.280 EDT: May 8 09:41:03.288 EDT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: NOTIFY sip:10.40.208.29:5060 SIP/2.0 v:SIP/2.0/TCP 172.17.254.170:5060;branch=z9hG4bKc96ca3c2c2e7da83fb9759288d008de5;lskpmc=P11 Record-Route:<sip:172.17.254.170;routing_id=pcscf_a_side;lskpmc=P11;lr> v:SIP/2.0/TCP 172.17.254.75:5090;branch=z9hG4bK93a8447a0d8890d6e32d6205611029d1;lskpmc=S11 f:<sip: +18163484000@ims.eng.rr.com >;tag=1254025593 t:<sip: +18163484000@ims.eng.rr.com >;tag=66E22814-DA5 o:reg i:B4343033-F4BE11E4-84A6DB8F-ECAF76A@10.40.208.29 Subscription-State:active CSeq:1 NOTIFY c:application/reginfo+xml m:<sip:abrscscf.ims.eng.rr.com:5090;lskpmc=S11> Max-Forwards:68 l:705 <?xml version="1.0"?><reginfo xmlns="urn:ietf:params:xml:ns:reginfo" xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance " version="0" state="full"><registration aor="sip: +18163484000@ims.eng.rr.com " id="7d94aa39111431092326854924" state="active"><contact id="111431092326854924" state="active" event="registered"><uri>sip:+18163484000@10.40.208.29:5060</uri><unknown-param name="audio"/></contact></registration><registration aor="sip:+18 163484001@ims.eng.rr.com ;end-num=18163484999" id="a9968911111431092326854924" state="active"><contact id="111431092326854924" state="active" event="created"><uri>sip:+18163484000@10.40.208.29:5060</uri><unknown-param name="audio"/></contact></registration></reginfo> May 8 09:41:03.296 EDT: //-1//AFW_:EE6791A580000:/AFW_M_TclModule_Action: May 8 09:41:03.296 EDT: //-1//AFW_:EE6791A580000:/AFW_TclModule_DefaultEvHandling: May 8 09:41:03.296 EDT: //-1//AFW_:EE6791A580000:/AFW_FSM_Drive: FSM no match for (NORMAL[2],ev_notify_indication[193]) May 8 09:41:08.296 EDT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 200 OK Via: SIP/2.0/TCP 172.17.254.170:5060;branch=z9hG4bKc96ca3c2c2e7da83fb9759288d008de5;lskpmc=P11,SIP/2.0/TCP 172.17.254.75:5090;branch=z9hG4bK93a8447a0d8890d6e32d6205611029d1;lskpmc=S11 From: sip: +18163484000@ims.eng.rr.com ;tag=1254025593 To: sip: +18163484000@ims.eng.rr.com ;tag=66E22814-DA5 Date: Fri, 08 May 2015 13:41:08 GMT Call-ID: B4343033-F4BE11E4-84A6DB8F-ECAF76A@10.40.208.29 CSeq: 1 NOTIFY Record-Route: <sip:172.17.254.170;routing_id=pcscf_a_side;lskpmc=P11;lr> Content-Length: 0

Alfred Johnson · ‎05-07-2015

The SIP Subscribe/Notify feature is documented in the IOS 15.1 SIP Config guide, and int the TCL IVR Applications Guide for IOS, so yes IOS does support it. You just set the event value to "reg" which makes it work for SIP registration events.

Alfred Johnson · ‎05-07-2015

Hi, I am trying to use TCL IVR to get my 2431/2921 VGWs to Subscribe to SIP registration events after successfully Registering with the SIP Proxy on our IMS system. Currently the VGW SIP stack does not support Subscribe/Notify for reg in native IOS code, but the TCL IVR does support a general purpose Subscribe/Notify capability. I wrote a TCL IVR script to do this, but the Subscribe message it sends is being rejected by the IMS, as shown below: May 7 12:52:20.459 EDT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SUBSCRIBE sip:+18163484000@172.17.253.69:5060 SIP/2.0 Via: SIP/2.0/UDP 10.40.208.29:5060;branch=z9hG4bK66F01AC3 From: sip: +18163484000@ims.eng.rr.com ;tag=626AEE7C-154D To: sip: +18163484000@ims.eng.rr.com Call-ID: 42C0EA2A-F41011E4-849CDB8F-ECAF76A@10.40.208.29 CSeq: 101 SUBSCRIBE Max-Forwards: 70 Event: reg Expires: 1210 Contact: <sip:10.40.208.29:5060> Content-Length: 0 May 7 12:52:20.471 EDT: //0/000000000000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 403 Forbidden - User Not Registered v:SIP/2.0/UDP 10.40.208.29:5060;branch=z9hG4bK66F01AC3 f:<sip: +18163484000@ims.eng.rr.com >;tag=626AEE7C-154D t:<sip: +18163484000@ims.eng.rr.com >;tag=1895008750 i:42C0EA2A-F41011E4-849CDB8F-ECAF76A@10.40.208.29 CSeq:101 SUBSCRIBE l:0 My VGW is actually registered to a somewhat different SIP-URI, before the Subscribe is sent, as shown below. VGW sip-ua Register From & To SIP-URI: <sip: +18163484000@ims.eng.rr.com > VGW TCL IVR Request-URI: sip:+18163484000@172.17.253.69:5060 May 7 12:52:51.303 EDT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: REGISTER sip:ims.eng.rr.com SIP/2.0 Via: SIP/2.0/UDP 10.40.208.29:5060;branch=z9hG4bK66F41259 From: <sip: +18163484000@ims.eng.rr.com >;tag=626B66C0-C9D To: <sip: +18163484000@ims.eng.rr.com > Call-ID: 551727A6-F41011E4-849DDB8F-ECAF76A Max-Forwards: 70 Timestamp: 1431017571 CSeq: 3 REGISTER Contact: <sip:+18163484000@10.40.208.29:5060> Expires: 600 Authorization: Digest username=" E06F4E57B7BDC175@ims.eng.rr.com ",realm="ims.eng.rr.com",uri="sip:ims.eng.rr.com:5060",response="21ad7384c27eb314a5e155099810eca7",nonce="0b31610d554b986311186304b1758c6c174e675f9fdecef68bf347",cnonce="074ED51F",qop=auth,algorithm=md5,nc=00000001 Content-Length: 0 May 7 12:52:51.363 EDT: //14200/000000000000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 200 OK v:SIP/2.0/UDP 10.40.208.29:5060;branch=z9hG4bK66F41259 f:<sip: +18163484000@ims.eng.rr.com >;tag=626B66C0-C9D t:<sip: +18163484000@ims.eng.rr.com >;tag=1185677959 i:551727A6-F41011E4-849DDB8F-ECAF76A CSeq:3 REGISTER m:<sip:+18163484000@10.40.208.29:5060>;audio;expires=600 Path:<sip:cakpcscf.ims.eng.rr.com:5070;lr> Service-Route:<sip: originating@abrscscf.ims.eng.rr.com :5090;reg-id=111431017571333507;lskpmc=S11;lr;ms_rest_id=S11554b9863> P-com.siemens.maximum-chat-size:1300 P-com.siemens.maximum-IM-size:1300 P-com.siemens.chat:direct P-Associated-URI:<sip: +18163484000@ims.eng.rr.com > P-Associated-URI:<sip: +18163484001@ims.eng.rr.com ;end-num=18163484999> l:0 Further below is my complete TCL IVR script, but the problem seems to be in the following TCL command that invokes the Subscribe: subscription open sip: +18163484000@ims.eng.rr.com SubscrParams For some reason, the subscription open command decides to do a dns query to resolve the host part of the URL parameter in the open, ims.eng.rr.com, and put the resulting IP address in the Subscribe Request-URI, I have an example of a Subscribe message that is accepted by IMS, from another platform we use shown below. You can see that its Request URI does not contain a resolved IP address, but puts the literal SIP Realm domain name for the host part. SUBSCRIBE sip: +18163225773@ims.eng.rr.com ;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.40.209.14:5060;branch=z9hG4bK-d8754z-6c19cd6b20f27144-1---d8754z-;rport Max-Forwards: 70 Route: <sip:eepcscf-gm.ims.eng.rr.com;lr> Contact: <sip:+18163225773@10.40.209.14:5060;user=phone> To: "Doscis SIP"<sip: +18163225773@ims.eng.rr.com ;user=phone> From: "Doscis SIP"<sip: +18163225773@ims.eng.rr.com ;user=phone>;tag=3879f398 Call-ID: NzE0YjY2NGU2ZDdjN2I4OGQ0ZjRmNWE0MmVkZDM2Njk. CSeq: 2 SUBSCRIBE Expires: 1210 Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, SUBSCRIBE, INFO, PRACK, UPDATE Proxy-Authorization: Digest username=" 192BAC9531407265@ims.eng.rr.com ",realm="ims.eng.rr.com",nonce="09c1a75f50cbb0471350477bc4b045cd697e3097e8c85e6a14bbca",uri="sip: +18163225773@ims.eng.rr.com ;user=phone",response="59d250ba43cb7866fef04c85c20a8890",cnonce="af43a5e3373f5c52",nc=00000001,qop=auth,algorithm=MD5 Supported: timer User-Agent: ESBC9328-4B-2.0.12.40-Build3 Event: reg Content-Length: 0 SIP/2.0 200 OK v:SIP/2.0/UDP 10.40.209.14:5060;branch=z9hG4bK-d8754z-6c19cd6b20f27144-1---d8754z-;rport=5060;received=10.40.209.14 t:"Doscis SIP"<sip: +18163225773@ims.eng.rr.com ;user=phone>;tag=2145026813 f:"Doscis SIP"<sip: +18163225773@ims.eng.rr.com ;user=phone>;tag=3879f398 i:NzE0YjY2NGU2ZDdjN2I4OGQ0ZjRmNWE0MmVkZDM2Njk. CSeq:2 SUBSCRIBE Expires:1210 m:<sip:rdceescscf2.ims.eng.rr.com:5090;lskpmc=S35> Record-Route:<sip:172.17.254.170;routing_id=pcscf_a_side;lskpmc=P19;lr;serv_user=10.40.209.14:5060> l:0 So I am wondering if anybody knows how I can do to get the TCL IVR subscription open command to use the literal SIP realm domain name instead of the resolved IP address in the Subscribe's Request-URI. I would certainly appreciate any help anyone can offer. Below is the full TCL script, followed by the brief IOS application config statements that invoke it.. Alfy Johnson Time Warner Cable, Herndon Virginia bctrunks-2431-4#show call application voice SubscribeReg Script Name : SubscribeReg URL : flash:SubscribeReg.tcl Type : Service State: Registered Life : Configured Exec Instances: 1 Parameters registered under SubscribeReg namespace: name type default value description uid-len I 10 the number of digits in UID warning-time I 30 the time (in secs) within which a user is warned before the calling time expires (call terminates) pin-len I 4 the number of digits in PIN retry-count I 3 the number of attempts to reenter PIN redirect-number S the telephone number where a call is redirected to Script Code Begin: -------------------------------- TCL Script version 2.0 - 2.1 # SubscribeReg.tcl #------------------------------------------------------------------ # Script Version 0.1 - 2015-5-5 # # This tcl script # #------------------------------------------------------------------ proc init { } { global param } proc Send_Subscribe { } { # not working set headers(User-Agent) "Cisco 2431 15.1 TCL IVR 2.0" set headers(From) "sip: +18163484000@ims.eng.rr.com " set headers(To) "sip: +18163484000@ims.eng.rr.com " set SubscrParams(protoHeaders) headers set SubscrParams(event) reg set SubscrParams(expirationTime) 1210 set mySubID [subscription open sip: +18163484000@ims.eng.rr.com SubscrParams] } proc Check_Response { } { set status [infotag get evt_status] puts status if { $status != "su_000"} { puts "Successful Subscribe" } } proc Timeout { } { puts "Expires Timer Expired" } proc act_Abort { } { puts "Unexpected event - entering act_Abort" call close } init #---------------------------------- # State Machine #---------------------------------- set SubscribeSM(any_state,ev_disconnected) "act_Abort,same_state" set SubscribeSM(SUBSCRIBING,ev_any_event) "Send_Subscribe,WAIT_FOR_RESPONSE" set SubscribeSM(WAIT_FOR_RESPONSE,ev_subscribe_done) "Check_Response,NORMAL" set SubscribeSM(NORMAL,ev_unsubscribe_indication) "Timeout,SUBSCRIBING" fsm define SubscribeSM SUBSCRIBING -------------------------------- bctrunks-2431-4#srs application application service SubscribeReg flash:SubscribeReg.tcl ! monitor interface stats interface event-log interface event-log flash stats event-log ! bctrunks-2431-4#ssrs Line peer expires(sec) registered P-Associ-URI ================================ ========== ============ ========== ============ +18163484000 -1 162 yes +18163484000 +18163484001

Alfred Johnson · ‎05-06-2015

I am currently trying to use the Cisco IOS TCL IVR package to implement a SIP SUBSCRIBE to SIP Registration events. I have yet to get a SUBSCRIBE to go out of the VGW.

Alfred Johnson · ‎04-30-2015

I have not found a good solution to this problem. Currently, our Operations people know about the issue and know that when they update the subscriber account on the IMS manually the VGW will become dergistered. They then know that they need to manually log into the VGW and force it to reregister. I wrote a short eem applet so they can do this with a simple cli alias command 'newreg'. The situation leave a lot to be desired, but that's where we are today.

Alfred Johnson · 11-09-2016

Does this mean that Cisco does not support the use of the C-Scripts by customers? If so, why do they...

Alfred Johnson · 11-08-2016

bctrunks-2431-4#show call application voice RetrProxy Script Name : RetrProxy URL : builtin:Retrieva...

Alfred Johnson · 09-22-2016

You may be able to use either SNMP or CLI commands to monitor a trunk, but I am not familiar enough ...

Alfred Johnson · 09-06-2016

I just googled 'eem applet reboot' and the 2nd result was: Cisco – how to schedule an unattended rel...

Alfred Johnson · 08-17-2015

I found a detailed example in the 15M & T SIP Config Guide, starting on page 213. However, I am stil...

Alfred Johnson · 08-16-2015

I have been able to use TCL IVR application to send a SIP SUBSCRIBE to a SIP proxy on an IMS for SIP...

Alfred Johnson · 06-01-2015

I have spent a little more time fleshing out my Subscribe/Notify state machine, and I was trying to ...

Alfred Johnson · 05-18-2015

This TCL Subscribe/Notify feature is specifically for the SIP protocol (Session Initiation Protocol,...

Alfred Johnson · 05-08-2015

I got a very basic TCL IVR application to send a Subscribe to our IMS and receive a notify. You have...

Alfred Johnson · 05-08-2015

I was able to get the Subscribe to work using the voice class sip-profiles command to modify the out...

Alfred Johnson · 05-07-2015

The SIP Subscribe/Notify feature is documented in the IOS 15.1 SIP Config guide, and int the TCL IVR...

Alfred Johnson · 05-07-2015

Hi,I am trying to use TCL IVR to get my 2431/2921 VGWs to Subscribe to SIP registration events after...

Alfred Johnson · 05-06-2015

I am currently trying to use the Cisco IOS TCL IVR package to implement a SIP SUBSCRIBE to SIP Regis...

Alfred Johnson · 04-30-2015

I have not found a good solution to this problem. Currently, our Operations people know about the is...

Alfred Johnson · 04-29-2015

I need to write a tcl ivr application to validate a received redirecting number against a list of 10...

Date Registered	‎06-09-2010 06:45 AM
Date Last Visited	‎08-18-2017 04:00 AM
Total Messages Posted	31
Total Helpful Votes Received	14

Re: Where can I find descriptions of th...

Re: Where can I find descriptions of th...

Re: TCL issue : Can´t read .. no such v...

You may be able to use either

I just googled 'eem applet

I found a detailed example in

Need working example of SIP NOTIFY mess...

I have spent a little more

This TCL Subscribe/Notify

I got a very basic TCL IVR

Re: Issue with TCL IVR 2.0 Subscribe/No...

Re: Issue with TCL IVR 2.0 Subscribe/No...

Issue with TCL IVR 2.0 Subscribe/Notify...

I am currently trying to use

I have not found a good

Re: Where can I find descriptions of the built-in ios tcl and C scripts shipped in ios 15.1