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.

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.

Ok, sounds interesting..

My team and me are currently investigating in a similar thing. We would like to receive a SIP-Notify.. when we have any update that may help you I´ll provide it to you.

Torsten

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

Wow, that look impressive, thanks for sharing it.

I guess that will give us a good starting point for our approach

Thank you for sharing! I want use the sip Notify to trigger a WSMA initiator profile. The router is behind a firewall and with this method the backend should direct triggered. Alfred is it possible inside an IVR application to execute CLI commands? 

Maybe, the EEM can have a syslog event detector that looks for the sip commands. I can’t find the correct event pattern for that. Do you think that could be an approach for that?

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.

Yes, exactly. I tried to catch the SIP Notify Event to trigger another TCL script with wsma stuff. Another program sends the Sip Notify packet to the router and the sip message is also displayed in the log. In the state machine I look for the ev_notify event, but I am not sure if that can work. I was not able to catch that sip event. Have you any idea why it does not work?

Here my sample code:

proc act_init { } {
    set syslog [open "syslog: " w+]
    puts $syslog "init script...."
    close $syslog
}

proc act_Notify { } {
    set content_type [infotag get evt_proto_content_type]
    puts "\n\n\n**** Notification content_type=$content_type\n\n"

    set content [infotag get evt_proto_content]
    puts "\n\n\n**** Notification content=$content\n\n"

    set syslog [open "syslog: " w+]
    puts $syslog "message notify recived...."
    close $syslog
}

proc act_Abort { } {
    puts "Unexpected event - entering act_Abort"
    call close
}

#----------------------------------
#  State Machine
#----------------------------------
set fsm(any_state,ev_disconnected) "act_Abort same_state"
set fsm(any_state,ev_notify) "act_Notify same_state"
set fsm(INIT,ev_any_event) "act_init same_state"

fsm define fsm INIT

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.

Thank you very much! I had also no success to detect the ev_notify event. I try now if i am able to catch the ev_notify_done event.

In my application, i want to use the sip notify to trigger some WSMA functions. The IVR script should write on sip notify a message into the syslog. Another EEM script detects that entry in syslog and creates a wsma initiator profile (CLI Commands). It is not an optimal solution but I found no better way to do it..