Can the method name used for signaling be a negotiated parameter as well, in addition to the event package? So if the endpoints in dialog want to use NOTIFY, they can do that and if other pair of endpoints want to use INFO or some new method, they can do that as long as both agree on that. Regarding concern of whether proxies in the middle of signaling path will pass this NOTIFY along or not, the endpoints can exchange their addresses as part of this event package negotiation, like c line in SDP. So dtmf signaling will be sent end-to-end and will not traverse a proxy that has added itself in signaling path with a RR header.
Sanjay >-----Original Message----- >From: Paul Kyzivat (pkyzivat) >Sent: Monday, October 22, 2007 9:37 AM >To: Brian Stucker >Cc: sip; Adam Roach; Michael Procter; Elwell,John >Subject: Re: [Sip] INFO > >I'm clearly in the minority here, in preferring NOTIFY over INFO. >(Minority of one?) > >I agree that it is impossible to make definitive claims that >something is easy to implement when talking about some >hypothetical sip stack. So I will refrain from making such a >claim from now on. > >I also agree that the name of the method is secondary to >getting the functionality right. So I am fine with leaving the >decision about the method until everything else is worked out. > >So, I think the next question is whether there should be a >single event package definition mechanism for this new >approach and for the 3265 type of events, or if these should >be entirely disjoint. I realize existing event package >definitions won't be applicable without at least some tweaks, >and not all event types are suitable for both mechanisms. But >I do think there are event types that are suitable for both >mechanisms (e.g. dtmf and dialog) and it would be better if we >didn't require independent definitions for them in both contexts. > >What do others think of that? > > Thanks, > Paul > >Brian Stucker wrote: >> >> >>> -----Original Message----- >>> From: Michael Procter [mailto:[EMAIL PROTECTED] >>> Sent: Monday, October 22, 2007 3:01 AM >>> To: Stucker, Brian (RICH1:AR00); Paul Kyzivat; Hadriel Kaplan >>> Cc: Elwell, John; sip; Adam Roach >>> Subject: RE: [Sip] INFO >>> >>> >>>> -----Original Message----- >>>> From: Brian Stucker [mailto:[EMAIL PROTECTED] >>>> Sent: 22 October 2007 08:48 >>>> To: Paul Kyzivat; Hadriel Kaplan >>>> Cc: Elwell, John; sip; Michael Procter; Adam Roach >>>> Subject: RE: [Sip] INFO >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Hadriel >>> Kaplan wrote: >>>>>>> -----Original Message----- >>>>>> Lastly, you don't *have* to support rfc3265 at all to >>>>> support 3261, so the code change could be quite a bit more. >>>>> >>>>> For somebody that doesn't support 3265, and doesn't want to, but >>>>> that does want to support these new packages within an >>> INVITE, this >>>>> is all new implementation in any case. Sure, it would require >>>>> supporting the NOTIFY *method*, as it is used in this new >>> usage. But >>>>> the hard work is in supporting the packages, not the method. And >>>>> that part is the same either way. >>>>> >>>> I don't agree that the method won't be hard to support. For >>> one thing, >>>> many people use stock SIP stacks they got from somewhere >>> else and have >>>> no idea how to add a new method or usage of a method >>> because they've >>>> simply never had to do so before or simply can't due to >>> other issues. >>>> Adding methods or a new nuance to an existing method may >>> look easy on >>>> paper, but it can be a lot harder to do in practice. Much >>> harder than, >>>> say, putting code together to toString your registration >>> entries into >>>> XML for regevent. >>> On a similar note, I suspect that adding a header (Event?) to INFO >>> would be simpler than subtracting a mandatory header >>> (Subscription-State) from NOTIFY, purely in terms of the >support for >>> each in 3rd party stacks. >>> >>> Of course, I am making a whole bunch of assumptions here >that aren't >>> necessarily true. So maybe this decision can be postponed until a >>> few more details are ironed out. >>> >> >> In this case, I think it's a pretty safe assumption. Subtracting >> mandatory headers from a method is not a great idea because >now you've >> added a new path in the code where the header is semi-mandatory and >> the information to determine when it is mandatory, and when >it is not, >> is not present in the message itself (so the stack may have >to ask the >> application what's going on when it's trying to verify that the >> message is minimally correct which may not be possible/desirable). >> >> If I get an INFO with an event header in it, and I'm not looking for >> an event header in an INFO, then I'm no worse off than I am >today, right? >> Besides, the event header isn't useful to the lower protocol layers. >> It's only useful to the application itself, whereas the >> subscription-state header is often handled by another chunk of code >> whose sole responsibility is to maintain subscriptions and >is neither >> part of the stack, nor the application, but used by both. >> >> Regards, >> Brian >> > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use >[EMAIL PROTECTED] for questions on current sip >Use [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
