Christer, The majority of the specification talks about a UA as client and an edge proxy as server. The only hint that it might be applied in other situations is in section 8 "Overlap with connection reuse", but there is no normative language there. So the scope clearly seems to be between a UA and an edge proxy, and I don't see much value in that (i.e., might as well support sip-outbound).
If you wish to extend the scope so that it can operate between any two SIP entities, and in particular between two proxies, then that is a different matter. There may be valid use cases, but I can't recall whether these have been discussed. Will the same technical solution apply (e.g., in terms of which side is the client, which side chooses the timer value, what is the default timer value, etc.)? I think Keith's questions related to the present draft (01) and I interpret the scope as UA to edge proxy only. If you wish to extend the scope, this would require a revised draft before making any decision on adopting as a work item. John > -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: 24 June 2008 08:20 > To: Elwell, John; Hadriel Kaplan; DRAGE, Keith (Keith); [email protected] > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > > > Hi John, > > SIP-keep CAN be used proxy-to-proxy, B2BUA-to-B2BUA etc. ANY > entity (e.g. a proxy) can insert the keep parameter in its > Via header, and if the next entity adds a "yes" value the > "keep-alives" can be used between those entities. > > Regards, > > Christer > > > -----Original Message----- > From: Elwell, John [mailto:[EMAIL PROTECTED] > Sent: 24. kesäkuuta 2008 10:15 > To: Hadriel Kaplan; DRAGE, Keith (Keith); [email protected] > Cc: Christer Holmberg > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > > 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
