Subject: Re: [siprec] "==" padding in Metadata URN UUID [wasFW: [Insipid] Session-ID construction choices]

From: James Polk <[email-masked]>
Date: Thu, 02 Aug 2012 20:38:39 -0500

all the examples in the INSIPID drafts are in hex. There's been 
discussions for weeks to use hex, and that's the proposal on the 
table there, so I would suggest not making any decisions in SIPREC 
based on INSIPID using base64 - because that's not a sure thing at 
all at this point.

James

At 12:27 AM 7/31/2012, Paul Kyzivat wrote:
>I don't have strong feelings either way. Just understand that 
>omitting the "==" locks us in to 64 bit values. That doesn't seem to 
>be a big constraint, since the spec we're referencing for the value 
>calls for 64 bits.
>
>         Thanks,
>         Paul
>
>On 7/30/12 8:12 PM, Ram Mohan R (rmohanr) wrote:
>>I am Ok too.
>>
>>Ram
>>
>>>On 30/07/12 10:44 PM, "Leon Portman"<[email-masked]>  wrote:
>>
>>>I am OK
>>>
>>>Leon
>>>On Jul 30, 2012, at 8:13 PM, "Ravindran, Parthasarathi"
>>><[email-masked]>  wrote:
>>>
>>>>Hi all,
>>>>
>>>>Metadata uses based 64 encoding of URN UUID. There is a discussion in
>>>>INSIPID WG to optimize "==" padding occurs due to base 64 URN UUID. I
>>>>attached Paul's snip of the below mail thread.
>>>>
>>>><snip>
>>>>If we go with base64, I agree that we don't need to preserve the
>>>>trailing "==".
>>>></snip>
>>>>
>>>>I'm fine with the optimization as it reduces 2 bytes in each URN UUID
>>>>of metadata XML element. I'm interested in hearing WG opinion about this
>>>>optimization.
>>>>
>>>>Thanks
>>>>Partha
>>>>
>>>>-----Original Message-----
>>>>From: [email-masked] [mailto:[email-masked]] On
>>>>Behalf Of Paul Kyzivat
>>>>Sent: Thursday, July 26, 2012 8:30 PM
>>>>To: Paul E. Jones
>>>>Cc: 'James Polk'; [email-masked]
>>>>Subject: Re: [Insipid] Session-ID construction choices
>>>>
>>>>On 7/24/12 10:51 PM, Paul E. Jones wrote:
>>>>>Paul,
>>>>>
>>>>>Following up on this thread, as I did not see an outcome.  I think
>>>>>this message might be the last in the series on this topic.
>>>>>
>>>>>I think your proposal is along the lines of what we originally
>>>>>proposed. As I understand, there is a desire to always include both A
>>>>>and B's halves.
>>>>>That's fine, so long as devices understand they might change from one
>>>>>message to the next.
>>>>>
>>>>>So given these two abbreviated UUIDs:
>>>>>
>>>>>UUID 1: 0xaeffa652
>>>>>UUID 2: 0xbe11afc8
>>>>>
>>>>>We would have:
>>>>>
>>>>>Session-ID: 0xaeffa652be11afc8
>>>>>
>>>>>If we agree to encode it in hex and agree on the size (a 16 octet
>>>>>UUID), that means this will always be a 64-byte hex string and there
>>>>>is no need to put a :.  We could also base64 encode the 64 octet
>>>>>binary value, which would encode in 44 octets (shaving off 20 octets).
>>>>>
>>>>>Do we want to go for reduced size or more readable hex string?
>>>>
>>>>I don't have a strong feeling about hex vs. base64.
>>>>But I think it would be good to have a separator (I'm not attached to
>>>>":" - that is just an example.) I realize it isn't logically necessary
>>>>as long as the halves are fixed length. But its not very friendly, and I
>>>>think it is worth "wasting" *1* byte on.
>>>>
>>>>If we go with base64, I agree that we don't need to preserve the
>>>>trailing "==".
>>>>
>>>>>As for putting the entire Session-ID into messages, there are many
>>>>>situations where the Session-ID will be wrong.  Let me give you just
>>>>>one example.
>>>>>
>>>>>Syntax:
>>>>>    A == B means A is in a call with B
>>>>>
>>>>>A == B&&   A == C  (A in call with B; A has a separate call with C.)
>>>>>
>>>>>         &&   B == D  (B has a separate call with D)
>>>>>
>>>>>A&   B are talking.  A puts B on hold.
>>>>>A starts talking to C.
>>>>>Meanwhile B puts A on hold and talks to D.
>>>>>
>>>>>A performs some action to join B and C, while at the same time B
>>>>>performs some action to join D and C
>>>>>
>>>>>Assuming a PBX does this magic, we might have some INVITE messages
>>>>>going down the wire like this:
>>>>>
>>>>>          +  INVITE ---->   C (so C can talk to B)  (Session-ID: B || C)
>>>>>PBX1 ---|
>>>>>          +  INVITE ---->   B (so B can talk to C)  (Session-ID: B || C)
>>>>>
>>>>>And we have
>>>>>
>>>>>          +  INVITE ---->   A (so A can talk to D)  (Session-ID: A || D)
>>>>>PBX2 ---|
>>>>>          +  INVITE ---->   D (so D can talk to A)  (Session-ID: A || D)
>>>>
>>>>I can't fully follow the above. My problem is that I don't know where
>>>>PBX1 and PBX2 fit into the topology of A,B,C,D. So I'm not going to
>>>>speculate much.
>>>>
>>>>>Now, these messages are passing on the wire at the same time.  So that
>>>>>message from PBX1 heading toward B is actually now heading toward D.
>>>>
>>>>???
>>>>
>>>>>So, what D receives is Session-ID "B || C".  D thought the Session-ID
>>>>>was A
>>>>>|| D.  It will be confused.  Perhaps PBX2 can massage the Session-ID,
>>>>>|| but
>>>>>it's not supposed to do that.  We really don't want intermediaries to
>>>>>touch it.
>>>>
>>>>Can you please map out the full topology, and a lot more of the call
>>>>flow you have in mind. (Including REFERs, or some other indication of
>>>>how the PBXs are being instructed what to do.) (There are a million ways
>>>>this could be done.)
>>>>
>>>>>To avoid these kinds of race conditions, adding complexity to try to
>>>>>straighten it out, etc., I very much prefer to have only the
>>>>>Session-ID-UUID header that contains only the UUID of the sender of
>>>>>the message.  If we did that, the endpoints in the above scenario
>>>>>would not be confused and the correct Session-ID could be noted in
>>>>>logs.
>>>>
>>>>I'm not ready to leap to this conclusion until I understand the cases
>>>>better.
>>>>
>>>>         Thanks,
>>>>         Paul K
>>>>
>>>>>Paul
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [email-masked] [mailto:[email-masked]] On
>>>>>>Behalf Of Paul Kyzivat
>>>>>>Sent: Wednesday, July 11, 2012 7:38 PM
>>>>>>To: James Polk
>>>>>>Cc: [email-masked]
>>>>>>Subject: Re: [Insipid] Session-ID construction choices
>>>>>>
>>>>>>On 7/11/12 6:23 PM, James Polk wrote:
>>>>>>...
>>>>>>>>>Option#1 - attach a prefix (e.g., From: and To:) to each half
>>>>>>...
>>>>>>>>>We have a proposal going forward: insert the From:/To: tags from
>>>>>>>>>Option #1.
>>>>>>>>>
>>>>>>>>>Does anyone have a technical reason why this wouldn't work?
>>>>>>>>
>>>>>>>>Do you mean to assign From and To once, and then keep it fixed for
>>>>>>>>the duration of the dialog? ISTM that From and To are not well
>>>>>>>>defined in all cases.
>>>>>>>>
>>>>>>>>For instance, consider a BTBUA that sets up a session by inviting
>>>>>>>>both endpoints. Which is From and which is To? IIUC, the reason for
>>>>>>>>labeling this way is so that someone observing a session id in a
>>>>>>>>message can tell which half corresponds to which end. Using From
>>>>>>>>and To won't satisfy that unless those tags are reassigned for each
>>>>>>request.
>>>>>>>>(This is a special case of a conference focus, which you already
>>>>>>>>call out as an exception.)
>>>>>>>
>>>>>>>The desire is to have the same half in the same position throughout
>>>>>>>the transaction or dialog (whichever it is). I believe in the case
>>>>>>>of a B2BUA initiating or originating the transaction or dialog on
>>>>>>>behalf of other endpoint UAs, the B2BUA would pick which Session-ID
>>>>>>>is the  From and which is the To. IOW - we don't make it a
>>>>>>>requirement on an implementation that Alice is always inserting her
>>>>>>>half in first, and Bob in as the second half. If the B2BUA is
>>>>>>>sending an INVITE to both Alice and Bob, then that's 2 separate
>>>>>>>Session-IDs because it's two different dialogs, even if a 3rd party
>>>>>>>isn't part (i.e., listening) of the media flow. This would be a hub
>>>>>>>and 2 spokes in which the hub doesn't listen or interact with the
>>>>>>>media of the 2 UAs.
>>>>>>>
>>>>>>>We could also have text that says for this scenario, that an INVITE
>>>>>>>normally inserts the From half of the Session-ID, but that in this
>>>>>>>scenario it can insert the To: half and the invitee inserts the To
>>>>>>>half.
>>>>>>>
>>>>>>>
>>>>>>>>Identifying which end is which is easy for any single transaction,
>>>>>>>
>>>>>>>agreed
>>>>>>>
>>>>>>>>but hard if you want to use the same identifiers in every message.
>>>>>>>>The endpoints can easily figure this out, because they should know
>>>>>>>>their half, and the half that isn't theirs is the other end's. But
>>>>>>>>its not simple for middleboxes.
>>>>>>>
>>>>>>>remember that each half is a UUID or GUID, which will always be a
>>>>>>>unique value through space and time.
>>>>>>>
>>>>>>>
>>>>>>>>The solution that is used for dialog ids is to use To and From, but
>>>>>>>>they must be reassigned depending on the direction of the message.
>>>>>>>>We could do the same for session id, but only if they are remapped
>>>>>>>>based on the direction of the request.
>>>>>>>
>>>>>>>I guess I'm no getting why the halves need to switch places yet
>>>>>>>depending on whether it's in a request or response. Or are you
>>>>>>>saying that for one complete transaction they are in a certain
>>>>>>>order, but in a related transaction(s) they are possibly in the
>>>>>>>reverse order - depending on who sent the message?
>>>>>>
>>>>>>When a message is sent in the reverse direction from the dialog
>>>>>>establishing message, the From URI and To URI are reversed, as well
>>>>>>as the  From and To tags. If the session id still has its halves
>>>>>>tagged consistent with the from and to of the dialog establishing
>>>>>>request, then you will get confused about which half goes with which
>>>>>>end.
>>>>>>
>>>>>>There is no problem for servers that keep state and remember the
>>>>>>values for each end. For them we don't need to tag the halves at all.
>>>>>>
>>>>>>There is also no problem for those who don't *care* which end is
>>>>>>which.
>>>>>>And there may be a lot of those.
>>>>>>
>>>>>>This tagging is only there for those who don't keep state yet need to
>>>>>>know. Maybe there aren't any of those, in which case we can stop
>>>>>>worrying about it.
>>>>>>
>>>>>>I guess an example that might matter is something analyzing logs, and
>>>>>>doesn't have a complete set of logs available to it - in particular
>>>>>>it doesn't have a log of the initial signaling that set up the
>>>>>>session, so it can't figure out which half-id belongs to which end.
>>>>>>
>>>>>>Then it sees a change - it sees a message where half of the id
>>>>>>matches prior things, but the other half doesn't - is new. From this
>>>>>>it can perhaps infer that there was a transfer. And in that case it
>>>>>>will want to know which end remains and which was replaced. But it
>>>>>>can't figure that out from which half of the id changed without
>>>>>>knowing the mapping from half to end.
>>>>>>
>>>>>>But I will be the first to say that this case is somewhat implausible.
>>>>>>In practice there will be lots of stuff in the messages being
>>>>>>analyzed that should support figuring this out. Perhaps this just
>>>>>>isn't a good example, and there is another that is better. But I
>>>>>>don't know a better one. Anybody else? (I think Paul J was the one
>>>>>>who raised this concern, so maybe he has an example.)
>>>>>>
>>>>>>If we can't find a plausible reason why we need to do this mapping,
>>>>>>then I propose that we just not bother. In that case I think
>>>>>>representation
>>>>>>#3 is attractive. It provides for the easiest comparison between id
>>>>>>values
>>>>>>- a single string comparison is sufficient. And its among the most
>>>>>>compact representations. I'd recommend:
>>>>>>
>>>>>>         session-id: SmallestHalf:BiggestHalf
>>>>>>
>>>>>>Or just
>>>>>>
>>>>>>         session-id: FirstHalf
>>>>>>
>>>>>>before the half for the far end has been assigned.
>>>>>>
>>>>>>         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
>>>>_______________________________________________
>>>>siprec mailing list
>>>>[email-masked]
>>>>https://www.ietf.org/mailman/listinfo/siprec
>>>
>>>_______________________________________________
>>>siprec mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/siprec
>>
>>
>>_______________________________________________
>>siprec mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/siprec
>
>_______________________________________________
>siprec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Aug 2012 19:09:05 -0700

