Sushil, Rama,
Sushil - if you haven't already definately read RFC3265 'SIP Specific Event Notification' as referenced by Rama, however I have slightly different answers to your questions. It is possible to send a un-solicited Notify - but the UA doing this should have an idea of the token's that the end UA will support - whether this is coded in as a known quantity or queried with Info or another method. Example:
Currently implemented are SIP UA (phone's or GW's) that include the Allow-Events header in the Register message with the tokens they support - allowing the registrar to know the capabilities of the end point - the specific example is "Allow-Events:telephone-event". This is saying that the UA will accept a unsolicited Notify for the purposes of turning the MWI on / off, which co-incidentally is the answer to your second question.
On unsubscribing, I haven't read 2848 - but have got it now and will have a read. I have seen some discussion in this forum on unsubscribing and the method that seemed to have more backing was to use a Subscribe message with an expires of 0. Perhaps someone else can best answer your third question.
Regards,
Wayne Davies
email: [EMAIL PROTECTED]
| Ramachandran Iyer <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 20/04/2004 08:39 PM
|
To: Sushil Kumar Verma <[EMAIL PROTECTED]>, [EMAIL PROTECTED] cc: Subject: Re: [Sip-implementors] Unsolicited NOTIFY |
inline...
Sushil Kumar Verma <[EMAIL PROTECTED]> wrote:
| Hi All,
I'll be thankful if you can help me in finding the answer for following questions. For first two questions, if a UA and the server (e.g. voice mail server) have some prior agreement for the services. Q1. Is it possible, in general, to send an unsolicited NOTIFY i.e without a SUBSCRIBE request? Q2. Is it possible to send unsolicited NOTIFY to send MWI (message waiting indication) ? [Rama] I think both your questions are linked. As Per 3265 (Specific event notification spec) NOTIFY's are only solicited messages. These NOTIFY's can only be sent (with whatever event/state information that needs to be passed across) in lieu with an already established subscribtion for these set of events via a SUBSCRIBE. So in the context of the spec its not syntactically correct to send unsolicited NOTIFY's. But if you are referring to the aggrement as some kind of a tweek, where the other party is ready to accept NOTIFY's voluntarity then i guess its just an arrangment between both of you'll, which is obviously not a general practise. What i can also see is the current NOTIFY'cations are boung with the subscribtion and bound for certain events to be notified, though a more flexible and open ended on the fly.. NOTIFY'cations could add more value. But i guess we dont have any such guidelines for that type of mid call profiling/information passing at this point in time. If there is we will hear back in this mail chain. Q3. Why an UNSUBSCRIBE method (mentioned in PINT RFC 2848) is requied while SUBSCRIBE and NOTIFY methods are capable enough to close the subscription? [Rama] Yes, a SUBSCRIBE with an expires '0' should do the job as well.. Thanks in advance. Regards, Sushil Kumar Axes Tecnologies (I) Pvt. Ltd. | |||
|
|
____________________________________________________
IncrediMail - Email has finally evolved - Click Here _______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25�_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
