Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions

Paul Kyzivat <> Tue, 05 January 2016 19:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 356E81B2D57 for <>; Tue, 5 Jan 2016 11:51:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cydM0_tvfz3M for <>; Tue, 5 Jan 2016 11:51:13 -0800 (PST)
Received: from ( [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07A5E1B2D47 for <>; Tue, 5 Jan 2016 11:51:12 -0800 (PST)
Received: from ([]) by with comcast id 2Kqz1s0014xDoy801KrCKL; Tue, 05 Jan 2016 19:51:12 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id 2KrB1s00K3KdFy101KrBgE; Tue, 05 Jan 2016 19:51:12 +0000
References: <>
From: Paul Kyzivat <>
Message-ID: <>
Date: Tue, 05 Jan 2016 14:51:10 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1452023472; bh=0oaYNh+2I49rd/26s95M3wCdfE/vu/DSN+4dW43yDfI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=D4ZfDl2Kp4GgX217nSc4H53wkYjtNQSu1l9vF7zLVblxV+8m20svP7c8vGDcf1AMI 1bAR8Adu6+wLaTWi8nOdH5AtoZAzvmcK6/sbuopGlTsd7EJvK8plAwQ3gfoIcXAS5g Q5WzAQXIqGyd/7THeXHGqyqAKsJHWRz44QPGFKq0DG4Y9Lf+qP9cMMPYkajVmPk/IR BXYww7WOV3AUeS31cGH9BhKUyxDJljTI0pyNDcIO25QCJvaKVee/mH9Tu4kwhv4nA3 Vcku3bkV8zGxIBkWgZ5+D8I6P9eIcps+t4yOkpoXyPsOjXu1t5LQZWavzU3rXVIA6C tXu6SN2PrM4og==
Archived-At: <>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Jan 2016 19:51:15 -0000

This discussion is reinforcing my belief that this mechanism is a mess - 
that the chance is slim to none of getting consistent results in all the 
connected devices.


On 1/5/16 12:51 PM, Brett Tate wrote:
> Hi Paul,
> Thanks for the response and welcome to the discussion.  Reply is inline.
>> I propose a simpler solution that should address your
>> concerns and make it easy for implementers to understand
>> what should be done in these scenarios. This would
>> require a slight modification to the draft as it stands
>> today. I am therefore seeking your and the working group’s
>> approval to move forward with this change. If we can all
>> agree on this in concept, I will put together some
>> concrete text for inclusion in the draft.
> To get more feedback, you might need to raise the topic in a new thread.
>> In a nutshell, I propose that we make a minor change to
>> the text to explicitly call out the conditions under
>> which a UUID should be stored by endpoints and
>> intermediaries. I propose that an endpoint or intermediary
>> only store an updated remote UUID under the following
>> conditions:
>> When receiving a request (other than ACK) that is accepted
>> (results in a 1XX or 2XX response), the received UUID must
>> be retained. If the request results in any other kind of
>> response, it should not be retained. This can, of course,
>> lead to conditions where a request is received, a
>> provisional response is sent (and therefore the UUID is
>> retained) and then for whatever reason, an error
>> (4XX/5XX/6XX) or redirect (3XX) response is sent. In such
>> a case, we will never “roll back” the Session ID.
> Concerning the mentioned "1xx", you might want to exclude 100 since 100
> isn't end-to-end (even if using proxies instead of B2BUAs).  For instance if
> 100 is only sent between two of the intermediaries, a resulting 500 response
> doesn't mean that everyone agrees that the uuid actually changed.  However,
> I guess that the same could be said for all non-reliable 1xx since a 18x
> sent by endpoint could be dropped (or received after 500).
> You might want to distinguish between a ACK-for-2xx versus ACK-for-non-2xx.
> Some within the SIP working groups prefer to allow ACK-for-2xx to update
> things.  For instance, see draft-ietf-insipid-session-id-16 section 9.7; the
> 3pcc sends the updated uuid within the ACK.
> The proposal currently appears to violate (or alter) RFC 3261 section 8.2:
> "If it is rejected, all state changes MUST NOT be performed".  Similarly it
> also appears to impact the following RFC 6141 section 3.3 SHOULD: "If any of
> the changes requested in a re-INVITE or in any transaction within it have
> already been executed, the UAS SHOULD return a 2xx response".
> You might want to exclude CANCEL and its 2xx response from the algorithm
> (although decision might be influenced by decision concerning 100 response).
> CANCEL and related 2xx response are not end-to-end (even if using proxies
> instead of B2BUAs).
>> The only additional rule for stateful intermediaries is
>> that if they accept a request and then forward that request
>> to another destination (therefore there was no error found
>> with the message), this will also trigger the intermediary
>> to update the retained UUID.
> The proposal means that not all of the devices will necessarily agree if a
> uuid changed during failure situation.
> Concerning "therefore there was no error found" statement, be aware that
> forwarding a request does not necessarily mean that no error was found (i.e.
> device can be lenient) or that the request won't eventually be rejected
> (with 400 or other failure response).
>> The remote UUID in all responses must match the UUID
>> received in the request if the SIP stack is able to process
>> the Session-ID header. This applies even if the UUID is not
>> going to be retained. If a re-INVITE {C,B} contains an
>> error but the Session-ID is successfully extracted from the
>> re-INVITE, the 4XX response should contain {B,C} (assuming
>> the receiving endpoint is still using B as the local UUID.
>> Otherwise B should be replaced with the correct Local UUID).
>> To deal with issues where a response with a Session ID
>> different than what is being retained is sent in an error
>> response and the ACK for that response contains the new
>> Session ID which we chose not to retain because it was as
>> a result of an error, the document will state that a
>> Session ID received in an ACK must never update the
>> retained value. This should never be an issue because the
>> Session ID in the ACK should always match that of the
>> matching request, so if the endpoint receiving the request
>> updated the Session ID on the request, it does not need to
>> do so again for the ACK.
> Concerning "Session ID in the ACK should always match that of the matching
> request", it isn't always true.  For instance, see
> draft-ietf-insipid-session-id-16 section 9.7; the 3pcc sends the updated
> uuid within the ACK.
> You might want to distinguish between a ACK-for-2xx versus ACK-for-non-2xx.
> Some within the SIP working groups prefer to allow ACK-for-2xx to update
> things.
>> Endpoints and intermediaries always update their Remote
>> Session ID based on any responses received regardless of
>> the type of response (provided the response is
>> syntactically valid and can be processed, of course).
> Sending a non-reliable response (1xx-6xx) is not necessarily the best way to
> update something because of race conditions and similar ambiguities.
> However, the proposal is basically the same as the draft.
>> There will always be feature interactions that result in
>> temporarily mismatched Session IDs when intermediaries are
>> involved, but I don’t think the above proposal makes this
>> any worse of a problem in real-world applications.
> I'm currently not sure if the proposal is better or worse than draft version
> 16.
>>From the rejecting device perspective, the proposal appears to be better.
> The proposal currently appears to leave partial changes up to rejecting
> device (i.e. intermediaries allowed change but rejecting device did not)
> without any indication to modifier to know if change was successful at the
> remote endpoint.  This is about the same as changing some of the MUST to
> SHOULD (or MAY) within the current draft which would allow the rejecting
> device to make the decision concerning which is better for the situation.
>> Please see my responses inline to address your concerns….
> I'll respond separately if I have any comments different from those within
> this reply.
> Thanks,
> Brett
> _______________________________________________
> insipid mailing list