On 8/2/12 6:38 PM, James Polk wrote:
> discussions for weeks to use hex, and that's the proposal on the table
> there, so I would suggest not making any decisions in SIPREC based on
> INSIPID using base64 - because that's not a sure thing at all at this
> point.

We had a discussion of this in the siprec meeting today.
There was violent objection from Joe Hildebrand and Hadriel not to do 
this because it would make it harder to use standard libraries to do the 
encode/decode.

I'm not an XML guy, so I guess I'll defer to them on that part, though 
it seems trivial to me to append "==" before calling the decoder and 
strip the "==" after calling the encoder. But if the conversions are 
automatic based on the declared typing in the schema then I guess I can 
see why it might be harder than that.

At the end of the day I don't really care. So I'll defer to someone who 
does.

	Thanks,
	Paul

>> I don't have strong feelings either way. Just understand that omitting
>> the "==" locks us in to 64 bit values. That doesn't seem to be a big
>> constraint, since the spec we're referencing for the value calls for
>> 64 bits.
>>
>> Thanks,
>> Paul
>>

---

From: James Polk <[email-masked]>
Date: Fri, 03 Aug 2012 01:51:24 -0500

At 09:09 PM 8/2/2012, Paul Kyzivat wrote:
>We had a discussion of this in the siprec meeting today. There was 
>violent objection from Joe Hildebrand and Hadriel not to do this

