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

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: R.Jesske@telekom.de
Sent: August 6, 2014 5:52:22 AM EDT
To: paulej@packetizer.com, agensler@cisco.com, insipid@ietf.org
Subject: AW: [Insipid] Pre-WGLC INSIPID Session-ID Review Comments

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:insipid-bounces@ietf.org] Im Auftrag von Paul E. Jones
Gesendet: Dienstag, 5. August 2014 23:55
An: Adam Gensler (agensler); insipid@ietf.org
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:

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

_______________________________________________
insipid mailing list
insipid@ietf.org
https://www.ietf.org/mailman/listinfo/insipid