Subject: Re: [Insipid] Query on solution draft

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 3 Jul 2012 21:40:05 -0400

Sorry I did not reply on this thread sooner.

What the proposed solution document currently says is that we concatenate
the two strings in a particular order.  Obviously, I was happy with that,
but felt like I'd open that up for discussion since there had been some
dialog about the construction of the ID.

I appreciated having a simple header like this:

Session-ID-UUID: <uuid>

This would be the UUID of the sender of the message.  I like that for a
variety of reasons.  The "Session-ID" itself is a derived value, taking
components from the left-hand side (Alice) and right-hand side (Bob).  The
construction rules should be well-defined.

Question is, do we *need* to signal the entire Session-ID in the header:

Session-ID: <uuid-1><uuid-2>

(Putting in "s" or "from" or ":" or whatever)

Or is it enough to only send Session-ID-UUID?

Note that there are some cases (complicated to explain and even harder to
debug) where we could have two ends changing UUID values simultaneously and
boxes in the middle of the network could receive messages that totally have
the wrong Session-ID header.

I prefer signaling only one UUID.  Do we *need* to include both in messages?

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Saturday, June 30, 2012 11:54 AM
> To: James Polk
> Cc: [email-masked]
> Subject: Re: [Insipid] Query on solution draft
> 
> On 6/29/12 2:22 PM, James Polk wrote:
> > At 08:53 AM 6/29/2012, Paul Kyzivat wrote:
> >> On 6/28/12 10:19 PM, Paul E. Jones wrote:
> >>> James,
> >>>
> >>>> If we agree that once the whole Session-ID is compiled, meaning the
> >>>> GUID from UA1 and the GUID from UA2 are concatenated in some order,
> >>>> that header value remains on in all SIP messages between those 2
> >>>> UAs until session termination or a transfer or join operation
> >>>> occurs.
> >>>>
> >>>> I think this is the right way forward. Is this agreeable to everyone?
> >>>
> >>> I'm OK with that so long as we indicate directionality. In the rare
> >>> event that two ends are joined to different calls are roughly the
> >>> same time, I would want intermediaries and the remote system to be
> >>> able to tell which of the two values UUIDs belong to the remote
> >>> device. Thus, something like:
> >>>
> >>> Session-ID: S:x;R:y
> >>>
> >>> (referring to the sender (S) of the message and the assumed
> >>> recipient (R)).
> >>>
> >>> If we do not do this, then Carol might receive this:
> >>>
> >>> Session-ID: XY
> >>>
> >>> And Carol knows her UUID is L and has no idea which value (X or Y)
> >>> belongs to the remote device. It's a rare case, but we can avoid it
> >>> ever becoming an issue by keeping the two UUIDs separated somehow.
> >>> This can be through "S:" tags or the order of placement (sender ||
> >>> receiver).
> >>
> >> Be careful here. You seem to be trying to pile on two different
> >> semantics. On one hand you are trying to associate each "half" of the
> >> id with the end that assigned it. On the other hand, for comparing
> >> two IDs you don't care what end is associated with what half - you
> >> want the IDs from two messages sent in opposite directions to compare
> equal.
> >>
> >> For precedent, what you are describing is very comparable to the
> >> from-tag and to-tag.
> >>
> >> What Paul J is suggesting (S:, R:) can work as long as comparison
> >> rules are properly defined. E.g. (as I already proposed) to compare
> >> IDs X and Y, compare min(Xs, Xr) to min(Ys, Yr) and max(Xs, Xr) to
> >> max(Ys, Yr).
> >>
> >> I'm inclined to suggest the following format:
> >>
> >> Session-ID: from=x; to=y
> >>
> >> to show the similarity to from and to tags.
> >
> > What I originally proposed was to order Alice's GUID first, then
> > Bob's, but make it implicit in which all observers of the Session-ID
> > header value could easily determine which was the initiator and which
> > was the responder - but only if the GUIDs were always of a known/fixed
> > length (i.e., always 24 or 32 bytes for each GUID). This is instead of
> > the analysis of which GUID is a greater value vs. which is a lessor
> > value and concatenate that way.
> 
> I don't understand. Once a dialog is established, it needs to be the case
> that the sessionid is the same for messages sent by Alice and those sent
> by Bob. And I don't think you can count of figuring out which end
> initiated the dialog. (In some cases with B2BUAs, both ends may initiate,
> or sometimes the middle initiates toward both ends.)
> 
> 	Thanks,
> 	Paul
> 
> > With that model, when Bob transfers Alice to Carol, Alice's GUID would
> > remain part of the Session-ID while Bob's would be replaced by Carol's
> > (once she responds).
> >
> > Now, I know I haven't thought about all versions of joins to
> > appreciate if there is a corner case of join that breaks this model.
> > But, I'm not sure we need to include the 'S:' & 'R:' or 'from=' &
> > 'to=' unless we determine we need to be explicit. If that's the case,
> > I'd like to see (i.e., a diagram of) an example of that corner case.
> >
> > WRT the idea of whether or not to have the GUIDs present in the
> > Session-ID header value, this is clean and not left to assumption as
> > to what is the other GUID value that is not in that SIP message. It's
> > not like we're attempting to hide one GUID from being seen on the
> > wire, that's what TLS is for if that's a concern.
> >
> > James
> >
> >
> >> Thanks,
> >> Paul
> >> _______________________________________________
> >> insipid mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/insipid
> >
> >
> 
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Jul 2012 23:34:54 -0400