Paul - which do you mean when you say "this"?

IOW, were Joe and Hadriel violently against base64 or hex?

Hadriel was in INSIPID when I mentioned the UUID is a RFC 4122 
defined 32 byte hex value, and he didn't leap out of his chair to 
jump my (you know what), but I don't want to assume which way he 
agrees with or disagrees with.

James

>because it would make it harder to use standard libraries to do the 
>encode/decode.
>
>I'm not an XML guy, so I guess I'll defer to them on that part, 
>though it seems trivial to me to append "==" before calling the 
>decoder and strip the "==" after calling the encoder. But if the 
>conversions are automatic based on the declared typing in the schema 
>then I guess I can see why it might be harder than that.
>
>At the end of the day I don't really care. So I'll defer to someone who does.
>
>         Thanks,
>         Paul
>
>>James
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Aug 2012 00:01:38 -0700

> Paul - which do you mean when you say "this"?

They were opposed to using base64 with the "==" stripped.
They were fine with using base64 with the "==" present.

	Thanks,
	Paul

> Hadriel was in INSIPID when I mentioned the UUID is a RFC 4122 defined
> 32 byte hex value, and he didn't leap out of his chair to jump my (you
> know what), but I don't want to assume which way he agrees with or
> disagrees with.
>
> James
>
>> automatic based on the declared typing in the schema then I guess I
>> can see why it might be harder than that.
>>