My 2 cents: it is a useful draft.  Personally, I would like to have it 
available for two reasons not cited: PBX connections a la SIP trunks, and 
proxy-proxy connections.  Today I think a lot of people are using OPTIONS 
requests or proprietary means to perform such keep-alives when registration is 
not appropriate, but it has led to some interop issues and performance concerns 
in some cases.

Since the contentious issue of what form the keep-alives take have already been 
agreed on for outbound, this seems like a simple draft to get done. (famous 
last words, I know)

-hadriel


> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> DRAGE, Keith (Keith)
> Sent: Thursday, June 19, 2008 5: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

Reply via email to