Subject: [Insipid] Comments on draft-ietf-insipid-session-id-00

From: Robert Sparks <[email-masked]>
Date: Wed, 03 Apr 2013 16:20:24 -0500

Some things I noted while reading through this document and formulating 
the definition I proposed.

In section 4 paragraph 5, we need to account for the possibility that 
you can have multiple 200 OKs or
that the INVITE may pend forever, and you never get any 200 OKs. That 
is, each of  the session listed
here may become full fledged "calls". The current text strongly implies 
that all but one of them are
ephemeral things.

The text (probably somewhere in section 5 or very early in section 6) 
should be more forceful in pointing
out that the sense of the remote part of this identifier is treated 
exactly the opposite in responses than
the related from and to tags. It's an ok decision for the group to make, 
but unless you make it _extremely_
obvious, it's very likely that an implementer would reuse their "what 
tag to I put in the To: of responses" logic.

Section 6, paragraph 1: s/all messages transmitted/all SIP messages 
transmitted/

Section 6 needs to make it clear what an intermediary sending a 
hop-by-hop SIP message (such as a 100 trying,
or a CANCEL) must or must not include for a Session-ID. I noted that 
after the end of the second paragraph - maybe
that's a good place for the discussion?

Section 6 paragraph 3 is out of place - it breaks the flow of the 
endpoint behavior section. I suspect it needs
a section of its own, and it needs to say more. If a UA gets a remote 
parameter that does not match what it thought
it was, should it start _using_ the parameter value it received in any 
subsequent messages it sends, or should it stick
with what it thought it's end was supposed to be? I'm assuming the 
latter, given paragraph 5 (which I think should
also be moved along with paragraph 3. Either way, the text needs to be 
explicit.

Section 7. How is the first paragraph useful? It's either 
underspecified, or not needed. Currently, the document says
the same thing if you delete it.

Section 8 first paragraph: What happens if the MCU gets one of the alien 
UUIDs mentioned in section 6 paragraph 3?
What would a system that was gathering all the messages related to the 
conference do (as hinted in the second paragraph)?
Wouldn't it miss such a message since it wouldn't have the UUID the MCU 
had created in it? Or are you expecting you would
find it through a chain of association with whatever happened at the 
endpoint that sent the martian?

A                    MCU
|<--  {MCU} -- |
|--- {A,MCU}->|
|<--{MCU, A}--|
|-- {A,MARS}->|

Section 9 needs to be recast explicitly as examples. It is very 
confusing to have things in examples labelled "Rules" or appear
to be defining operation.

Section 9.2 should show a 100 Trying

Consider adding a variant of 9.2 that sends the REFER out-of-dialog - 
would such a thing have the same session-id or a different one?

The example in Section 9.3 is broken. As drawn, Carol and Alice would be 
very surprised when the media they just started exchanging went away as 
bob causes Carol's UA to hang up.

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 9 Apr 2013 18:39:42 -0400

Robert,

My apologies for the belated reply.  I've been extremely busy this past week
or so.

> that all but one of them are

Perhaps the issue is the language " Until one UA returns a 200 OK to the
initial INVITE,"

If we delete that wording, would it help?  The intent is that the
communication session between Alice and Bob-1 can be identified
independently from that communication session between Alice and Bob-2, and
using different UUIDs at each device makes this possible.
 
> tag to I put in the To: of responses" logic.

How about this right at the end of the first paragraph in Section 6?

"The UUID of the sender of the message MUST appear first in the Session-ID
header and the UUID of the peer device, if known, must appear as the
"remote" parameter following the sender's UUID."

But now that you ask this... :-)

Suppose Alice send an INVITE to Bob and receives Bob-1, Bob-2, and Bob-3
UUIDs.

Now suppose Alice wants to send an UPDATE?  What UUID does Alice put as the
"remote" parameter?  (Originally, we did not have the "remote" parameter,
since we knew this value would be different for very Bob-x that replied.)
 
> Section 6, paragraph 1: s/all messages transmitted/all SIP messages

OK
 
> that's a good place for the discussion?