If you only signal the sending end's id in each message, it complicates 
logging, or else it complicates log analysis. Somebody needs to save 
state to fill in the "other" half of the id for log analysis.

	Paul K

On 7/3/12 9:40 PM, Paul E. Jones wrote:
> Session-ID-UUID:<uuid>
> Session-ID:<uuid-1><uuid-2>
>
>>> But, I'm not sure we need to include the 'S:'&  'R:' or 'from='&

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 4 Jul 2012 08:25:42 +0000

It is preferred to have two piece of information rather than one as each end form its own id and make the unique id based on its concatenation.

There is no need to spell out in the session-id whether it is "from" piece or "to" piece as it does not matter during the mid-dialog and it is subjected to change due to different SIP application/services.

Thanks
Partha 

>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Paul Kyzivat
>Sent: Wednesday, July 04, 2012 9:05 AM
>To: Paul E. Jones
>Cc: 'James Polk'; [email-masked]
>> What the proposed solution document currently says is that we
>> concatenate the two strings in a particular order.  Obviously, I was
>> happy with that, but felt like I'd open that up for discussion since
>> there had been some dialog about the construction of the ID.
>>
>> This would be the UUID of the sender of the message.  I like that for
>> a variety of reasons.  The "Session-ID" itself is a derived value,
>> taking components from the left-hand side (Alice) and right-hand side
>> (Bob).  The construction rules should be well-defined.
>>
>> debug) where we could have two ends changing UUID values
>> simultaneously and boxes in the middle of the network could receive
>> messages that totally have the wrong Session-ID header.
>>
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of Paul Kyzivat
>>>>>>> If we agree that once the whole Session-ID is compiled, meaning
>>>>>>> the GUID from UA1 and the GUID from UA2 are concatenated in some
>>>>>>> order, that header value remains on in all SIP messages between
>>>>>>> those 2 UAs until session termination or a transfer or join
>>>>>>> operation occurs.
>>>>>>>
>>>>>> I'm OK with that so long as we indicate directionality. In the
>>>>>> rare event that two ends are joined to different calls are roughly
>>>>>> the same time, I would want intermediaries and the remote system
>>>>>> to be able to tell which of the two values UUIDs belong to the
>>>>>> remote device. Thus, something like:
>>>>>>
>>>>>> Session-ID: S:x;R:y
>>>>>>
>>>>>> belongs to the remote device. It's a rare case, but we can avoid
>>>>>> it ever becoming an issue by keeping the two UUIDs separated
>somehow.
>>>>> semantics. On one hand you are trying to associate each "half" of
>>>>> the id with the end that assigned it. On the other hand, for
>>>>> comparing two IDs you don't care what end is associated with what
>>>>> half - you want the IDs from two messages sent in opposite
>>>>> directions to compare
>>> equal.
>>>>>
>>>> header value could easily determine which was the initiator and
>>>> which was the responder - but only if the GUIDs were always of a
>>>> known/fixed length (i.e., always 24 or 32 bytes for each GUID). This
>>>> is instead of the analysis of which GUID is a greater value vs.
>>>> which is a lessor value and concatenate that way.
>>>
>>> I don't understand. Once a dialog is established, it needs to be the
>>> case that the sessionid is the same for messages sent by Alice and
>>> those sent by Bob. And I don't think you can count of figuring out
>>> which end initiated the dialog. (In some cases with B2BUAs, both ends
>>> may initiate, or sometimes the middle initiates toward both ends.)
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>>> With that model, when Bob transfers Alice to Carol, Alice's GUID
>>>> would remain part of the Session-ID while Bob's would be replaced by
>>>> Carol's (once she responds).
>>>>
>>>> 'to=' unless we determine we need to be explicit. If that's the
>>>> case, I'd like to see (i.e., a diagram of) an example of that corner
>case.
>>>>
>>>> to what is the other GUID value that is not in that SIP message.
>>>> It's not like we're attempting to hide one GUID from being seen on
>>>> the wire, that's what TLS is for if that's a concern.
>>>>
>>>> James
>>>>
>>>>
>>>>> Thanks,
>>>>> Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 04 Jul 2012 11:57:25 -0400

