Q1: I agree that the emergency services use case is important. However, I would like to see the statement that some devices do not support outbound but want to use the keep alive mechanism be further clarified (what devices this applies to and why they would not implement outbound - I think this has already been discussed on the list).
Q2: Based on my comments to Q1, I would like to see the requirements narrowed in scope to only be in the context of a dialog initiating request outside of a registration. The reason being that outbound is the approach defined by the WG for client to Edge Proxy NAT traversal and I don't think there is a strong need for more tools which allow the creation of another NAT traversal solution. This narrowing of scope would still allow support by devices which would not implement outbound and are not providing edge proxy functionality. Regards, Kevin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DRAGE, Keith (Keith) Sent: Thursday, June 19, 2008 3:31 AM To: [email protected] Cc: Christer Holmberg Subject: [Sip] 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
