Subject: [dispatch] new charter version for Session-id

From: Salvatore Loreto <[email-masked]>
Date: Fri, 7 Oct 2011 15:50:10 +0300

Hi,

in Quebec we got a strong consensus on moving the Session-ID work forward,
but in order to do so we have been asked
to work on improving the charter so to make more clear and focused the 
aim of the mini-working group.

Together with all the proponents of the initial charter [1] we have 
worked on it
and we hope it now satisfy all the concerns we listened as well as all 
the questions/feedback we got
during the Quebec presentation.
(the charter is below)

comments and feedback are really welcome

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

[1] http://www.ietf.org/mail-archive/web/dispatch/current/msg03647.html
_

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

The end-to-end Session Identifier in SIP-based multimedia communication 
networks refers to the ability for endpoints, intermediary devices, 
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 and hops.

Unfortunately, there are a number of factors that contribute to the fact 
that the current dialog identifiers defined in SIP are not suitable for 
end-to-end session identification.Perhaps the most important factor 
worth describing is that in real-world deployments devices like 
Back-to-Back User Agents (B2BUAs) 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 aims to identify a Dialog (as defined 
in RFC 3261 Section 5), but does so in such a way as to overcome the 
limitations of the present means of Dialog identification.The Session 
Identifier allows for the possibility of uniquely identifying the 
communication session from the originating endpoint, passing through any 
number of intermediaries, to the terminating endpoint. The Session 
Identifier will address issues related to transferring or forwarding of 
sessions, as well as changes during mid-call of either of the endpoints 
by an intermediary (e.g., "joining" two calls at a B2BUA).

As for Dialogs, an end-to-end Session Identifier should be "created 
through the generation of non-failure responses to requests with 
specific methods" (RFC 3261 Section 12.1).That said, the end-to-end 
Session Identifier may change if an endpoint receives an INVITE or other 
request indicating through some means that the remote endpoint has 
changed.This may occur, for example, when a B2BUA performs a call "join" 
or otherwise re-routes one end of the communication session.Taking note 
of such changes is important to ensure a new end-to-end Session 
Identifier can be constructed.

Further, the Session Identifier must be constructed so that it may be 
used by other session control protocols, such as H.323 or XMPP, to 
improve interworking between protocols.The ITU-T has identified a need 
for an end-to-end session Identifier and is progressing work to be 
aligned with the output of this Working Group.

The end-to-end Session Identifier has been considered as possible 
solution to different use cases like media and signaling correlation, 
session tracking, troubleshooting, billing, session recording, 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 and Splices). The requirements document shall deliver the 
possible scenarios where the Session Identifier would be used.

This group will first focus on a document that will identify, collect 
and discuss all the requirements and use cases. Once the needs are clear 
and identified, the working group will specify the end-to-end Session 
Identifier mechanism.

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

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

Goal and Milestone:

March 2012 - Requirement and use case document sent to the IESG 
(Information)

November 2012 -- Specification of the new mechanism sent to the IESG

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 07 Oct 2011 08:27:46 -0500

On 10/07/2011 07:50 AM, Salvatore Loreto wrote:
> in Quebec we got a strong consensus on moving the Session-ID work
> forward, but in order to do so we have been asked to work on
> improving the charter so to make more clear and focused the aim of
> the mini-working group.
>
> worked on it and we hope it now satisfy all the concerns we listened
> as well as all the questions/feedback we got during the Quebec
> presentation. (the charter is below)
>

Sal: Charter reads good.

One minor question --- in the first paragraph it is stated that the e2e
session identifier can be used to "identify and correlate SIP messages
and dialogs of the same higher-level end-to-end "communication session"
across multiple SIP devices and hops."

Any specific reason why the latter part of the sentence does not read
as "... across multiple SIP devices, hops, and administrative domains."?

IIRC, when we were having the session identifier discussions in SIPCLF,
one of the motivating factors that came up was the continued tracing
of a SIP call based on such an identifier when the session leaves
one administrative domain and enters another.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 7 Oct 2011 16:34:34 +0300

> as "... across multiple SIP devices, hops, and administrative domains."?

that is a good point, I thought was implicit
but you are right that should be stated clearly in that sentence.
I am be happy to include explicitly "and administrative domains" in the 
next update

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 7 Oct 2011 08:51:52 -0600

With my chair hat on. 

This charter is completely out of line with what we had consensus on at the last meeting - I am shocked to see it go and add in so many of the things which people clearly objected to on provisos discussions of this. 

I encourage you to read the charter you proposed in your slides at IETF 81, read the minutes from the meetings, then give some thought to how you like to move this work forward. 

As chair, I would like to formally state there is no consensus for a charter such as the one below. There was consensus for a the charter presented at IETF 81. 

Cullen <Dispatch co-chair>

