Subject: Re: [Insipid] Pre-WGLC INSIPID Session-ID Review Comments

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 05 Aug 2014 21:55:03 +0000

Adam, et al,

First, let me thank you and the others who have provided invaluable 
input on the draft.  I haven't yet incorporated all of the proposed 
textual changes, but I am collecting all of the input and will be making 
the revisions in the next couple of weeks (I hope).

Anyway, I wanted to comment now on one:

>---
>7. Processing by Intermediaries
>
>"When intermediaries transmits a 100 (Trying) provisional responseand 
>when
>the UUID of the destination UA is unknown, the intermediary MUST place 
>the
>one known UUID in the "remote-uuid" field and set the "local-uuid" 
>field
>to the null UUID value. When an intermediary transmits any other
>provisional response and when the UUID of the destination UA is 
>unknown,
>the intermediary MUST place the one known UUID in the "remote-uuid" 
>field
>and MAY set the "local-uuid" field to a locally created UUID value or 
>the
>null UUID value.
>
>Comment: What's the rational behind the difference in behavior between 
>the
>100 and other 1xx responses?
>---

This item was brought up to me today off-list, so this is at least the 
second time it was raised.  Initially, we had text that said that all 
provisional responses would have a null UUID if one of the UUID values 
is not known.  However, that was changed to what we have now since there 
were cases where that wasn't ideal.  Arguably there are cases here this 
exception is not ideal.

What I think might be best is to remove that first sentence and apply 
the same behavior on intermediaries for all provisional responses.  That 
means the intermediary might use "null" or might fabricate a UUID if it 
doesn't know the UUID of the destination endpoint for 100 or any 
provisional response.

So unless there is objection, that's the direction I'll go with this 
one.

Paul

---

From: <[email-masked]>
Date: Wed, 6 Aug 2014 11:52:22 +0200

Hi Paul,
So if I understand you correctly we will then have for each 100 Trying a own local uuid included.
Looking on the practical approach in O&M I would be confused about too many different local uuid used in one SIP call.

So a call that will have 10 hops will have the sess-id  for INVITE (A,null) for all 100 Trying (Hop-1,A), (Hop-2,A).... (Hop-10,A)and for the UAS (B,A), For 180 (B,A) ect.

So all the nice UUIDs have to be created by the proxies and have to be solved by the network monitoring system.
For O&M reasons I see there no value add on.
I would prefer to use the Null uuid in the local-uuid for the 100 Trying.

The only use case where I think it could be worth to include a local uuid instead of the null uuid would be a 181 by a forwarding server.

Thank you and Best Regards

Roland
-----Ursprüngliche Nachricht-----
Von: insipid [mailto:[email-masked]] Im Auftrag von Paul E. Jones
Gesendet: Dienstag, 5. August 2014 23:55
An: Adam Gensler (agensler); [email-masked]
Betreff: Re: [Insipid] Pre-WGLC INSIPID Session-ID Review Comments

Adam, et al,

First, let me thank you and the others who have provided invaluable input on the draft.  I haven't yet incorporated all of the proposed textual changes, but I am collecting all of the input and will be making the revisions in the next couple of weeks (I hope).

Anyway, I wanted to comment now on one:

>when the UUID of the destination UA is unknown, the intermediary MUST 
>place the one known UUID in the "remote-uuid" field and set the 
>"local-uuid"
>field
>unknown, the intermediary MUST place the one known UUID in the 
>"remote-uuid"
>field
>the null UUID value.
>the 100 and other 1xx responses?
>---

This item was brought up to me today off-list, so this is at least the second time it was raised.  Initially, we had text that said that all provisional responses would have a null UUID if one of the UUID values is not known.  However, that was changed to what we have now since there were cases where that wasn't ideal.  Arguably there are cases here this exception is not ideal.

What I think might be best is to remove that first sentence and apply the same behavior on intermediaries for all provisional responses.  That means the intermediary might use "null" or might fabricate a UUID if it doesn't know the UUID of the destination endpoint for 100 or any provisional response.

So unless there is objection, that's the direction I'll go with this one.

Paul

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 06 Aug 2014 08:53:27 -0400

Roland,

The change would not require intermediaries to use a non-null value. The intent is to change the language to say that they may use non-null values.  This is the language we have for all other 1xx messages.

Your point is valid and the examples will still show use of null. However, the desire was expressed to have all provisional messages work the same way.

Paul

-------- Original Message --------
From: [email-masked]
Sent: August 6, 2014 5:52:22 AM EDT
To: [email-masked], [email-masked], [email-masked]
Subject: AW: [Insipid] Pre-WGLC INSIPID Session-ID Review Comments

Hi Paul,

Roland
-----Ursprüngliche Nachricht-----
Von: insipid [mailto:[email-masked]] Im Auftrag von Paul E. Jones
Gesendet: Dienstag, 5. August 2014 23:55
An: Adam Gensler (agensler); [email-masked]
Betreff: Re: [Insipid] Pre-WGLC INSIPID Session-ID Review Comments

Adam, et al,

Paul

---

From: "Adam Gensler (agensler)" <[email-masked]>
Date: Thu, 7 Aug 2014 19:52:10 +0000

Paul,

That approach sounds good to me.

Best regards,
Adam

On Aug 5, 2014, at 5:55 PM, Paul E. Jones <[email-masked]> wrote:

>> "When intermediaries transmits a 100 (Trying) provisional responseand when
>> the UUID of the destination UA is unknown, the intermediary MUST place the
>> one known UUID in the "remote-uuid" field and set the "local-uuid" field
>> provisional response and when the UUID of the destination UA is unknown,
>> the intermediary MUST place the one known UUID in the "remote-uuid" field
>> and MAY set the "local-uuid" field to a locally created UUID value or the
>> null UUID value.
>> 
>> Comment: What's the rational behind the difference in behavior between the