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=0x10b5a408) 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]>
<mailto:[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]>
<mailto:[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
