Re: [Insipid] draft-ietf-insipid-session-id-10: comments

"Paul E. Jones" <paulej@packetizer.com> Sat, 24 January 2015 00:42 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532C41A8A43 for <insipid@ietfa.amsl.com>; Fri, 23 Jan 2015 16:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level:
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X13bY3SpZwm7 for <insipid@ietfa.amsl.com>; Fri, 23 Jan 2015 16:42:46 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124571A8A39 for <insipid@ietf.org>; Fri, 23 Jan 2015 16:42:45 -0800 (PST)
Received: from [192.168.1.20] (cpe-098-027-048-015.nc.res.rr.com [98.27.48.15]) (authenticated bits=0) by dublin.packetizer.com (8.14.9/8.14.9) with ESMTP id t0O0ghvb026864 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 19:42:43 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1422060164; bh=nsxQiRZcq0yOKcYh9sY5e/o/eBuxv1D85D18S7jBPU8=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=nz32f1cSvsl/8hd5PuM1mUjwMXdKeisYc6krQ/w+OHnVMFPLiiqd2lEud4VPfvNVc 8FZyEiBe9eVTBl5Nm7Gk3AIQpMVI7iDAIFzvJwO6hzA3gNe3RlcwuWEezU4LLbJZ3l eOew6gwibDxxZWGnAqoWknWJCSPp+TRnYM7/ylgM=
From: "Paul E. Jones" <paulej@packetizer.com>
To: Brett Tate <brett@broadsoft.com>, draft-ietf-insipid-session-id@tools.ietf.org, insipid@ietf.org
Date: Sat, 24 Jan 2015 00:42:54 +0000
Message-Id: <em17a6c706-b38c-48d2-8146-2a8b41ff8628@sydney>
In-Reply-To: <86b4120892860c2b418046d71347c35b@mail.gmail.com>
User-Agent: eM_Client/6.0.21372.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/insipid/aogotNzZ8dG65t-xUAYIj9guAGE>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-10: comments
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Jan 2015 00:42:48 -0000

Brett,


>>  I think the answer, regardless, is going to be that
>>  the 487 should have the same Session-ID value as the
>>  CANCEL or INVITE for the "remote" part.
>
>Is there a snippet within the draft (or an RFC) which supports that
>behavior? SIP has occasionally been vague about what can update stored
>information associated the dialog/remote-party (and what all gets 
>rolled
>back during re-INVITE failure); I'm attempting to help avoid this draft 
>from
>having the same issue.

Section 6 (first sentence) says that all non-intermediary SIP UAs must 
include the Session-ID header.  It then explains what the format of that 
message is.  There are no exception, except for CANCEL that we added and 
provisional responses.



>If your answer is correct, that means that the working group thinks 
>that it
>is better to use the received out-of-dialog CANCEL or INVITE local-uuid
>(instead of reflecting the mid-dialog modification) when populating the
>487's remote-uuid. The behavior seems atypical; I usually don't 
>consider an
>out-of-dialog CANCEL as being able to update mid dialog information (or
>mid-dialog updates forgotten before sending failure response).

These values should be the same, since they're part of the same 
"session".  Now, it's the definition of "session" that is purposely 
vague, but the OOD message should have the same UUID as the INVITE and 
other in-dialog messages.  Ditto for replies to those OOD messages.


>If your answer is correct, that means that the working group thinks 
>that it
>is better to use the received mid-dialog CANCEL or re-INVITE local-uuid
>(instead of reflecting a subsequent modification) when populating the 
>487's
>remote-uuid. The behavior seems atypical; I usually don't consider a
>mid-dialog CANCEL as being able to update mid-dialog information (or
>mid-dialog updates forgotten before sending failure response).

Is this just a repeat of the previous?


>
>What about my ACK questions? Should the ACK sent by B2BUA for the 487
>(after CANCEL) contain {A, B} or {A2, B} during the two situations? Is
>there a snippet within the draft (or an RFC) which supports that 
>behavior?

All messages related to the session should carry the same UUID values.  
If the intermediary is manipulating the exchanges (e.g., switching 
endpoints B with C, for example), it should know what UUID to send.


>To help avoid further confusion, I fixed my following questions 
>concerning
>487 since I had accidently reflected To/From switching behavior instead 
>of
>draft's local/remote switching behavior.
>
>
>>  >The CANCEL is sent outside of dialog and would
>>  >contain {A, N}. If the 487 from B contains the
>>  >same To tag associated with UPDATE's modification,
>>  >should the 487 indicate {B, A} or {B, A2}? Should
>>  >the ACK sent by B2BUA contain {A, B} or {A2, B}?
>>  >
>>  >Same questions except UPDATE occurs during a re-INVITE.
>>  >
>>  >The CANCEL is sent within dialog and would
>>  >contain {A, B}. Should the 487 indicate {B, A}
>>  >or {B, A2}? Should the ACK sent by B2BUA contain
>>  >{A, B} or {A2, B}?

The 487 should contain {B,A} (same UUID for same session).  I'm not sure 
what's leading you to suggest this A2 value.

Paul