Section 7 is intended to discuss intermediary behavior and it says
intermediaries must not alter the UUID values.  Whether it adds them or not
should be optional and that is also covered in Section 7.  So, what is
missing, exactly?
 
> a section of its own, and it needs to say more.

I think the paragraph is in the right place, because we're still talking
about Bob here.  I think what's confusing is the use of the words
"non-intermediary UAS".  We're talking about Bob, but there was a request to
make the point that we're not talking about intermediaries when we speak of
this section.  If we replace "non-intermediary UAS" with "UA", would this
sound better?

> If a UA gets a remote

The "remote" parameter that Alice would receive in a message is her UUID.
If it's wrong, she should ignore it.

I think your question is if Bob receives one "local-UUID" value in an INVITE
and 20 minutes later there is a new INVITE for the same call with a
different "local-UUID" value, which value should Bob use in subsequent
messages?  The answer would be the most recently received "local-UUID"
value.

How about I change paragraph 5 of Section 6 to read (new text surrounded by
__):
"An endpoint MUST assume that the UUID value of the peer UA MAY change at
any time due to service interactions.  __If the UUID value of the peer UA
changes, the UA MUST include this new UUID as the "remote" parameter in any
subsequent messages.__  However, once a UA allocates a UUID value for a
communication session, the UA MUST NOT change that UUID value..."

I would further like to suggest we split this paragraph.  It deals with two
topics: the fact that an endpoint never changes its own UUID for a session
and the fact that the remote UUID might change due to service interaction.

> the same thing if you delete it.

Probably not terrible useful.  It's more informative than normative, I
think.  I'll remove it.

> UUIDs mentioned in section 6 paragraph 3?

The MCU is only interested in the "local-UUID" field.  It would not get an
alien value there.  If a device participating in a conference uses some
non-standard means of transferring the call to a new endpoint, the MCU might
see a new "local-UUID" value.  That's expected as described in Section 6.
(The MCU is just an endpoint.)

> conference do (as hinted in the second paragraph)?

Whatever it wanted to do. The intent is not prescribe what a devices is to
do with values like:
 {A, B}
 {A, C}
 {A, D}

Rather, it is there to show that one might assume some kind of relationship.
It might be a conference call, or it might be that A called B, B transferred
the call to C, and C transferred the call to D.

> endpoint that sent the martian?

I'm not sure how MARS got into that flow.  Why would A send a UUID that had
never been part of these flows?
 
> to be defining operation.

New second paragraph in 9 that says this?
"This section is for illustrative purposes only and is non-normative."

> Section 9.2 should show a 100 Trying

I would not expect there to be a Session-ID header in a 100 Trying since
it's not generated by an endpoint.  Since 9.2 is a little busy, would you
rather see this in 9.1?
 
> would such a thing have the same session-id or a different one?

Given that an OOD REFER is not part of a session, then that should introduce
a new Session-ID UUID, right?
 
> bob causes Carol's UA to hang up.

I assume the offending part is:

     {B,A}      |<-----BYE-------|                |               |
     {A,B}      |-----200 OK---->|                |               |

That should not be going to Alice.

Paul

---

From: Robert Sparks <[email-masked]>
Date: Tue, 09 Apr 2013 19:01:41 -0500

> using different UUIDs at each device makes this possible.
It would help, but look for more - right now, the text still has more of 
a flavor
of a "call"-like thing rather than a dialog-like thing. You're wanting 
to be more
dialog-like here.
> "remote" parameter following the sender's UUID."
You missed the important part of my point. The issue is that you are 
treating
the session-id differently in _responses_ than SIP treats to and from 
tags in
responses.

The from-tag in a response is going to be _exactly_ what it was in a 
request.

The local part of the Session ID is going to be _different_ in a 
response than it was in the request.

Let me try this with two example (partial) messages - Lets use a BYE and 
its associated 200 OK

BYE sip:[email-masked] SIP/2.0
To: sip:[email-masked];tag=aTagThatFooMade
From: sip:[email-masked];tag=aTagThatBarMade
Session-ID: <32 characters of stuff bar made up>;remote=<32 characters 
of stuff foo made up>