Yes, that's the trade off. Signaling both without somehow indicating which one belongs to the remote end can also cause confusion. I think the SIP header should allow each end to signals its value such that it is clear which value belongs to the other end. Its possible in a call join scenario where both ends do a join at the same time for an invite to come across the wire that has two uuids, one right and one wrong, but the receiver cannot tell what's right and intermediaries will log the wrong values.

Rare case, but can happen.

So, I like

Session-ID: alice/bob

Or similar. 

Paul

_____________________________________________
From: Paul Kyzivat <[email-masked]>
Sent: Tue Jul 03 23:34:54 EDT 2012
To: "Paul E. Jones" <[email-masked]>
Cc: 'James Polk' <[email-masked]>, [email-masked]
Subject: Re: [Insipid] Query on solution draft

	Paul K

On 7/3/12 9:40 PM, Paul E. Jones wrote:
>>>>_____________________________________________

>>_____________________________________________

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Jul 2012 12:18:35 -0400

OK, it seems there are some conflicting desires here.

Specifically, it seems hard to encode both "halves" of the id in a way 
that is the same for requests traveling in either direction, and to 
identify which half belongs to which end. This may be because the only 
way that has been suggested for distinguishing the two ends is by the 
direction of a request.

This could be solved by carrying the half-id as a parameter of the 
From/To headers. (IOW a new and improved tag.) But this probably doesn't 
work because proxies aren't allowed to modify the From/To.

It could also be addressed by tagging the half-ids with a param 
indicating if it is for the sender or receiver. This would have to be 
flipped for requests in the other direction. And this would need to be 
ignored when comparing IDs.

If we just beefed up the requirements on from-tags and to-tags, then 
they could serve this purpose. But that would mean that for UAs that 
don't support this you could only fix it in B2BUAs, not proxies. But 
this might still be a most expedient way to go.

	Thanks,
	Paul

	Thanks,
	Paul

On 7/4/12 11:57 AM, Paul E. Jones wrote:
> Yes, that's the trade off. Signaling both without somehow indicating
> which one belongs to the remote end can also cause confusion. I think
> the SIP header should allow each end to signals its value such that it
> is clear which value belongs to the other end. Its possible in a call
> join scenario where both ends do a join at the same time for an invite
> to come across the wire that has two uuids, one right and one wrong, but
> the receiver cannot tell what's right and intermediaries will log the
> wrong values.
>
> ------------------------------------------------------------------------
> *From:* Paul Kyzivat <[email-masked]>
> *Sent:* Tue Jul 03 23:34:54 EDT 2012
> *To:* "Paul E. Jones" <[email-masked]>
> *Cc:* 'James Polk' <[email-masked]>, [email-masked]
> *Subject:* Re: [Insipid] Query on solution draft
>
>>  variety of reasons.  The "Session-ID" !
>   itself
> is a derived value, taking
>>>  From: [email-masked]
> [mailto:[email-masked]] On Behalf
>>>  Of Paul Kyzivat
>>>>>>>  I thin!
>   k this
> is the right way forward. Is this agreeable to everyone?
>>>>>>
>>>>>>  And Carol knows her UUID is L a!
>   nd has
> no idea which value (X or Y)
>>>>>  from-tag and to-tag.>>>>
>>>>  length (i.e., always 24 or 32 bytes fo!
>   r each
> GUID). This is instead of
> ------------------------------------------------------------------------
>
>>>>>  insipid mailing list
>>>>>
> [email-masked]
> ------------------------------------------------------------------------
>
>>>  insipid mailing list
>>>  [email-masked]

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 4 Jul 2012 20:27:37 -0400

Partha,

You're largely correct, but let's suppose you are Alice and you receive an
INVITE that has:

Session-ID: D||E

Neither of those identifiers belong to Alice, so which one belongs to the
remote endpoint?

This *can* happen when we have two PBXes in the path, for example, that
independently perform a call "join" operation and fabricate INVITE messages
on behalf of a device and toward a remote device that is now not a party to
the call. :-)  It's an unusual event, I know, but I prefer to avoid corner
cases if we can.

What we call the Session-ID should be the concatenation of two values as
we've prescribed in the solution document.  However, there was a reason for
sending each UUID separately.  This is one of them.

