Hi, I see this also as useful to have the proxy-proxy behaviour covered. BR
Roland > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im > Auftrag von Christer Holmberg > Gesendet: Mittwoch, 25. Juni 2008 00:05 > An: Hadriel Kaplan; Elwell, John; DRAGE, Keith (Keith); [email protected] > Betreff: Re: [Sip] Progress draft-holmberg-sip-keep > > > Hi, > > As I said before, I would be happy to extend the scope to > also cover proxy-proxy. I have also received an off-line > comment indicating that it would be useful. I don't think it > would change the mechanism itself, so... > > So, if we choose to move forward with the draft I would then > update the scope etc it in the next version. > > Does that sound ok? > > Regards, > > Christer > > -----Original Message----- > From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > Sent: 24. kesäkuuta 2008 19:11 > To: Elwell, John; DRAGE, Keith (Keith); [email protected] > Cc: Christer Holmberg > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > > > > Those cases are the ones I said would be useful in my > original email far below. I.e., when I said "two reasons not > cited: PBX connections a la SIP trunks, and proxy-proxy > connections." They are not identical, in the sense that an > IP-PBX can be a b2bua/UA/whatever, but also in the sense of > their example use-case, for example an IP-PBX could be behind > a NAT and thus want this keep-alive for more reasons than a > proxy-proxy. > > -hadriel > > > -----Original Message----- > > From: Elwell, John [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 24, 2008 11:48 AM > > To: Hadriel Kaplan; DRAGE, Keith (Keith); [email protected] > > Cc: Christer Holmberg > > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > > > > Hadriel, > > > > That trunking case is no different from other trunking cases, e.g., > > proxy-to-proxy, and I have already suggested to Christer > that he might > > extend the scope of the draft to cover that. It would be > good to have > > some discussion on whether keep-alive on "trunking" > interfaces would > > be beneficial - I have an open mind on that at present. > > > > John > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > > > Sent: 24 June 2008 16:32 > > > To: Elwell, John; DRAGE, Keith (Keith); [email protected] > > > Cc: Christer Holmberg > > > Subject: RE: [Sip] Progress draft-holmberg-sip-keep > > > > > > Hey John, > > > For the case where the IP-PBX registers into the SP, > outbound can be > > > used. But it's the other case I was talking about: > > > where the IP-PBX does NOT register into the SP, but it > instead is a > > > trunk. > > > > > > -hadriel > > > > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:[EMAIL PROTECTED] > > > > Sent: Tuesday, June 24, 2008 3:15 AM > > > > 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 > _______________________________________________ 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
