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

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 30 Jul 2012 17:13:58 +0000

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

---

From: Leon Portman <[email-masked]>
Date: Mon, 30 Jul 2012 20:14:56 +0300

I am OK

Leon
On Jul 30, 2012, at 8:13 PM, "Ravindran, Parthasarathi" <[email-masked]> wrote:

> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 31 Jul 2012 03:12:10 +0000

I am Ok too.

Ram

> On 30/07/12 10:44 PM, "Leon Portman" <[email-masked]> wrote:

>> 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>
>> 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
>> 
>> 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.
>> 
>> 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.)
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jul 2012 22:27:37 -0700

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