My nua_i_notify callback handler checks to see if the incoming NOTIFY handle matches the subscription handle.
If it matches, it is a subscribed NOTIFY and there is no need to respond.
If it does not match, then it is an un-subscribed NOTIFY, and I call nua_respond() and nua_handle_destroy().

Colin..


Michael Jerris wrote:

Is there an easy way to use this in combination with the way notifies were handled before where either ones that were 481’d before are instead sent to nua_i_notify, but the ones that nua handled before (the ones with matching subscriptions) will continue to be handles as before, or a simple way to write a function for nua_i_invite that will sort out between the 2 and send the ones that were handled before back to the code that handles them otherwise?

 

Mike

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Colin Whittaker
Sent: Thursday, February 01, 2007 8:31 PM
To: Colin Whittaker
Cc: Pekka Pessi; [email protected]
Subject: Re: [Sofia-sip-devel] NOTIFY not getting to the application.

 

Well, it appears to work if I put the

NUTAG_APPL_METHOD("NOTIFY")
 

in it's own nua_set_params() call.

The other tags I am using are:
                    NUTAG_AUTOACK( 0 ),
                    NUTAG_AUTOALERT( 0 ),
                    NUTAG_AUTOANSWER( 0 ),
                    NUTAG_EARLY_MEDIA( 0 ),
                    NUTAG_ENABLEINVITE( 1 ),
                    NUTAG_ENABLEMESSAGE( 0 ),
                    NUTAG_ENABLEMESSENGER( 0 ),
                    SIPTAG_ALLOW_STR( allow_str ),
                    SIPTAG_SUPPORTED_STR( "timer" ),
                    NTATAG_REL100( 0 ),

And I am getting the nua_i_notify for unsubscribed and subscribed NOTIFY messages.
Cool. Thanks for the quick implementation.
Let me know if I can help diagnose the crash any further.

Colin..

Colin Whittaker wrote:

Ok, here is a better backtrace from gdb:

#0  0x0fc89be8 in kill () from /lib/libc.so.6
#1  0x0ff08bec in pthread_kill () from /lib/libpthread.so.0
#2  0x0ff09254 in raise () from /lib/libpthread.so.0
#3  0x0fc8b26c in abort () from /lib/libc.so.6
#4  0x0fc83014 in __assert_fail () from /lib/libc.so.6
#5  0x100a8100 in su_free (home=0x7fffeba8, data="" at su_alloc.c:772
#6  0x100ef4f4 in msg_header_free (home=0x0, h=0x6) at msg_parser.c:3029
#7  0x1006ca7c in nhp_merge_lists (home=0x7fffeba8, hc=0x10126288, return_new_list=0x7fffeaf4, old_list=0x10b5a408, already_set=1,
    already_parsed=1, always_merge=1, value=0) at nua_params.c:1029
#8  0x1006c380 in nhp_set_tags (home=0x7fffeba8, nhp=0x7fffeb28, global=1, tags=0x8) at nua_params.c:875
#9  0x1006b870 in nua_stack_set_params (nua=0x10b581d8, nh=0x10b5a1a0, e=nua_r_set_params, tags=0x10b5bffc) at nua_params.c:505
#10 0x10064004 in nua_stack_signal (nua=0x10b581d8, msg=0x7fffec48, e=0x10b5bfe8) at nua_stack.c:385
#11 0x10100c78 in su_base_port_execute_msgs (queue=0x0) at su_base_port.c:253
#12 0x101009c0 in su_base_port_getmsgs (self=0x10b58150) at su_base_port.c:179
#13 0x10100f14 in su_base_port_step (self=0x10b58150, tout=1) at su_base_port.c:414
#14 0x100acd98 in su_root_step (self=0x0, tout=6) at su_port.h:333
#15 0x10033d60 in sip_poll () at esa_sip.c:64
#16 0x10024d84 in main (argc=10, argv=0x7ffffba4) at esacad.c:445
#17 0x0fc763a8 in __libc_start_main () from /lib/libc.so.6


Pekka Pessi wrote:

On 1/31/07, Colin Whittaker <[EMAIL PROTECTED]> wrote:
  
 When you said should not be too hard, which approach do you think is best /
easiest ?
    
 
Pushed to darcs:
 
Fri Feb  2 02:12:21 EET 2007  [EMAIL PROTECTED]
  * nua: allow unsolicited NOTIFY.
 
  When NUTAG_NEWSUB(1) is included in nua_notify() tags, notifier will allow
  sending unsolicited NOTIFY without existing subscription.
 
  When NUTAG_APPL_METHOD("NOTIFY") is included in nua_set_params() tags,
  incoming NOTIFYs are to be processed and accepted by application.
 
A usage example is in test_simple.c. Comments?
 
--Pekka
 
  
 Pekka Pessi wrote:
 On 1/31/07, Colin Whittaker <[EMAIL PROTECTED]> wrote:
 
 
 It appears that Sofia does not allow support for unsolicited NOTIFY events.
This is a problem for proxies which prefer to generate message waiting
NOTIFY packets without supporting subscription.
The NORTEL DMS is an example of such a proxy.
It replies 501 to a SUBSCRIBE for message-summary, but sends a NOTIFY
when a voice-mail is available.
 
 OK. What is the event there, "message-summary"? Is there a single
NOTIFY only, or several? And is the Subscription-State header included
in the request? And is the NOTIFY sent within an existing dialog or
outside them? A message trace from tcpdump/ethereal/wireshard would be
doubleplusgood.
 
 
 
 It seems to me the stack should forward the NOTIFY to the application
via the nua_i_notify. Then the application could handle it
appropriately. i.e. send back the 481 if it does not want it.
I realize this would be outside a dialog, but it still seems like it
should be up to the application even if it has to handle the nua_handle
differently for subscribed NOTIFYs and non-subscribed NOTIFYs. I think a
simple check to see if the handle is the same as the subscription handle
is an easy test.
 
 
 
 Alternatively, the application could subscribe for any NOTIFY packet
silently somehow. Or a TAG that allows un-subscribed NOTIFY packets to
get processed by the application.
What do you think ?
 
 Should not be too hard..
 
 
 
 Is this such a large violation of the spec that I need to push Nortel to
fix their side ?
 
 Nope. I think there are also other uses of unsolicitated NOTIFYs.
 
 
 
 
    
 
 
  
 


 
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
 



 
_______________________________________________
Sofia-sip-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
  

------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________ Sofia-sip-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sofia-sip-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Reply via email to