On Oct 7, 2011, at 6:50 AM, Salvatore Loreto wrote:

> to work on improving the charter so to make more clear and focused the aim of the mini-working group.
> 
> Together with all the proponents of the initial charter [1] we have worked on it
> and we hope it now satisfy all the concerns we listened as well as all the questions/feedback we got
> End-to-end Session Identifier in SIP (NEW charter proposal)
> The end-to-end Session Identifier in SIP-based multimedia communication networks refers to the ability for endpoints, intermediary devices, 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 and hops.
> 
> Unfortunately, there are a number of factors that contribute to the fact that the current dialog identifiers defined in SIP are not suitable for end-to-end session identification.  Perhaps the most important factor worth describing is that in real-world deployments devices like Back-to-Back User Agents (B2BUAs) 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 aims to identify a Dialog (as defined in RFC 3261 Section 5), but does so in such a way as to overcome the limitations of the present means of Dialog identification.  The Session Identifier allows for the possibility of uniquely identifying the communication session from the originating endpoint, passing through any number of intermediaries, to the terminating endpoint.  The Session Identifier will address issues related to transferring or forwarding of sessions, as well as changes during mid-call of either of the endpoints by an intermediary (e.g., “joining” two calls at a B2BUA).
> 
> As for Dialogs, an end-to-end Session Identifier should be “created through the generation of non-failure responses to requests with specific methods” (RFC 3261 Section 12.1).  That said, the end-to-end Session Identifier may change if an endpoint receives an INVITE or other request indicating through some means that the remote endpoint has changed.  This may occur, for example, when a B2BUA performs a call “join” or otherwise re-routes one end of the communication session.  Taking note of such changes is important to ensure a new end-to-end Session Identifier can be constructed.
> 
> Further, the Session Identifier must be constructed so that it may be used by other session control protocols, such as H.323 or XMPP, to improve interworking between protocols.  The ITU-T has identified a need for an end-to-end session Identifier and is progressing work to be aligned with the output of this Working Group.
> 
> The end-to-end Session Identifier has been considered as possible solution to different use cases like media and signaling correlation, session tracking, troubleshooting, billing, session recording, 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 and Splices).  The requirements document shall deliver the possible scenarios where the Session Identifier would be used.
> 
> This group will first focus on a document that will identify, collect and discuss all the requirements and use cases. Once the needs are clear and identified, the working group will specify the end-to-end Session Identifier mechanism.
> 
> 1. A requirement and use case document with key consideration for SIP Session End-to-End Identification
> 
> March 2012 - Requirement and use case document sent to the IESG (Information)
> 
> November 2012 – Specification of the new mechanism sent to the IESG
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Oct 2011 11:05:22 -0400

I like this charter.

Given the diversity of aspirations, I fear it will be difficult to find 
a single solution. But neither am I fond of introducing multiple 
mechanisms. But I remain open minded that after digging in to this it 
will be possible to come up with something useful.

	Thanks,
	Paul

> by an intermediary (e.g., “joining” two calls at a B2BUA).
>
> As for Dialogs, an end-to-end Session Identifier should be “created
> specific methods” (RFC 3261 Section 12.1).That said, the end-to-end
> changed.This may occur, for example, when a B2BUA performs a call “join”
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Adam Roach <[email-masked]>
Date: Fri, 07 Oct 2011 10:35:30 -0500

To aid in the discussion, I've attached a file that highlights the diffs 
between the charter we talked about in Quebec and the one Salvatore sent 
out today.

Cullen: can you point to the changes that you believe contravene the 
consensus in the room?

On a separate note, the charter remains silent on whether calls 
involving three or more parties are in scope. The current text is 
schizophrenic on the topic. In places, it strongly implies a model of 
one originating endpoint, multiple intermediaries, and one terminating 
endpoint. In others, it discusses the use of the "join" primitive, which 
implies conferencing.

Regardless of intention, whether conference calls are in scope need to 
be explicitly stated in the charter rather than merely being implied. 
What I heard in Quebec was as assertion that the work would be 
addressing the two-party situation, rather than the (possibly 
intractable) general problem of conferencing.

/a

On 10/7/11 9:51 AM, Cullen Jennings wrote:
> Cullen<Dispatch co-chair>
>

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 7 Oct 2011 19:30:13 +0300

> intractable) general problem of conferencing.
the work we have done on the charter is to focus it to address only the 
two-party situation...
I agree that the example involving "join" is quite misleading we should 
clarify it or remove the related
text, so the make the charter less schizophrenic.

We can state more explicitly that it focus exclusively on the two-party 
scenario

cheers
/Sal

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 07 Oct 2011 14:45:20 -0500

At 10:35 AM 10/7/2011, Adam Roach wrote:

>To aid in the discussion, I've attached a file 
>that highlights the diffs between the charter we 
>talked about in Quebec and the one Salvatore sent out today.

