Hadriel, Concerning your "PBX connections a la SIP trunks" use case, I am not convinced of this. ETSI TISPAN has specified two ways for an IPPBX to connect to a service provider. One is the so-called subscription-based approach, where the IPPBX registers with the SP and communicates via an edge proxy. In this case, why not use SIP-outbound? The other is the so-called peering-based approach, which is essentially the same as any SIP "trunk", e.g., proxy-to-proxy, B2BUA-to-B2BUA, proxy-to-gateway. SIP-outbound does not apply to these situations, and similarly the keep-alive mechanism is not specified for this cases. The requirements in SIP-keep do not cover these situations.
Basically I am not sold on the idea of a separate SIP-keep spec - I don't think it would be the best use of WG time. John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Hadriel Kaplan > Sent: 20 June 2008 18:20 > To: DRAGE, Keith (Keith); [email protected] > Cc: Christer Holmberg > Subject: Re: [Sip] Progress draft-holmberg-sip-keep > > > 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 > _______________________________________________ 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
