Re: [Insipid] Proposal for Backwards Compatibility Session-ID

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Thu, 19 September 2013 14:39 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1F121F9926 for <insipid@ietfa.amsl.com>; Thu, 19 Sep 2013 07:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkKwFcpyOQQu for <insipid@ietfa.amsl.com>; Thu, 19 Sep 2013 07:38:53 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id B1E9421F9798 for <insipid@ietf.org>; Thu, 19 Sep 2013 07:38:53 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r8JEckqX008352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Sep 2013 09:38:47 -0500 (CDT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r8JEcIW2015411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Sep 2013 16:38:40 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 19 Sep 2013 16:37:37 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, James Polk <jmpolk@cisco.com>, "Paul E. Jones" <paulej@packetizer.com>, "insipid@ietf.org" <insipid@ietf.org>
Thread-Topic: [Insipid] Proposal for Backwards Compatibility Session-ID
Thread-Index: AQHOtJ9TQ07PUIfMsU63KESiEFFNz5nMgfqAgACd1VA=
Date: Thu, 19 Sep 2013 14:37:37 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0A6F84@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <201309162210.r8GMAKPM024097@rcdn-core2-1.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C4A47C0@ESESSMB209.ericsson.se> <002f01ceb3c6$22845f00$678d1d00$@packetizer.com> <7594FB04B1934943A5C02806D1A2204B1C4A6AA1@ESESSMB209.ericsson.se> <201309181846.r8IIkJZN029754@rcdn-core2-5.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C4A7650@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4A7650@ESESSMB209.ericsson.se>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B0A6F84FR712WXCHMBA11zeu_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Subject: Re: [Insipid] Proposal for Backwards Compatibility Session-ID
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 19 Sep 2013 14:39:00 -0000

The key parts of the kaplan draft is the following:


   The UAC MUST include the Session-ID header field in every SIP

   message it transmits.


...



   A UAS compliant with this document MUST copy a received Session-ID

   header field in a request, into responses and subsequent upstream

   requests sent within the dialog.


   If an out-of-dialog request is received without a Session-ID header

   field, the UAS SHOULD generate a new one for subsequent use in the

   transaction and dialog, as defined for a UAC, and use the same value

   in all responses and upstream in-dialog requests for the same

   dialog.


So my reading is that it occurs in a response even if it was not in a request.

As far as 3GPP is concerned it is only called up for conference participants, conference focus and IBCF where it is mandatory for all. The references are to implement as specified in Kaplan.

Regards

Keith

________________________________
From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 19 September 2013 08:04
To: James Polk; Paul E. Jones; insipid@ietf.org
Subject: Re: [Insipid] Proposal for Backwards Compatibility Session-ID

Hi James,

I will skip the questions regarding the format of the null value for the moment, because I think it is more important to first agree on IF/HOW it is going to be used.

...
...
...

>>> I haven't double check whether draft-kaplan says anything regarding
>>> this, but as it doesn't define any parameters to begin with I doubt it.
>>>
>>> Even if they do, an INSIPID device can still detect Bob is a
>>> Kaplan device since the reply should not contain a NULL remote
>>> parameter.  (And the first parameter should be different in a reply.
>>
>> Correct, that is what I said :)
>>
>> So, instead of trying to figure out what every implementation out
>> there does, I think Alice needs to be prepared for both cases.
>
> whatever we reach consensus on will be written into the insipid
> draft, even if it's multiple choices - but I'd prefer that we keep it
> to a list of as few choices as possible, explicitly *not* taking
> "...every implementation out there..." into account, after all, there
> is only 1 draft that's been implemented, therefore there should only
> be one way to do that (kaplan) implementation

There are only two choices: either the [Kaplan] device copies the header field parameter(s), or it doesn't :)

------------------

>The only question is if we have an insipid implementation include a
>remote value or not. If one is present, that in and of itself
>indicates to every entity in the signaling path that that UA is an
>insipid endpoint, and explicitly *not* a kaplan endpoint.
>
>That's what the WG is after (wrt backwards compatibility).

And hearing you saying that is music to my ears :)

But, I still think that using a "dummy parameter value" as a capability indicator is bad design. A feature/option tag would be as explicit as a dummy value.

Also keep in mind that, even if a [Kaplan] device would copy both values, the [Insipid] device cannot "switch" the order, as it would both entities were [Insipid].

So, as shown in the example, the remote parameter would always represent the [Insipid] device, no matter in which direction a message is sent.

Example:

[Kaplan]                                     [Insipid]

--------- S-ID: xyz;r=null ----------->
<---------S-ID: xyz;r=null ------------

[Kaplan]                                     [Insipid]

<--------- S-ID: xyz;r=null -----------
-----------S-ID: xyz;r=null ---------->

So, in my opinion it is better two use two values when both endpoints actually support them, and use something else as [Insipid] capability indicator.

Regards,

Christer