IETF Logo Mail Archive

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

Brett Tate <brett@broadsoft.com> Fri, 23 January 2015 14:44 UTC

Return-Path: <brett@broadsoft.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 451301A90BA for <insipid@ietfa.amsl.com>; Fri, 23 Jan 2015 06:44:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 9kKxngiX-4Vg for <insipid@ietfa.amsl.com>; Fri, 23 Jan 2015 06:44:03 -0800 (PST)
Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (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 CB97C1A017D for <insipid@ietf.org>; Fri, 23 Jan 2015 06:44:02 -0800 (PST)
Received: by mail-qa0-f54.google.com with SMTP id w8so6036434qac.13 for <insipid@ietf.org>; Fri, 23 Jan 2015 06:44:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=0hyvgFJN0JJE1TKwdm63oxMcvXNLsMNoNBP2mEmUkJU=; b=WoJKQ1KTLaG0YAq8iizNUDG2rL6vi9+ycOFONnzu0EPldaj0DtmskcwQduJfQ6UT9t R6znsUAppkjYmpttbKwScXQGGIkvZwTv/DqNJNLRgIA2riqErzROUxLyZ666Fhwqbky+ lNNWSkxAemlqnThgZaf23d/X0iHJXR1GOBbL6hv0sHxEhiy73FF4bnvz0zA7T534G63x daK4mYOS3wpUwxNWWIHAOqJVRCx7FOcl3EuzFPSOYBAc7Bg7K07bEU8t4FUx3IytWgcL CYKap0l0ALQpoOuY5EyJlgNj4y4zOUxDl0ogdmHrRBQvOO43rbm1xxS5nV6LzNbW7H/U FoEQ==
X-Gm-Message-State: ALoCoQlsYRdnHmY2eA3OWJyGsvIEjNU17m/1UM3MzbFn4pySoZlvFge4uEkKLY4ZVP8NZllgrAdqrj1QIkxXuZ/op9tYSwpE+s1vcue5UQSau76CkNzxi6M=
X-Received: by 10.140.91.201 with SMTP id z67mr13935240qgd.27.1422024241975; Fri, 23 Jan 2015 06:44:01 -0800 (PST)
From: Brett Tate <brett@broadsoft.com>
References: <72e3bd0ddec802bd4fa5fd495c2bab2f@mail.gmail.com> <em6dd67f9b-2dd8-4f68-b9d1-29082e7e4f62@sydney>
In-Reply-To: <em6dd67f9b-2dd8-4f68-b9d1-29082e7e4f62@sydney>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQItQ3k/tTAg9fJOIDLQ+vXSLGvqhJwTib6A
Date: Fri, 23 Jan 2015 09:44:01 -0500
Message-ID: <86b4120892860c2b418046d71347c35b@mail.gmail.com>
To: draft-ietf-insipid-session-id@tools.ietf.org, insipid@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/insipid/1MAFfwDa_wqwiyL-_rY45LypMCY>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-10: comments
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Fri, 23 Jan 2015 14:44:05 -0000

Hi,

Thanks for the response; reply is inline.

> >During call setup, consider an UPDATE from caller
> >that changed Session-ID from {A, B} to {A2, B}.
>
> Why would the UPDATE have a different "local" UUID
> value than what was sent before?

A B2BUA interaction occurred which replaced a user or user's device on one
side while call setup was occurring on the other side.


> 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.

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).

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).

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?

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}?

-- 

Meet with us at Mobile World Congress 2015 
<http://www.broadsoft.com/news/mobile-world-congress/>

This email is intended solely for the person or entity to which it is 
addressed and may contain confidential and/or privileged information. If 
you are not the intended recipient and have received this email in error, 
please notify BroadSoft, Inc. immediately by replying to this message, and 
destroy all copies of this message, along with any attachment, prior to 
reading, distributing or copying it.

v2.23.0 | Report a Bug | By Email