SIP/2.0 200 OK
To: sip:[email-masked];tag=aTagThatFooMade
From: sip:[email-masked];tag=aTagThatBarMade
Session-ID: <32 characters of stuff foo made up>;remote=<32 characters 
of stuff bar made up>

This is a consequence of this sentence from section 5:
    The "local-uuid" in the Session-ID header represents the UUID value
    of the UA transmitting the message.

Bar transmitted the request message (the BYE), and Foo transmitted the 
response message (the 200 OK).

I'm assuming you wanted that to be different than from how tags are 
handled on purpose.
That's fine, but we should be proactive in pointing that difference out.

> since we knew this value would be different for very Bob-x that replied.)
This is a no-brainer. She will use the UUID for the instance of Bob-X that
she's sending the UPDATE to. Remember that an UPDATE sent in a dialog
like this goes to one particular dialog, and the remote target established
by that dialog. It will not fork. If Alice is wanting to affect all of 
the Bob-X,
she will need to send an UPDATE to each of them, each using UUID provided
by that particular Bob-X.
> should be optional and that is also covered in Section 7.  So, what is
Proxies _source_ 100 Tryings and CANCELs. They don't forward them.
Point to me where you think explaining what to put in either a 100 Trying
or a Cancel is in the current text. I assert that you have not covered 
either
message (or any other hop-by-hop message, such as an ACK to a non-200
final response to an INVITE).