Adam - and remember, the 81 charter severely 
deviated from the presentation of the slides - or 
the slides the presenter was given by "the group 
working on this" at the time, so I'm not sure 
which way this effort is going now (spoken as the 
loudest/firmest voice at the mic in Quebec).

>Cullen: can you point to the changes that you 
>believe contravene the consensus in the room?
>
>On a separate note, the charter remains silent 
>on whether calls involving three or more parties 
>are in scope. The current text is schizophrenic 
>on the topic. In places, it strongly implies a 
>model of one originating endpoint, multiple 
>intermediaries, and one terminating endpoint. In 
>others, it discusses the use of the "join" 
>primitive, which implies conferencing.
>
>Regardless of intention, whether conference 
>calls are in scope need to be explicitly stated 
>in the charter rather than merely being implied.

Clearly this is a mistake and needs to be called 
out explicitly, and I would prefer a goal (but 
not a mandatory solution containing) of 
addressing conferencing. In other words, if we 
come up with a solution that can address 
conferencing, include it - but don't hold the 
work back because we can't solve for conferencing.

James

>What I heard in Quebec was as assertion that the 
>work would be addressing the two-party 
>situation, rather than the (possibly 
>>This charter is completely out of line with 
>>what we had consensus on at the last meeting - 
>>I am shocked to see it go and add in so many of 
>>the things which people clearly objected to on provisos discussions of this.
>>
>>I encourage you to read the charter you 
>>proposed in your slides at IETF 81, read the 
>>minutes from the meetings, then give some 
>>thought to how you like to move this work forward.
>>
>>As chair, I would like to formally state there 
>>is no consensus for a charter such as the one 
>>below. There was consensus for a the charter presented at IETF 81.
>>
>>>to work on improving the charter so to make 
>>>more clear and focused the aim of the mini-working group.
>>>
>>>and we hope it now satisfy all the concerns we 
>>>listened as well as all the questions/feedback we got
>>>The end-to-end Session Identifier in SIP-based 
>>>multimedia communication networks refers to 
>>>the ability for endpoints, intermediary 
>>>devices, 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 and hops.
>>>
>>>Unfortunately, there are a number of factors 
>>>that contribute to the fact that the current 
>>>dialog identifiers defined in SIP are not 
>>>suitable for end-to-end session 
>>>identification.  Perhaps the most important 
>>>factor worth describing is that in real-world 
>>>deployments devices like Back-to-Back User 
>>>Agents (B2BUAs) 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 aims to 
>>>identify a Dialog (as defined in RFC 3261 
>>>Section 5), but does so in such a way as to 
>>>overcome the limitations of the present means 
>>>of Dialog identification.  The Session 
>>>Identifier allows for the possibility of 
>>>uniquely identifying the communication session 
>>>from the originating endpoint, passing through 
>>>any number of intermediaries, to the 
>>>terminating endpoint.  The Session Identifier 
>>>will address issues related to transferring or 
>>>forwarding of sessions, as well as changes 
>>>during mid-call of either of the endpoints by 
>>>an intermediary (e.g., “joining” two calls at a B2BUA).
>>>
>>>As for Dialogs, an end-to-end Session 
>>>Identifier should be “created through the 
>>>generation of non-failure responses to 
>>>requests with specific methods” (RFC 3261 
>>>Section 12.1).  That said, the end-to-end 
>>>Session Identifier may change if an endpoint 
>>>receives an INVITE or other request indicating 
>>>through some means that the remote endpoint 
>>>has changed.  This may occur, for example, 
>>>when a B2BUA performs a call “join” or 
>>>otherwise re-routes one end of the 
>>>communication session.  Taking note of such 
>>>changes is important to ensure a new 
>>>end-to-end Session Identifier can be constructed.
>>>
>>>Further, the Session Identifier must be 
>>>constructed so that it may be used by other 
>>>session control protocols, such as H.323 or 
>>>XMPP, to improve interworking between 
>>>protocols.  The ITU-T has identified a need 
>>>for an end-to-end session Identifier and is 
>>>progressing work to be aligned with the output of this Working Group.
>>>
>>>The end-to-end Session Identifier has been 
>>>considered as possible solution to different 
>>>use cases like media and signaling 
>>>correlation, session tracking, 
>>>troubleshooting, billing, session recording, 
>>>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 and Splices).  The 
>>>requirements document shall deliver the 
>>>This group will first focus on a document that 
>>>will identify, collect and discuss all the 
>>>requirements and use cases. Once the needs are 
>>>clear and identified, the working group will 
>>>specify the end-to-end Session Identifier mechanism.
>>>
>>>1. A requirement and use case document with 
>>>key consideration for SIP Session End-to-End Identification
>>>
>>>November 2012  Specification of the new mechanism sent to the IESG
>>>