Re: [Insipid] Reviews for INSIPID Session-ID solution draft

Brett Tate <brett@broadsoft.com> Mon, 04 August 2014 10:24 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 6DCFE1B29C8 for <insipid@ietfa.amsl.com>; Mon, 4 Aug 2014 03:24:46 -0700 (PDT)
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 8dzcyAidxXYB for <insipid@ietfa.amsl.com>; Mon, 4 Aug 2014 03:24:45 -0700 (PDT)
Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EB91B29CB for <insipid@ietf.org>; Mon, 4 Aug 2014 03:24:44 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id lf12so10594053vcb.15 for <insipid@ietf.org>; Mon, 04 Aug 2014 03:24:43 -0700 (PDT)
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 :content-transfer-encoding; bh=y8hLxo9lTnI4RIOU+3JWpgkKr0cSvescQ4BLc9fglYw=; b=JJFlRoA+29jemjVJEFy4+ifSr1l+x+LNEFIG5lOuabZtNIjxdRo0VTuR3Bz3PG+ZX4 B9N4q2pHxX3I7rgFX0KWXvyxf74X1sitatepEoHywSGLFbomgiS9ZB0UEBLNMSmQHGt1 7mw8RfHCmi+ciYoHAE7CW7WBM/zznrHhKNeTQEcq3c9ATwjsarbvuVDIL9UmztQFE+4U PaHl86zfzF4HL/Gyd7msQQIjVc7m/gpUoZHsfs10MrQT7/5XbwbjRWykrxrgLSAEoORP 7HYblbX0YpR3cvhaTudPuOVgSDE6ViOqPUJE3hp7xeZXTqCFlvVwmiULytyY+yC9gyG7 EDVg==
X-Gm-Message-State: ALoCoQnGRHDcR07ChssHZLSwfTWke89EJFs7dBFwGi9/CyHKexp6PcLC+gU62eu36oXySlh1f2Tt
X-Received: by 10.221.59.194 with SMTP id wp2mr933686vcb.59.1407147883582; Mon, 04 Aug 2014 03:24:43 -0700 (PDT)
From: Brett Tate <brett@broadsoft.com>
References: <4DB16225-A09D-4B9A-ADAB-9C2B23FE3D57@cisco.com> <49405AE0-0C44-4260-849B-22621387581A@cisco.com> <999A3253-0F6E-4172-BC5B-8B851BC60019@cisco.com> <0663B39E-2E3F-4B03-AC7C-BC5C83324DD7@cisco.com>
In-Reply-To: <0663B39E-2E3F-4B03-AC7C-BC5C83324DD7@cisco.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKsNg9pJ9Rd/Lnl4FcINMLUgMNHzwJ2LFSYAp5vE0YCYZGiKZnLd0tQ
Date: Mon, 04 Aug 2014 06:24:42 -0400
Message-ID: <8b639cc7c90f95a505b7ed66a9af5cce@mail.gmail.com>
To: Arun Arunachalam <carunach@cisco.com>, insipid@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/N28zVFfDG6K2y9r__B_liA5kvhE
Subject: Re: [Insipid] Reviews for INSIPID Session-ID solution draft
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: Mon, 04 Aug 2014 10:24:46 -0000

> Section 4.1 (page 4)
>  Intermediaries that insert a Session-ID header into a SIP message on
>   behalf of a sending User Agent MUST utilize version 5 UUIDs to ensure
>   that UUIDs for the communication session are consistently generated.
>   If an intermediary does not know the tag value for an endpoint, the
>   intermediary MUST NOT attempt to generate a UUID for that endpoint.
>
>  Typically, an INVITE from an endpoint will have a From tag. Can you
give
> an example where the intermediary doesn't know the tag value?

If you are seeking an answer instead of requesting that the example be
included within draft...

The text indicates how to behave when interacting with devices
non-compliant to RFC 3261.  For instance, tag usage was not always
mandatory within RFC 2543.