I suspect you are wanting to copy the logic that 3261 uses for populating
the To and From headers (specifically the tags) for those messages (except
for reversing the sense of what's remote in responses as above). But the
document currently does not say that.

A couple of quick examples here. You need to draw more in the document.

(using S: as a shorthand for Session ID, and the {A}, {A,B}, {B,A} 
notation from the draft.)

View this in a fixed width font
  A          Proxy             B1           B2
  | Inv        |               |             |
  | S: {A}     |               |             |
  |----------->|               |             |
  |            | Inv           |             |
  |            | S: {A}        |             |
  |            |-------------->|             |
  |            | Inv           |             |
  |            | S: {A}        |             |
  |            |---------------------------->|
  |            | 603 Decline   |             |
  |            | S: {B1,A}     |             |
  |            |<--------------|             |
  |            | ACK           |             |
  |            | S: {A,B1}     |             |
  |            |-------------->|             |
  |            | CANCEL        |             |
  | 603 Decline| S: {A}        |             |
  | S: {B1,A}  |---------------------------->|
  |<-----------| 200 OK (to the CANCEL)      |
  | ACK        | S: {B2,A}     |             |
  | S: {A,B1}  |<----------------------------|
  |----------->| 487 Request Cancelled       |
  |            | S: {B2,A}                   |
  |            |<----------------------------|
  |            | ACK                         |
  |            | S: {A,B2}                   |
  |            |---------------------------->|

I am _guessing_ at what you intended to be in that CANCEL and its 200 OK,
and in the hop-by-hop ACKs. Did I guess correctly? What if B2 were another
proxy - would it make up a B2 to put in the 200 OK to that cancel?

The text needs to be clear about these things.

> this section.  If we replace "non-intermediary UAS" with "UA", would this
Uh, no. I'm talking about the paragraph that says

    It should be noted that messages received by a UA might contain a
    "remote" parameter that does match the UAs UUID.  This might happen
    as a result of service interactions by intermediaries and MUST NOT be
    regarded as an error.

You appear to be talking about paragraph 2, not paragraph 3.
> If it's wrong, she should ignore it.
Where does the document say that that Alice would ignore it?
Again, I'm talking about that third paragraph of section 6 that I quote 
above.
This is the "Martian" that I talk about below as well. Something sent
a message to Alice containing a remote parameter that _should_ have been
what Alice provided, but it wasn't. All you say is that Alice shouldn't 
treat that
as an error. You don't say (yet) that she should ignore it. If that's 
what should
happen you should go further and say endpoints should never even look at 
what
they receive an the remote parameter.
> messages?  The answer would be the most recently received "local-UUID"
That was absolutely not my question.
I hope you have it now from what's above, but I'll be graphic:
What section 6 paragraph 3 says is that this can happen to Alice:
(Again, view in a fixed-width font)
Alice    Intermediary
   | S:{A}   |
   |-------->|
   | S:{B,A} |
   |<--------|
   |         | (the service interactions section 6 paragraph 3 mentions
   | S:{B,M} |  happen somewhere over here)
   |<--------|

You are saying that the next message alice sends in that session should 
contain S:{A,B}, and would never contain an M.
The document does not yet say that.

> and the fact that the remote UUID might change due to service interaction.
That will help.
> alien value there.
I'm sorry - there may be service interactions in processing a request it 
sends,
and the response it gets has a Q in it, just like above.  The fix you 
are working
towards will handle this case.
>   If a device participating in a conference uses some
> I'm not sure how MARS got into that flow.
I hope you understand how that would happen now. Section 6 paragraph 3.
>    Why would A send a UUID that had
Maybe it would have helped if I drew A as an intermediary initially.
> "This section is for illustrative purposes only and is non-normative."
That's not enough. Please don't be lazy. Change the text.
> it's not generated by an endpoint.  Since 9.2 is a little busy, would you
_REALLY_?
I don't expect the working group to agree with you, but let's ask.
Those folks wanting to be able to grab messages to do diagnostics
are going to be _seriously_ interested in those hop-by-hop cancels,
100s, 200 OKs, and ACKs.
> a new Session-ID UUID, right?
Are you sure? Your ability to correlate the INVITES in a transfer goes 
out the window
if you make that OOD part of a different session. You might want to see 
if the
definition I sent will allow you to treat the OOD refer as part of the 
same session,
or be explicit that you are not providing the ability to correlate the 
messages in this case.
> That should not be going to Alice.
Correct.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 10 Apr 2013 02:43:45 -0400

Robert,

Please see comments below (PEJ):

 

You missed the important part of my point. The issue is that you are
treating
the session-id differently in _responses_ than SIP treats to and from tags
in
responses.

PEJ: I got the point.  What you said is correct, which is why I used the
language "sender of the message".  If that's not clear, how can we make it
clear?

PEJ: Ah, yes. now that point I missed.  You're correct that this is not
presently addressed.  What confused me was that you were in Section 6, but
this should be a topic of Section 7.

PEJ: For 100 Trying, the proxy would not be in a position to offer either
UUID, unless it just fabricated a bogus value.  We could do that, but is
there value in doing so?  A CANCEL could have valid values if the
intermediary maintains state information (as shown in in your example
below).  I think we need suggestions on what to do here.  I would hope this
guidance could go into Section 7.

(using S: as a shorthand for Session ID, and the {A}, {A,B}, {B,A} notation
from the draft.)

PEJ: I'm inclined to  say that a proxy initiating or replying to such
messages should not include a Session-ID if it does not know what the
endpoint UUIDs are. But, as I said, I'm open to input on this one.  I don't
know what the most appropriate thing is to do.

PEJ: Agreed.  I don't think it was considered before.

PEJ: OK.  That particular paragraph is then followed by a paragraph that is
related.  So, if we move that, we need to move the next.  Actually, this
whole section has undergone a bit of revision.  I'll post the text to the
list separately and let's work on the organization and wording. ;-)

If a UA gets a remote

as an error. You don't say (yet) that she should ignore it. If that's what
should

PEJ: I agree with your last statement: Alice should never even consider the
"remote" parameter, as it's useless to her.  However, we had a discussion on
this point and folks said that Alice might want to log it.  So, I unless
folks want to retract the view, I can't write that she should ignore it.
That's text that is in my version, but not yet published.  That will be in
the text I send to the list shortly.  Let's consider that and further refine
it.

PEJ: The text says Alice would never change her UUID for the duration of the
session.  She would always send {A, <whatever she received in the most
recent message>}.  If that's not clear, it should be simple to clarify it.
I'll admit I might be conveying something that's not written clearly, since
I know what I expect.   But, I'm missing why it's not clear.  In the above
flow, Alice received a message from B to her (A).  Then she received a
message from B to her, but this time mislabeled.  I don't see how that can
happen.  Now, had B been transferred to C (using some non-standard
signaling), C might send a message to A that was {C,M}.  Alice should accept
that (as per Section 6).  But, I would not expect the above flow.

I'm sorry - there may be service interactions in processing a request it
sends,
and the response it gets has a Q in it, just like above.  The fix you are
working
towards will handle this case.

A                    MCU
|<--  {MCU} -- |
|--- {A,MCU}->|
|<--{MCU, A}--|
|-- {A,MARS}->|

PEJ: This is similar to the above, but again I don't know how/when/why A
would suddenly change the "remote" value it sends in a flow like this.

PEJ: I don't think it would make any difference.  If the intermediary
originated a UUID (e.g., the 3PCC case), it might send {Q} to the MCU and
the MCU replies with {MCU,Q}.  Later, a UA (D) is inserted and sends a
message to the MCU.  Messages might contain {D,MCU} or {D,E} (where "E" was
a value the intermediary had previously used with D).  Either of these
things could happen.

PEJ: OK

_REALLY_?

PEJ: I didn't speak of CANCEL or 200, just 100 Trying.  What would make
sense in a 100?

Given that an OOD REFER is not part of a session,

 then that should introduce
a new Session-ID UUID, right?

Are you sure? Your ability to correlate the INVITES in a transfer goes out
the window
if you make that OOD part of a different session. You might want to see if
the
definition I sent will allow you to treat the OOD refer as part of the same
session,
or be explicit that you are not providing the ability to correlate the
messages in this case.

PEJ: Good point.  I think we would want that correlation.

Paul

---

From: Robert Sparks <[email-masked]>
Date: Wed, 10 Apr 2013 09:25:45 -0500

Thanks Paul -

Trimming heavily to just a couple of things.

On 4/10/13 1:43 AM, Paul E. Jones wrote:
>
> PEJ: I got the point.  What you said is correct, which is why I used 
> the language "sender of the message".  If that's not clear, how can we 
> make it clear?
>
Add a sentence that says something like this:

"Note that unlike To and From tags which remain in the same order in the 
request and all responses to the request, the components of the 
Session-ID in each response will in the reversed order from the request".

I'm sure that needs wordsmithing though.

Now, for the martian value conversation, using this figure again, but 
> (Again, view in a fixed-width font)
(leaving this bit for context)
>
> You are saying that the next message alice sends in that session 
> should contain S:{A,B}, and would never contain an M.
> PEJ: The text says Alice would never change her UUID for the duration 
> of the session.  She would always send {A, <whatever she received in 
> the most recent message>}.  If that's not clear, it should be simple 
> to clarify it. I'll admit I might be conveying something that's not 
> written clearly, since I know what I expect.   But, I'm missing why 
> it's not clear.  In the above flow, Alice received a message from B to 
> her (A).
>
Here's what I want to talk about.
>
> Then she received a message from B to her, but this time mislabeled.  
> I don't see how that can happen.
>
I think we're identifying then that the document needs to be clearer 
when you move paragraph 3 of section 6.
Right now, the document explicitly _says_ that figure can happen. Look 
at the figure and this text. If the text is
meant to say something that prevents (or at least does not imply) that 
picture, call it out.

> Now, had B been transferred to C (using some non-standard signaling), 
> C might send a message to A that was {C,M}. Alice should accept that 
> (as per Section 6).  But, I would not expect the above flow.
>
So more explanation in the document about what could lead to the 
condition is in order (providing an full example of the service
interaction involved), and I think we need to dive a level of detail lower.

Are you saying that inside a given SIP dialog, you know of no way that 
Alice would receive a message with a Session-ID containing a remote-uuid 
did not match what Alice had provided in an earlier uuid?

If so, then the only time this could occur is in an out of dialog 
message (like an initial INVITE). Are you sure that whatever 
circumstances that led to there being a remote-uuid in that message 
wouldn't also have lead to there being a non-empty to-tag? If it did, 
Alice would reject the message with a 481. If you _can_ think of a 
circumstance where Alice would get an initial message with a populated 
remote-uuid that she didn't provide that was otherwise admissible SIP, 
could you put a description of it in the document?

Either way, in the text you are working on re: not using the 
remote-uuid, please explicitly call out the case of one showing
up in an out-of-dialog message.
> PEJ: I didn't speak of CANCEL or 200, just 100 Trying.  What would 
> make sense in a 100?
>
Whatever appeared in the INVITE the 100 is squelching the retransmissions of
(with local and remote reversed).
That squelching of retransmissions is why the people that are looking at 
using this for diagnostic
purposes are going to really want to be able to find those 100s.

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 18 Apr 2013 12:57:55 -0400

Robert,

Comments below (PEJ):

From: Robert Sparks [mailto:[email-masked]] 
Sent: Wednesday, April 10, 2013 10:26 AM
To: Paul E. Jones
Cc: [email-masked]
Subject: Re: [Insipid] Comments on draft-ietf-insipid-session-id-00

Thanks Paul -

  

"Note that unlike To and From tags which remain in the same order in the
request and all responses to the request, the components of the Session-ID
in each response will in the reversed order from the request".

PEJ: I'm still struggling with this language.  The example mentions two
headers, whereas we're dealing with a single header.  This is more like the
Max-Forwards header, which is set by the sender.  How about this:

Note that the "sender" of the message is not the user agent that initiates a
transaction.  Rather, the "sender" is the user agent initially transmits a
message, regardless of whether this is a new transaction or a response to a
message received.

I just tried to clarify what "sender" means.  But, this might also need
wordsmithing.  How close is this?

Now, for the martian value conversation, using this figure again, but still
trimming heavily:

flow, Alice received a message from B to her (A).  

Then she received a message from B to her, but this time mislabeled.  I
don't see how that can happen.  

I think we're identifying then that the document needs to be clearer when
you move paragraph 3 of section 6.
Right now, the document explicitly _says_ that figure can happen. Look at
the figure and this text. If the text is
meant to say something that prevents (or at least does not imply) that
picture, call it out.

PEJ: Thinking about this further, I suppose it could happen, so we need to
allow for it.  A B2BU in the middle might attempt to transfer B to M.  That
might fail or the "call leg" is transitioned back to A for good cause.  As
examples here, B might be directed to a music-on-hold server or a transfer
attempted that fails (and transitions back).

Now, had B been transferred to C (using some non-standard signaling), C
might send a message to A that was {C,M}.  Alice should accept that (as per
Section 6).  But, I would not expect the above flow.

So more explanation in the document about what could lead to the condition
is in order (providing an full example of the service
interaction involved), and I think we need to dive a level of detail lower.

Are you saying that inside a given SIP dialog, you know of no way that Alice
would receive a message with a Session-ID containing a remote-uuid did not
match what Alice had provided in an earlier uuid? 

If so, then the only time this could occur is in an out of dialog message
(like an initial INVITE). Are you sure that whatever circumstances that led
to there being a remote-uuid in that message wouldn't also have lead to
there being a non-empty to-tag? If it did, Alice would reject the message
with a 481. If you _can_ think of a circumstance where Alice would get an
initial message with a populated remote-uuid that she didn't provide that
was otherwise admissible SIP, could you put a description of it in the
document?

Either way, in the text you are working on re: not using the remote-uuid,
please explicitly call out the case of one showing
up in an out-of-dialog message.

PEJ: Given my revised position that this could be valid signaling, are you
OK with the text?

_REALLY_?

PEJ: If the called endpoint sends a 100 (for whatever reason), I would
expect the Session-ID to be present.  The concern is with intermediaries.
Those are more likely to generate a 100, but they are not the called
endpoint.  We could specify that the intermediaries generate a bogus UUID
value, but what value is that?  Should we specify that the intermediaries
return a Session-ID with a UUID of zero and insert the "remote" parameter.
Whatever folks want, I think we can discuss this explicitly in Section 7.

Paul