[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] New version of draft-ietf-sip-199
Comments inline. I think we are in substaFrom sip-bounces at ietf.org Wed Aug 27 17:44:53 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 D74703A68F1;
Wed, 27 Aug 2008 17:44:53 -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 494993A6932
for <sip at core3.amsl.com>; Wed, 27 Aug 2008 17:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.394
X-Spam-Level:
X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=0.205,
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 e9KE3ZpZGiE4 for <sip at core3.amsl.com>;
Wed, 27 Aug 2008 17:44:50 -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 26DEF3A68BA
for <sip at ietf.org>; Wed, 27 Aug 2008 17:44:50 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.32,283,1217808000"; d="scan'208";a="18930730"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
by rtp-iport-2.cisco.com with ESMTP; 28 Aug 2008 00:44:50 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7S0iocG005480;
Wed, 27 Aug 2008 20:44:50 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
[64.102.31.12])
by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m7S0io3s020694;
Thu, 28 Aug 2008 00:44:50 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Wed, 27 Aug 2008 20:44:50 -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 20:44:49 -0400
Message-ID: <48B5F53D.9090909 at cisco.com>
Date: Wed, 27 Aug 2008 20:45:49 -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>
<48B5685B.1030106 at cisco.com>
<CA9998CD4A020D418654FCDEF4E707DF046C792D at esealmw113.eemea.ericsson.se>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF046C792D at esealmw113.eemea.ericsson.se>
X-OriginalArrivalTime: 28 Aug 2008 00:44:49.0691 (UTC)
FILETIME=[46C906B0:01C908A7]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7796; t=1219884290;
x=1220748290; 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=20VS=3A=20[Sip]=20New=20version=20of=20dr
aft-ietf-sip-199 |Sender:=20
|To:=20Christer=20Holmberg=20<christer.holmberg at ericsson.co m>;
bh=ECpQzZFiwGTXvKotJGxQpNl8oZMZJ1PnCy9lmNIkBhg=;
b=wr7p3b5YM1xpOE5lijbx6s6yZUvBJSl4rT8vQnPGkyLs4lXMiBA0+O2VPK
SOv0gk+MsrcjIgwSTKRtxRP6HQFzrC57e98HscoLbXAlQijZUcwP+unyD4Rh
f+OWKf3Bc6;
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
Comments inline. I think we are in substantial agreement.
Thanks,
Paul
Christer Holmberg wrote:
> Hi Paul,
>
>> 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
>> 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.)
>
> I think it's clear that the 199 applies to the invite dialog usage. But, what if there are other usages? You would need to know whether the error response which triggered the 199 also affects those usages.
>
> Again, this would only happen if you have established the other usage during the early phase of the invite dialog (which I think is only theoretical).
OK. I think I see what you are getting at, but it is somewhat obscure.
Lets suppose for a minute we have an early invite dialog usage, and have
another dialog usage sharing the dialog with it. (E.g. maybe we sent a
REFER and got a refer subscription going.) [At this point Robert runs
out of the room, screaming.]
Of course the invite was also forked, and we have another early dialog
going as well.
Now something happens that leads the forking proxy to want to send a 199
response. Because this is a 1xx class response, it must be something
that has happened pertaining to the INVITE, since we now only allow
provisionals for INVITE. I guess the question is whether the response
that provokes the 199 might *also* imply the termination of the dialog
as a whole rather than just the invite dialog usage. That can only be
determined if the actual final response is known, and we have excluded
that have we not?
>> 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/
>
> I'll fix that.
>
>
>
>> 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.
>
> Yes, I was thinking about the same thing. Having two 199s sent (one by the forking proxy, and one by the UAS) is not a good thing.
>
>
>
>> 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.
>
> Yes. I was thinking of an UAS only, so I will clarify that this does not apply to proxies.
>
>
>
>> 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.
>
> I have no problem saying that. But, again, I don't think there are cases where you would be obligated to include an offer/answer in 199, because you have already sent at least one 18x.
>
> Of course, one use-case is when the UAS first sends a 18x unreliably, and then send a 199 reliably. In this case, if the INVITE didn't contain an offer, the 199 would have to contain one, since it's the first RELIABLE provisional response sent.
Good - you found your own counterexample!
> But, I have no problem saying that 199 must not be sent reliably (not even by a UAS), if people are ok with that.
>
>
>
>> 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.
>
> We can use another value, if someone comes up with something more sexy than "199" :)
>
> Regards,
>
> Christer
>
>
>
>
>
> Christer Holmberg 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
ntial agreement.
Thanks,
Paul
Christer Holmberg wrote:
> Hi Paul,
>
>> 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
>> 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.)
>
> I think it's clear that the 199 applies to the invite dialog usage. But, what if there are other usages? You would need to know whether the error response which triggered the 199 also affects those usages.
>
> Again, this would only happen if you have established the other usage during the early phase of the invite dialog (which I think is only theoretical).
OK. I think I see what you are getting at, but it is somewhat obscure.
Lets suppose for a minute we have an early invite dialog usage, and have
another dialog usage sharing the dialog with it. (E.g. maybe we sent a
REFER and got a refer subscription going.) [At this point Robert runs
out of the room, screaming.]
Of course the invite was also forked, and we have another early dialog
going as well.
Now something happens that leads the forking proxy to want to send a 199
response. Because this is a 1xx class response, it must be something
that has happened pertaining to the INVITE, since we now only allow
provisionals for INVITE. I guess the question is whether the response
that provokes the 199 might *also* imply the termination of the dialog
as a whole rather than just the invite dialog usage. That can only be
determined if the actual final response is known, and we have excluded
that have we not?
>> 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/
>
> I'll fix that.
>
>
>
>> 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.
>
> Yes, I was thinking about the same thing. Having two 199s sent (one by the forking proxy, and one by the UAS) is not a good thing.
>
>
>
>> 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.
>
> Yes. I was thinking of an UAS only, so I will clarify that this does not apply to proxies.
>
>
>
>> 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.
>
> I have no problem saying that. But, again, I don't think there are cases where you would be obligated to include an offer/answer in 199, because you have already sent at least one 18x.
>
> Of course, one use-case is when the UAS first sends a 18x unreliably, and then send a 199 reliably. In this case, if the INVITE didn't contain an offer, the 199 would have to contain one, since it's the first RELIABLE provisional response sent.
Good - you found your own counterexample!
> But, I have no problem saying that 199 must not be sent reliably (not even by a UAS), if people are ok with that.
>
>
>
>> 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.
>
> We can use another value, if someone comes up with something more sexy than "199" :)
>
> Regards,
>
> Christer
>
>
>
>
>
> Christer Holmberg 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