[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:john.elwell at siemens.com]
Sent: 24. kesäkuuta 2008 10:15
To: Hadriel Kaplan; DRAGE, Keith (Keith); sip at ietf.org
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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
> Hadriel Kaplan
> Sent: 20 June 2008 18:20
> To: DRAGE, Keith (Keith); sip at ietf.org
> 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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of
> > DRAGE, Keith (Keith)
> > Sent: Thursday, June 19, 2008 5:31 AM
> > To: sip at ietf.org
> > 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
> > sip-implementors at cs.columbia.edu for questions on current sip Use
> > sipping at ietf.org 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
> sip-implementors at cs.columbia.edu for questions on current sip Use
> sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip