Subject: Re: [Insipid] 3.X. End-to-end identification of a communication session: evaluation

From: Brett Tate <[email-masked]>
Date: Wed, 5 Sep 2012 11:37:20 +0000

> 3.X. End-to-end identification of a communication session:
> 
> SIP messaging that either does not involve SIP servers 
> or only involves SIP proxies, the Call-ID: header value 
> sufficiently identifies each SIP message within a 
> transaction or dialog. This is not the case when either 
> B2BUAs or SBCs are in the signaling path between UAs. 
> Therefore, we need the ability to identify each
> communication session per transaction through a single 
> SIP header-value regardless of which type of SIP servers 
> are in the signaling path between UAs. For transactions 
> that create a dialog, have each message within the same 
> dialog MUST use the same identifier.

If this item is added, I recommend that the last sentence be changed since it appears to conflict with other requirements to allow the identifier to change if the "end" changes.  The following is an alternative to the last sentence; it is intentionally vague to allow the endpoint (B2BUA or otherwise) to change the identifier when deemed appropriate.  

"Concerning transactions that create a dialog, each message within the same dialog MUST use the same identifier unless the endpoint changes."

Thanks,
Brett

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Sep 2012 10:35:09 -0400

> "Concerning transactions that create a dialog, each message within the same dialog MUST use the same identifier unless the endpoint changes."

The text as it was written is already weasle worded. It talks about 
*dialogs*. But when there are B2BUA middle boxes then there is not one 
dialog E2E. With one B2BUA there are two dialogs, etc. The use of 
*transaction* is even more dubious, since even proxies terminate a 
transaction and start another on the other side. (As the text was 
written, the call-id meets the requirement.)

I think that the last sentence should have been written as:

"For requests that create an end-to-end communication session, each 
message withing the end-to-end communication session MUST use the same 
identifier."

And then I guess it is *that* which you propose to weaken. Perhaps to:

"For requests that create an end-to-end communication session, each 
message withing the end-to-end communication session MUST use the same 
identifier as long as the endpoints remain unchanged."

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 14 Sep 2012 16:28:27 -0400

So, where are we on this one?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Wednesday, September 05, 2012 10:35 AM
> To: [email-masked]
> Subject: Re: [Insipid] 3.X. End-to-end identification of a communication
> session: evaluation
> 
> >> SIP messaging that either does not involve SIP servers or only
> >> involves SIP proxies, the Call-ID: header value sufficiently
> >> identifies each SIP message within a transaction or dialog. This is
> >> not the case when either B2BUAs or SBCs are in the signaling path
> >> between UAs.
> >> Therefore, we need the ability to identify each communication session
> >> per transaction through a single SIP header-value regardless of which
> >> type of SIP servers are in the signaling path between UAs. For
> >> transactions that create a dialog, have each message within the same
> > If this item is added, I recommend that the last sentence be changed
> since it appears to conflict with other requirements to allow the
> identifier to change if the "end" changes.  The following is an
> alternative to the last sentence; it is intentionally vague to allow the
> endpoint (B2BUA or otherwise) to change the identifier when deemed
> appropriate.
> >
> > "Concerning transactions that create a dialog, each message within the
> same dialog MUST use the same identifier unless the endpoint changes."
> 
> transaction and start another on the other side. (As the text was written,
> the call-id meets the requirement.)
> 
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid