Subject: [dispatch] Revised Session-ID Charter (proposal)

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 13 Nov 2011 00:19:51 -0500

Folks,

We've tossed around a charter a few times.  The one at the last meeting
appeared to receive good consensus.  Sal and I made significant changes and
sent that to the list earlier, but that was met with criticism since it was
too much of a departure from the original charter.

Sal and I then went back to the original charter text presented at the last
meeting and made only very minor edits.  Tonight, I took the liberty of
introducing a few minor changes.  One change was to add to the requirements
and use cases document a definition of the word "session."  I think that is
what Dale was suggesting we do.

In any case, I will not be at the meeting to debate the charter, but I want
to put something out on the list to see if we can get some general
agreement.  I'm happy to revise it in whatever way the group wishes and
would definitely welcome any text from those who feel passionate about it.

Paul

---------------------------------------

End-to-end Session Identifier in SIP (charter proposal)

The end-to-end Session Identifier in SIP-based multimedia communication
networks refers to the ability for endpoints, intermediate devices, and
management and monitoring system to identify and correlate SIP messages and
dialogs of the same higher-level end-to-end "communication session" across
multiple SIP devices, hops, and administrative domains.

Unfortunately, there are a number of factors that contribute to the fact
that the current dialog identifiers defined in SIP is not suitable for
end-to-end session identification. Perhaps the most important factor worth
describing is that in real-world deployments Back-to-Back User Agents
(B2BUAs) devices like Session Border Controllers (SBC) often change the call
identifiers (e.g., the From-tag and To-tag that are used in conjunction with
the Call-ID header to make the dialog-id) as the session signaling passes
through.

An end-to-end Session Identifier should allow the possibility to identify
the communication session from the point of origin, passing through any
number of intermediaries, to the ultimate point of termination. It should
have the same aim as the From-tag, To-tag and Call-ID conjunction, but
should not be mangled by intermediaries.  Consideration must be given to the
fact that the entities involved in a communication session might change as a
result of service interaction in the network, such as call transfers, joins,
etc. 

A SIP end-to-end Session Identifier has been considered as possible solution
of different use cases like troubleshooting, billing, session tracking,
session recording, media and signaling correlation, and so forth.  Some of
these requirements have also been identified and come directly from other
Existing working group within the RAI area (e.g. SIPRec, Splices).

Moreover, other standards organizations have identified the need for SIP and
H.323 to carry the same "session ID" value(s) so that it is possible
identify a call end-to end even when performing interworking between
protocols.

The working group will produce the following deliverables:

1. A requirement and use case document with key consideration for SIP
Session End-to-End Identification, including the definition of a "session"

2. Specification of new end-to-end Session Identifier mechanism

Goal and Milestone:

August 2012 - Requirement and use case document sent to the IESG
(Informational)

March 2013 - Specification of the new mechanism sent to the IESG (PS)

---

From: Michael Hammer <[email-masked]>
Date: Mon, 14 Nov 2011 10:24:25 -0500

Paul,

I am wondering if the term "session" is so encumbered with baggage, that
the group might better to consider an alternative name that gets to the
essence of what you are looking for, without linking to session as defined
by SIP.

Something like:  Bidirectional path completion ID

Although that is clearly too long, I hope the idea is clear.  One may not
care how many sessions it took to get there; you may just want to know
which one actually completed.

Such a parameter could be offered by each potential termination point of
the multitude of sessions, but only one actually completes.
Just a thought.  Accept or reject as you see fit.  I won't be there to
discuss.

Good luck,
Mike

On Sun, Nov 13, 2011 at 12:19 AM, Paul E. Jones <[email-masked]>wrote:

> Folks,****
>
> ** **
>
> We’ve tossed around a charter a few times.  The one at the last meeting
> too much of a departure from the original charter.****
>
> ** **
>
> Sal and I then went back to the original charter text presented at the
> last meeting and made only very minor edits.  Tonight, I took the liberty
> of introducing a few minor changes.  One change was to add to the
> requirements and use cases document a definition of the word “session.”  I
> think that is what Dale was suggesting we do.****
>
> ** **
>
> In any case, I will not be at the meeting to debate the charter, but I
> want to put something out on the list to see if we can get some general
> agreement.  I’m happy to revise it in whatever way the group wishes and
> ****
> ** **
> Paul****
> ** **
> ---------------------------------------****
>
> ** **
>
> End-to-end Session Identifier in SIP (charter proposal)****
>
> ** **
>
> multiple SIP devices, hops, and administrative domains.****
>
> ** **
>
> (B2BUAs) devices like Session Border Controllers (SBC) often change the
> call identifiers (e.g., the From-tag and To-tag that are used in
> conjunction with the Call-ID header to make the dialog-id) as the session
> signaling passes through.****
>
> ** **
>
> should not be mangled by intermediaries.  Consideration must be given to
> the fact that the entities involved in a communication session might change
> as a result of service interaction in the network, such as call transfers,
> joins, etc. ****
>
> ** **
>
> A SIP end-to-end Session Identifier has been considered as possible
> solution of different use cases like troubleshooting, billing, session
> tracking, session recording, media and signaling correlation, and so
> forth.  Some of these requirements have also been identified and come
> directly from other Existing working group within the RAI area (e.g.
> SIPRec, Splices).****
>
> ** **
>
> Moreover, other standards organizations have identified the need for SIP
> and H.323 to carry the same "session ID" value(s) so that it is possible
> protocols.****
> ** **
> The working group will produce the following deliverables:****
>
> ** **
>
> ****
> ** **
> 2. Specification of new end-to-end Session Identifier mechanism****
>
> ** **
>
> Goal and Milestone:****
>
> ** **
>
> (Informational)****
> ** **
> March 2013 - Specification of the new mechanism sent to the IESG (PS)****
>
> ** **
>
> ** **
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 14 Nov 2011 10:57:32 -0500

Mike,

Session is definitely encumbered with baggage, but not only from SIP and
SDP.  It does make it a challenge, but I really have no preference for what
we call this thing.  I believe SIPREC defined "communication session".  I
think "session" is probably the most fitting, but perhaps an adjective to go
with it?

Anyway, I'm not there, either.  I do hope there is some discussion and
agreement.  We could work out what we call it as we progress the work.

Paul

From: Michael Hammer [mailto:[email-masked]] 
Sent: Monday, November 14, 2011 10:24 AM
To: Paul E. Jones
Cc: [email-masked]
Subject: Re: [dispatch] Revised Session-ID Charter (proposal)

Paul,

I am wondering if the term "session" is so encumbered with baggage, that the
group might better to consider an alternative name that gets to the essence
of what you are looking for, without linking to session as defined by SIP.

Although that is clearly too long, I hope the idea is clear.  One may not
care how many sessions it took to get there; you may just want to know which
one actually completed.

Such a parameter could be offered by each potential termination point of the
multitude of sessions, but only one actually completes.

Good luck,

Mike

On Sun, Nov 13, 2011 at 12:19 AM, Paul E. Jones <[email-masked]>
wrote:

Folks,

Paul

Goal and Milestone:

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 14 Nov 2011 13:54:19 -0500

> From: Michael Hammer [[email-masked]]
> 
> I am wondering if the term "session" is so encumbered with baggage,
> that the group might better to consider an alternative name that gets
> to the essence of what you are looking for, without linking to session
> as defined by SIP.

I agree.  What has saved us so far is that in no single conversation
do we use "session" to mean the media session described by SDP and
also the session we are proposing to define.

Not that I have a good suggestion.  Connection?  Nexus?  Syzygy?

Dale