[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] New version of draft-ietf-sip-199
Hi Christer,
This seems to have covered most things. The addition of descriptions of
the sorts of resources that can be released is quite helpful. I haFrom sip-bounces at ietf.org Wed Aug 27 07:44:26 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id CA00A3A67EF;
Wed, 27 Aug 2008 07:44:26 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E764C3A67A3
for <sip at core3.amsl.com>; Wed, 27 Aug 2008 07:44:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.19
X-Spam-Level:
X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.409,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id YIfVAol6CALV for <sip at core3.amsl.com>;
Wed, 27 Aug 2008 07:44:24 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149])
by core3.amsl.com (Postfix) with ESMTP id 0130D3A67EF
for <sip at ietf.org>; Wed, 27 Aug 2008 07:44:23 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.32,279,1217808000"; d="scan'208";a="18863078"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
by rtp-iport-2.cisco.com with ESMTP; 27 Aug 2008 14:43:54 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7REhsDg026421;
Wed, 27 Aug 2008 10:43:54 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
[64.102.31.102])
by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7REhsxx002952;
Wed, 27 Aug 2008 14:43:54 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Wed, 27 Aug 2008 10:43:42 -0400
Received: from [161.44.174.168] ([161.44.174.168]) by
xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Wed, 27 Aug 2008 10:43:41 -0400
Message-ID: <48B5685B.1030106 at cisco.com>
Date: Wed, 27 Aug 2008 10:44:43 -0400
From: Paul Kyzivat <pkyzivat at cisco.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg at ericsson.com>
References: <CA9998CD4A020D418654FCDEF4E707DF079F23C0 at esealmw113.eemea.ericsson.se>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF079F23C0 at esealmw113.eemea.ericsson.se>
X-OriginalArrivalTime: 27 Aug 2008 14:43:41.0669 (UTC)
FILETIME=[4C91A150:01C90853]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5182; t=1219848234;
x=1220712234; c=relaxed/simple; s=rtpdkim2001;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=pkyzivat at cisco.com;
z=From:=20Paul=20Kyzivat=20<pkyzivat at cisco.com>
|Subject:=20Re=3A=20[Sip]=20New=20version=20of=20draft-ietf
-sip-199 |Sender:=20
|To:=20Christer=20Holmberg=20<christer.holmberg at ericsson.co m>;
bh=VtM7nMNEOtHUdf/phwPeF6UsilsH4DEoY2CmdSaNCsg=;
b=gv5z45V35y6lvegEBm9gETK/TUptLwZIM4mDi3zxWDUmype0k8nMheXrpn
YR8ybuw58hkyJdgbMcxJ/faXMzgzEWCSuLGb5VYs4BAyUEhi8++uJCD7lL29
MZzYoX7IhK;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat at cisco.com; dkim=pass (
sig from cisco.com/rtpdkim2001 verified; );
Cc: SIP IETF <sip at ietf.org>
Subject: Re: [Sip] New version of draft-ietf-sip-199
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
Hi Christer,
This seems to have covered most things. The addition of descriptions of
the sorts of resources that can be released is quite helpful. I have a
feve a
few comments on the new version
> If multiple usages [RFC5057] are used within an early dialog, and it
> is not clear which dialogusage the 199 response terminates, SIP
> entities that keep dialog state SHALL NOT release resources
> associated with the early dialog when they receive the 199 response.
Under what circumstances can it not be clear which usage the 199 applies
to? AFAIK the 199 should only be used with an INVITE dialog usage, and
there can only be one of those per dialog. (We don't allow early dialogs
for other usages.)
> 5. limited access resources - in case of forking and multiple stream
> there may not be possible to allow early media on all dialogs, so
> some dialogs may e.g. be set to "inactive". When a dialog is
> terminated, media can be allowed on other dialogs.
s/there may not be possible/it may not be possible/
> When a forking proxy receives a non-2xx final response which
> terminates one or more early dialogs and the proxy does not intend to
> forward the final response immediately (due to the rules for a
> forking proxy), and the UAC has indicated support of the 199 response
> code, the forking proxy MUST send a 199 provisional response, for
> each associated early dialog that it can associate with the final
> response, upstream towards the sender of the associated request. The
> 199 provisional response MUST contain a To header tag parameter,
> which identifies the early dialog that has been terminated.
This still seems to require sending a 199 even if a 199 was previously
received and forwarded. IMO the proxy should never send a 199 if one was
previously received and forwarded for the same dialog. Keeping record of
that should be a requirement for any proxy that intends to send a 199.
> Since all SIP entities involved in a session setup do not necessarily
> support the specific meaning of the 199 Early Dialog Terminated
> provisional response, the sender of the response MUST be prepared to
> receive SIP requests and responses associated with the dialog for
> which the 199 response was sent (a proxy may receive SIP messages
> from either direction). If such request is received, and the
> receiver maintains state of the dialogs, the receiver MUST reply to
> such requests with a 481 final response. A UAC that receives a 199
> response for an early dialog MUST NOT send any further requests on
> that dialog, except for requests which acknowledge reliable
> responses.
I'm dubious of requiring, or even expecting or allowing, proxies to
generate 481 responses. For instance, the UAC is still permitted to send
PRACKs, and the proxies had better forward them. So I think it would be
best for a proxy to always forward requests even if it thinks the dialog
has ceased to exist.
> NOTE: According to [RFC3262] and [RFC3264], if the INVITE request did
> not contain an SPD offer, the first relaible response (provisonal or
> final) MUST contain an SDP offer. However, since 199 is only sent on
> established early dialog, it will never be the first response sent.
IMO a better rationale here is that the 199 response is not sent
reliably, and so isn't obligated to carry the offer. I think the above
logic is weaker and questionable - an early dialog can be established
without sending a reliable response. And I *think* a 199 can still be
used in that case.
I guess the UAS is permitted to send a reliable 199, but it would be
sufficient to say that it must not do so if that would obligate it to
include an offer. Better yet, lets just say that 199 should *never* be
sent reliably.
> This section registers a new SIP response code, 199. The required
> information for this registration, as specified in RFC 3261, is:
I have mixed feelings about using "199" as the option-tag. It is
syntactically valid, but using an all-numeric token bothers me. It could
be something like "use199". But if nobody else is bothered by a numeric
token I can live with it.
Thanks,
Paul
Christer Holmbergw comments on the new version
> If multiple usages [RFC5057] are used within an early dialog, and it
> is not clear which dialogusage the 199 response terminates, SIP
> entities that keep dialog state SHALL NOT release resources
> associated with the early dialog when they receive the 199 response.
Under what circumstances can it not be clear which usage the 199 applies
to? AFAIK the 199 should only be used with an INVITE dialog usage, and
there can only be one of those per dialog. (We don't allow early dialogs
for other usages.)
> 5. limited access resources - in case of forking and multiple stream
> there may not be possible to allow early media on all dialogs, so
> some dialogs may e.g. be set to "inactive". When a dialog is
> terminated, media can be allowed on other dialogs.
s/there may not be possible/it may not be possible/
> When a forking proxy receives a non-2xx final response which
> terminates one or more early dialogs and the proxy does not intend to
> forward the final response immediately (due to the rules for a
> forking proxy), and the UAC has indicated support of the 199 response
> code, the forking proxy MUST send a 199 provisional response, for
> each associated early dialog that it can associate with the final
> response, upstream towards the sender of the associated request. The
> 199 provisional response MUST contain a To header tag parameter,
> which identifies the early dialog that has been terminated.
This still seems to require sending a 199 even if a 199 was previously
received and forwarded. IMO the proxy should never send a 199 if one was
previously received and forwarded for the same dialog. Keeping record of
that should be a requirement for any proxy that intends to send a 199.
> Since all SIP entities involved in a session setup do not necessarily
> support the specific meaning of the 199 Early Dialog Terminated
> provisional response, the sender of the response MUST be prepared to
> receive SIP requests and responses associated with the dialog for
> which the 199 response was sent (a proxy may receive SIP messages
> from either direction). If such request is received, and the
> receiver maintains state of the dialogs, the receiver MUST reply to
> such requests with a 481 final response. A UAC that receives a 199
> response for an early dialog MUST NOT send any further requests on
> that dialog, except for requests which acknowledge reliable
> responses.
I'm dubious of requiring, or even expecting or allowing, proxies to
generate 481 responses. For instance, the UAC is still permitted to send
PRACKs, and the proxies had better forward them. So I think it would be
best for a proxy to always forward requests even if it thinks the dialog
has ceased to exist.
> NOTE: According to [RFC3262] and [RFC3264], if the INVITE request did
> not contain an SPD offer, the first relaible response (provisonal or
> final) MUST contain an SDP offer. However, since 199 is only sent on
> established early dialog, it will never be the first response sent.
IMO a better rationale here is that the 199 response is not sent
reliably, and so isn't obligated to carry the offer. I think the above
logic is weaker and questionable - an early dialog can be established
without sending a reliable response. And I *think* a 199 can still be
used in that case.
I guess the UAS is permitted to send a reliable 199, but it would be
sufficient to say that it must not do so if that would obligate it to
include an offer. Better yet, lets just say that 199 should *never* be
sent reliably.
> This section registers a new SIP response code, 199. The required
> information for this registration, as specified in RFC 3261, is:
I have mixed feelings about using "199" as the option-tag. It is
syntactically valid, but using an all-numeric token bothers me. It could
be something like "use199". But if nobody else is bothered by a numeric
token I can live with it.
Thanks,
Paul
Christer Holmberg wrote:
wrote:
> Hi,
>
> Based on a large number of good comments and suggestions off-line I have
> produced and submitted a new version (-01) of the draft-ietf-sip-199
> draft.
>
> Until available, it can also be found at:
>
> http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-01.txt
>
> Some work is still needed on the security section.
>
> I also realized that, in the reference section, I still refer to the
> dialog-usage draft document, eventhough it became an RFC.
>
> Regards,
>
> Christer
>
> _______________________________________________
> 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
> Hi,
>
> Based on a large number of good comments and suggestions off-line I have
> produced and submitted a new version (-01) of the draft-ietf-sip-199
> draft.
>
> Until available, it can also be found at:
>
> http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-01.txt
>
> Some work is still needed on the security section.
>
> I also realized that, in the reference section, I still refer to the
> dialog-usage draft document, eventhough it became an RFC.
>
> Regards,
>
> Christer
>
> _______________________________________________
> 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