If we put both UUIDs into the message (when available), I'd prefer a format
like:

Session-ID: <sender_uuid>[:<receiver_uuid>]

So, the sender of the message always puts its value first, then we have a
separator of some sort, and then the receiver's UUID.  In this way, the
device that receives a message with some value "D:E" would know that the
remote side's UUID is D and it was unaware of a recent change where messages
are now being directed to it (device C). It can then reply and, in parallel,
inform the remote side of this change in UUIDs:

Session-ID: C:D

Just so people do not consider this is the Session-ID, perhaps we continue
to use "Session-ID-UUID" as the header?

Paul

> From: Ravindran, Parthasarathi [mailto:[email-masked]]
> Sent: Wednesday, July 04, 2012 4:26 AM
> To: Paul Kyzivat; Paul E. Jones
> Subject: RE: [Insipid] Query on solution draft
> 
> It is preferred to have two piece of information rather than one as each
> end form its own id and make the unique id based on its concatenation.
> 
> There is no need to spell out in the session-id whether it is "from" piece
> or "to" piece as it does not matter during the mid-dialog and it is
> subjected to change due to different SIP application/services.
> 
> Thanks
> Partha
> 
> >>>>>> rare event that two ends are joined to different calls are
> >>>>>> roughly the same time, I would want intermediaries and the remote
> >>>>>> system to be able to tell which of the two values UUIDs belong to
> >>>>>> the remote device. Thus, something like:
> >>>>>>
> >>>>>> Session-ID: S:x;R:y
> >>>>>>
> >>>>>> And Carol knows her UUID is L and has no idea which value (X or
> >>>>>> Y) belongs to the remote device. It's a rare case, but we can
> >>>>>> avoid it ever becoming an issue by keeping the two UUIDs
> >>>>>> separated
> >somehow.
> >>>>>> This can be through "S:" tags or the order of placement (sender
> >>>>>> || receiver).
> >>>>>
> >>>>> rules are properly defined. E.g. (as I already proposed) to
> >>>>> compare IDs X and Y, compare min(Xs, Xr) to min(Ys, Yr) and
> >>>>> max(Xs, Xr) to max(Ys, Yr).
> >>>>>
> >>>> Bob's, but make it implicit in which all observers of the
> >>>> Session-ID header value could easily determine which was the
> >>>> initiator and which was the responder - but only if the GUIDs were
> >>>> always of a known/fixed length (i.e., always 24 or 32 bytes for
> >>>> each GUID). This is instead of the analysis of which GUID is a
> greater value vs.
> >>> which end initiated the dialog. (In some cases with B2BUAs, both
> >>> ends may initiate, or sometimes the middle initiates toward both
> >>> ends.)
> >>>
> >>> 	Thanks,
> >>> 	Paul
> >>>
> >>>> would remain part of the Session-ID while Bob's would be replaced
> >>>> by Carol's (once she responds).
> >>>>
> >>>> Session-ID header value, this is clean and not left to assumption
> >>>> as to what is the other GUID value that is not in that SIP message.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 4 Jul 2012 20:55:24 -0400

Paul,

> OK, it seems there are some conflicting desires here.

No, just not being clear, I think.
 
> identify which half belongs to which end. This may be because the only way
> that has been suggested for distinguishing the two ends is by the
> direction of a request.

Indeed.  So, I never proposed having the same header going in each direction.  In the current solution spec, we propose Alice sends:
Session-ID-UUID: A
And Bob sends:
Session-ID-UUID: B

If we wish to include both (or as much as a device knows), Alice might send:

Session-ID-UUID: A:B

And Bob would send:

Session-ID-UUID: B:A

The Session-ID is always:

Session_ID = min(A,B) || max(A,B)

This is computed value may be used by the endpoints or intermediaries.
 
> This could be solved by carrying the half-id as a parameter of the From/To
> headers. (IOW a new and improved tag.) But this probably doesn't work
> because proxies aren't allowed to modify the From/To.

Perhaps.  We also want to ensure transparency and using any existing header concerns me.
 
> It could also be addressed by tagging the half-ids with a param indicating
> if it is for the sender or receiver. This would have to be flipped for
> requests in the other direction. And this would need to be ignored when
> comparing IDs.

We can tag it or order it, I don't care.  Explicit ordering makes for faster processing.
 
> If we just beefed up the requirements on from-tags and to-tags, then they
> could serve this purpose. But that would mean that for UAs that don't
> support this you could only fix it in B2BUAs, not proxies. But this might
> still be a most expedient way to go.

Not sure how this would make life any easier.  Not disagreeing, but just don't see it.

Paul