Re: [Insipid] Will the identifier pass unchanged through B2BUAs?

Hello All,
The question from Gonzalo was about REQ3:

REQ3: The solution must require that the identifier, if present, pass
unchanged through SIP B2BUAs or other intermediaries.

My interpretation was that 1) the solution document must contain the text "SIP B2BUAs or other intermediaries MUST NOT change the Session-ID header field value." and 2) no future drafts/RFCs are allowed to specify that a SIP B2BUA or intermediary may change the Session-ID header field value.

This is simplistic but I think it meets REQ3. The discussion on Gonzalo's question seems to me to be about a different requirement along the lines of "how the Session-ID header field is generated and used must be compared with generation and use of header fields that a SIP B2BUA or other intermediary removes or modifies to ensure that a SIP B2BUA or other intermediary does not have any reason to remove the Session-ID: header field."

Regards,
Peter

-----Original Message-----
From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Hadriel Kaplan
Sent: 31 July 2013 13:04
To: Paul Kyzivat
Cc: insipid@ietf.org
Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs?

On Jul 31, 2013, at 6:24 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> Well, the point of doing the work was to get an id that would survive e2e, in spite of b2buas, for use in *some* way or ways. If it is likely not to survive e2e, for whatever reason, then ISTM there is no point in progressing the work.

Sure there is: for the use-cases people have in mind.   Afaict, that's mostly around correlating multiple SIP dialogs of the same conference or 3PCC scenario, and applying policies on such matching cases.  Those use-cases don't actually need true, world-wide end-to-end survival.  They only need to survive through *some* B2BUAs, not all; and only in/across some domains, not all; and only in certain scenarios, not all.

The goal has never really been to simply "get an ID that would survive e2e" - it's been to get something we could use for some *purpose*.  I believe an e2e identifier would be quite useful for a troubleshooting purpose, and so long as it was used for only that then the odds of someone wanting to change it would be minimized.  But if people use it for other purposes, then each and every purpose it is used for expands the scenarios and likelihood in which someone would need to change it and no longer make it truly e2e.  That's *ok* - it just means it's not going to be as useful for troubleshooting as it could have been, is all.  It's not doom and gloom.

> The fact that you are only offering a "hunch" about survivability doesn't make it a strong justification for giving up on the work. We aren't likely to get any definitive answers. But maybe we can solicit opinions from those who might have influence over the survivability of the session id. Maybe we can ensure that it will survive if we promise not to use it for anything useful.

How can we promise not to use it for anything useful?  We already know some people want to use it for things that are useful *for them*.

-hadriel

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