[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Progress draft-holmberg-sip-keep
Hi,
>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).
Outbound can not always be used, as the draft says.
It is true that initially the primary scope is between the UA and the edge proxy. However, I am happy to add the proxy-to-proxy use-case, if people think that is something we should do.
>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.)?
At the moment I see no reason why the same technical solution wouldn't apply.
Regards,
Christer
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:christer.holmberg at ericsson.com]
> Sent: 24 June 2008 08:20
> To: Elwell, John; Hadriel Kaplan; DRAGE, Keith (Keith); sip at ietf.org
> 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: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