Keith, We would find this very useful. Being the mechanism can be used between any two SIP entities, I agree with John to expand the scope to reflect that.
We support proxy to proxy being in, as it is needed for the network deployments. Martin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DRAGE, Keith (Keith) Sent: Wednesday, June 25, 2008 5:37 AM To: [email protected] Cc: Christer Holmberg Subject: Re: [Sip] Progress draft-holmberg-sip-keep (As SIP WG cochair) While I am seeing some traffic on the list, I am not yet seeing enough clear answers to the two questions asked to progress this to the AD as a charter request. Can I ask people who have already participated in the discussion to repost in regard to the questions asked. Can I ask more people in the group to review and and post their opinions on the two questions. Additionally, one issue that has been raised is proxy to proxy usage. If this draft progresses, is that an additional complexity that should be in or out? Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: Wednesday, June 18, 2008 11:28 PM > To: [email protected] > Cc: 'Christer Holmberg' > Subject: Progress draft-holmberg-sip-keep > > (As SIP WG cochair) > > We have been asked by the author of > > http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt > > Whether the SIP WG can progress this document. > > Because this draft arose as a result of the discussion of > outbound, and indeed seems to reuse the requirements from > outbound, and these requirements never really got handled in > the SIPPING WG, it has been agreed with the SIPPING chairs > that we will handle this entirely within SIP. > > Now in order to ask for charter milestones, and indeed when > we finally present this to IESG, we will be asked for the > level of support in the WG, which is also predicated on does > this fix a real problem, or is it just a corner case with > limited application. So: > > QUESTION 1 TO SIP WG: Are the use cases sufficiently > important to proceed with this draft? The document states: > > Chapter 3.5 of draft-ietf-sip-outbound-13 [I-D.ietf-sip-outbound] > defines two keep-alive techniques. Even though the keep-alive > techniques are separated from the Outbound mechanism > [I-D.ietf-sip-outbound], it is currently not possible to indicate > support of the keep-alive techniques without also > indicating support > for the Outbound mechanism. > > The Outbound mechanism is enabled during the UA registration phase. > However, there are use-cases where the UA does not register itself, > but still needs to be able to make calls and maintain NAT bindings > open during the duration of that call. A typical example is > emergency calls. There are also cases where entities do > not support > the Outbound mechanism, but still want to be able to > indicate support > and use the keep-alive techniques defined in > [I-D.ietf-sip-outbound]. > > At first sight this is not the most inspiring declaration of > the need for the document. Please respond indicating whether > you consider this a useful draft, and propose text that you > think would be useful in this section. Conversely, if you > think this draft is not useful and the WG has other more > important things to work on first, please also respond. > > QUESTION 2 TO SIP WG: Do we have a robust set of requirements > for proceeding with this work? The document currently lists: > > REQ 1: It MUST be possible for a UA to indicate support of > the keep- > alive techniques defined [I-D.ietf-sip-outbound] if the UA supports > only the keep-alive part of [I-D.ietf-sip-outbound]. > > REQ 2: It MUST be possible for an edge proxy to indicate support of > the keep-alive techniques defined [I-D.ietf-sip-outbound] > if the edge > poxy supports only the keep-alive part of [I-D.ietf-sip-outbound]. > > It would be desirable to agree these at the outset, and not > revisit them if we continue with the work. So if you require > clarification, modification, or addition to these two > requirements, then please also response with your questions > and proposals. > > I suggest we would like responses by 30th June 2008 in order > to allow the author to revise the document before the > deadlines. Please note that we are looking to make this > decision on the list within this deadline based on responses > received, not leave it until the Dublin meeting. > > Regards > > Keith _______________________________________________ Sip mailing list https://www.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://www.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
