Subject: [Insipid] I-D Action: draft-ietf-insipid-session-id-02.txt

From: [email-masked]
Date: Mon, 15 Jul 2013 12:16:35 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the INtermediary-safe SIP session ID Working Group of the IETF.

	Title           : End-to-End Session Identification in IP-Based Multimedia Communication Networks
	Author(s)       : Paul E. Jones
                          Chris Pearce
                          James Polk
                          Gonzalo Salgueiro
	Filename        : draft-ietf-insipid-session-id-02.txt
	Pages           : 25
	Date            : 2013-07-15

Abstract:
   This document describes an end-to-end Session Identifier for use in
   IP-based Multimedia Communication systems that enables endpoints,
   intermediate devices, and management systems to identify a session
   end-to-end, associate multiple endpoints with a given multipoint
   conference, track communication sessions when they are redirected,
   and associate one or more media flows with a given communication
   session.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-insipid-session-id-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-insipid-session-id-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Jul 2013 17:01:05 -0400

This is getting better. I have a few things:

Section 6:

    The exception to including the UUID of the transmitting entity
    mentioned above is in the case of provisional responses that occur
    before the destination UA has generated its UUID.  The 100 (Trying)
    response and the 181 (Call Forwarding) response are examples of such
    provisional responses. In these cases, the sending intermediary
    places the one known UUID in the remote-uuid field, and leaves the
    "local-uuid" blank. This placement is always where a UA expects to
    receive its UUID value in SIP responses.

The syntax doesn't currently permit the local-uuid to be "blank".

Then Section 7 talks about the same thing and says to use a null uuid, 
which is really one with all zeros.

I guess you intend to use "null" everywhere, but haven't got the 
language fixed everywhere. Frankly, I would like it better if you 
changed the syntax for Session-ID to make the local-uuid optional:

      session-id    = "Session-ID" HCOLON [local-uuid]
                     *(SEMI sess-id-param)

Section 9.6:

I don't think figures 6 & 7 are consistent with the words in this 
section. It says:

      o The MCU that is contacted, i.e., the UAS MCU, does not populate
        or complete the Session-ID header value. The UAS MCU transmits a
        200 OK response acknowledging it is to respond with this M' UUID
        to all requests for the designated conference.

yet figure 6 shows {J,M'} and figure 7 shows {J,M'}, {K,M'}, {L,M'}. 
AFAICT, J/K/L could only be known if sent from the UAS MCU.

Also, the *point* of this is that participants in the conference will 
always get M', regardless of which MCU they contact. I think this should 
be shown by expanding the flows to include the connecting of a UA to one 
of the subordinate MCUs.

Section 9.9:

Figure 10 annotates the REFER with "(Target-Dialog:Carol)". If you look 
at the original in 5589, the Target-Dialog has the dialog id of the 
dialog between Bob and Alice - it has nothing to do with Carol. (There 
is as yet no dialog with Carol.)

But you say this is about an out-of-dialog REFER. So why do you put {X} 
in it? It makes more sense to me that you would still use {B}, since 
this is intended to replace the {B,A} dialog.

Either way, when Alice gets this she sees the Target-Dialog and knows 
this is to replace the {B,A} dialog. That is what causes her to use {A} 
in the the resulting INVITE.

	Thanks,
	Paul

On 7/15/13 3:16 PM, [email-masked] wrote:
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid
>

---

From: James Polk <[email-masked]>
Date: Mon, 15 Jul 2013 17:23:43 -0500

>The syntax doesn't currently permit the local-uuid to be "blank".

You're right, we got ahead of ourselves in that we didn't touch the 
ABNF, but should have *with* making these changes to other 
sections.  A thousand apologies...

>Then Section 7 talks about the same thing and says to use a null 
>uuid, which is really one with all zeros.
>

That's certainly worth considering (instead of the null value we 
allude to in this new versions).

>Also, the *point* of this is that participants in the conference 
>will always get M', regardless of which MCU they contact.

But we have to have a means of distributing M' to all the MCUs, and 
that's what we're after. Obviously we missed some text to bring the 
draft all to the point of consistency.

>I think this should be shown by expanding the flows to include the 
>connecting of a UA to one of the subordinate MCUs.

ok, that sounds reasonable to me.

>Section 9.9:
>
>Figure 10 annotates the REFER with "(Target-Dialog:Carol)". If you 
>look at the original in 5589, the Target-Dialog has the dialog id of 
>the dialog between Bob and Alice - it has nothing to do with Carol. 
>(There is as yet no dialog with Carol.)
>
>But you say this is about an out-of-dialog REFER. So why do you put 
>{X} in it? It makes more sense to me that you would still use {B}, 
>since this is intended to replace the {B,A} dialog.

In 5589, the figure we took from that RFC shows the REFER as a 
separate dialog than the Alice-to-Bob dialog. How is the Session-ID 
not going to change with the dialog change?

Thanks for the quick review

JAmes

