[EMAIL PROTECTED] wrote:
Paul,
When I mentioned a UA including the allow-events field I was thinking actually of having seen it implemented in Cisco -
Well, we all have our crosses to bear. :-)
To be fair, people have to do pragmatic things to get systems to work, and I won't fault them for doing so.
But here we are talking about how we *want* this to work. (Well, at least on the sip and sipping lists we are. Maybe not so much so on sip-implementors.)
In any case, I was answering on the basis of how I think sip is intended to / should work.
Now back to my day job.
Paul
> ok I said in
a Register message when the example below has it in the Invite. Now UA's don't subscribe to phones normally - although I have seen this discussed for purposed of call processing such as subscribing to a phone for a "Camp on" function and recieving a notify when the user is off the current call. I may have misread you but it seemed you were saying this should not happen.
INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0 Via: SIP/2.0/UDP 172.22.191.8:5060;branch=z9hG4bK83E From: "David Kemp" <sip:[EMAIL PROTECTED]>;tag=5B1DD14-1E96 To: <sip:[EMAIL PROTECTED]> Date: Thu, 15 Apr 2004 01:04:59 GMT Call-ID: [EMAIL PROTECTED] Supported: 100rel,timer Min-SE: 1800 Cisco-Guid: 3193630158-2377060824-2175270915-3812211944 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, ROB-VO3#UPDATE, REGISTER CSeq: 101 INVITE Max-Forwards: 6 Remote-Party-ID: "David Kemp" <sip:[EMAIL PROTECTED]>;party=calling;screen=no;privacy=off Timestamp: 1081991099 Contact: <sip:[EMAIL PROTECTED]:5060> Expires: 180 *Allow-Events: telephone-event* Content-Type: application/sdp Content-Length: 247
v=0 o=CiscoSystemsSIP-GW-UserAgent 2457 2674 IN IP4 172.22.191.8 s=SIP Call c=IN IP4 172.22.191.8 t=0 0 m=audio 19142 RTP/AVP 0 101 c=IN IP4 172.22.191.8 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20
Regards,
Wayne Davies email: [EMAIL PROTECTED]
*Paul Kyzivat <[EMAIL PROTECTED]>*
21/04/2004 07:10 AM
To: [EMAIL PROTECTED]
cc: Ramachandran Iyer <[EMAIL PROTECTED]>, Sushil Kumar Verma <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [Sip-implementors] Unsolicited NOTIFY
I would qualify this a bit further. I think you can send an "unsolicited" NOTIFY only if there is an implicit subscription with the recipient. How this implicit subscription would come about is something you need to work out. An example is REFER, where the REFER message is understood to cause an implicit subscription.
The implicit subscription implies the need for a dialog, and of course the notifier and the subscriber need to agree on the dialog id. There are already cases where the subscriber first learns of the dialog via the first NOTIFY sent over it. So in the absence of anything better, this would be a possibility. It should be pretty important to support the subscriber unsubscribing from this implicit subscription to avoid being bothered. This is done by sending a (re)SUBSCRIBE in the same dialog, with the same event type and event id, and an Expires:0.
Having said all that, it is a bad idea. The existing case with REFER is already regretted, so it is unlikely that any other instance of implicit subscriptions will ever be standardized.
If you feel a need to do something unsolicited, especially if it is based on configuration rather than some runtime action of the recipient, I think it would be better to use PUBLISH.
Paul
[EMAIL PROTECTED] wrote:
>
> 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.
> >
>
>
> _____________________________________________________
> _ <http://www.incredimail.com/redir.asp?ad_id=309&lang=9> /IncrediMail/
> - *Email has finally evolved* - *_Click Here_*
> <http://www.incredimail.com/redir.asp?ad_id=309&lang=9>
> _______________________________________________
> 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�_
> <http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=23765/*http://photos.yahoo.com/ph/print_splash>_______________________________________________
> 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
------------------------------------------------------------------------
_______________________________________________ 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