>Either way, when Alice gets this she sees the Target-Dialog and 
>knows this is to replace the {B,A} dialog. That is what causes her 
>to use {A} in the the resulting INVITE.
>
>         Thanks,
>         Paul
>
>>         Title           : End-to-End Session Identification in 
>> IP-Based Multimedia Communication Networks

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 15 Jul 2013 18:24:37 -0400

Paul,

You're quick... you commented before I had a chance to summarize the

> The syntax doesn't currently permit the local-uuid to be "blank".

Indeed, that's a leftover from where we initially tried to address Robert's
100 Trying call flow example.  The offending sentence should have been:

    In these cases, the sending intermediary places the one known
    UUID in the "remote-uuid" field, and sets the "local-uuid"
    field to the "null" UUID value.

> which is really one with all zeros.

Correct.  That's intended.
 
>       session-id    = "Session-ID" HCOLON [local-uuid]

This is certainly open for discussion, as we just inserted this to address
those new call flows.  If folks prefer to allow a Session-ID header of the
form:
  Session-ID: ; remote=6e7d43af3ea14ec6a43d39171ff17b09
 
> AFAICT, J/K/L could only be known if sent from the UAS MCU.

Right.  That paragraph should be deleted.  We had it this was in the last
draft, but I felt it was inconsistent with all other call flows.  We
neglected to remove that paragraph.
 
> be shown by expanding the flows to include the connecting of a UA to one

That's correct and I agree.  I don't want to rush those changes out the
door, but I'll take note that we should show a UA calling into MCU 3 or 4,
for example.
 
> is as yet no dialog with Carol.)

You're correct.  James and I will need to revise this.  Not sure why it
reads like this.

> this is intended to replace the {B,A} dialog.

Not sure about this one.  REFER here uses a whole new Call-ID, which is the
reason why the Session-ID is different.  It's not related to the current
Session and, therefore, should not utilize the same UUID value.
 
> in the the resulting INVITE.

Right.  Regardless of what prompts the call transfer, Alice should re-use
her UUID since the call is transferred.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 15 Jul 2013 18:40:51 -0400

Folks,

In this draft, the following changes were made:

* Revised the example UUID values to use "version 4" (random) UUIDs
  to be consistent with the requirements spec
* Introduced the "null" UUID value (numerically zero) to support
  some message exchanges like sending a 100 Trying from
  an intermediary
* Clarified that the "sender" of a message is the "transmitter"
  of a message (terminology change)
* Introduce language related to 100 Trying and CANCEL in
  Sections 5 and 6
* Modified the language of the example to make it clearer
  those are non-normative examples
* Made minor changes to most examples to make them clearer
* Introduced new examples for 100 Trying, Cancel, and OOD REFER

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Monday, July 15, 2013 3:17 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Insipid] I-D Action: draft-ietf-insipid-session-id-02.txt
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Jul 2013 21:17:03 -0400

On 7/15/13 6:23 PM, James Polk wrote:

> In 5589, the figure we took from that RFC shows the REFER as a separate
> dialog than the Alice-to-Bob dialog. How is the Session-ID not going to
> change with the dialog change?

Its up to you to make the rules. A focus uses the same uuid for all the 
dialogs in the conference. So why shouldn't the transferor use the same 
uuid for the before/after dialogs?

Ultimately it doesn't make much difference, because the transferor isn't 
part of the new (referred) invite dialog. But at least there would be 
some commonality via the session id of the refer.

	Thanks,
	Paul

---

From: James Polk <[email-masked]>
Date: Mon, 15 Jul 2013 20:38:51 -0500

At 08:17 PM 7/15/2013, Paul Kyzivat wrote:
>Its up to you to make the rules. A focus uses the same uuid for all 
>the dialogs in the conference. So why shouldn't the transferor use 
>the same uuid for the before/after dialogs?
>
>Ultimately it doesn't make much difference, because the transferor 
>isn't part of the new (referred) invite dialog. But at least there 
>would be some commonality via the session id of the refer.

I agree with commonality as a goal. However, in this case, Robert 
specifically wanted an "out-of-dialog REFER", and he hand picked the 
figure out of RFC 5589 for us to use - one that didn't have a 
dialog-ID in common with the Alice-to-Bob dialog.

I believe that's what we showed.

I could be wrong though...

James

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Jul 2013 22:07:11 -0400

On 7/15/13 9:38 PM, James Polk wrote:
>> the dialogs in the conference. So why shouldn't the transferor use the
>> same uuid for the before/after dialogs?
>>
> figure out of RFC 5589 for us to use - one that didn't have a dialog-ID
> in common with the Alice-to-Bob dialog.
>

Well, without showing the sip messages it is not possible to tell if you 
are doing out of dialog REFER or not.

If it were in-dialog, then I guess the session id would be {B,A}.

If its out of dialog, then it could still be {B}. And then Alice, seeing 
that the target-dialog is {A,B}, might choose to respond to the REFER 
with {A,B} even though it is a different dialog, or {Y,B} because it is 
a different dialog. (That seems a little fuzzy.)

	Thanks,
	Paul