dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf= .org] On Behalf = Of Robert = Sparks
Sent: Tuesday, November 08, 2011 = 1:42 PM
To: Salvatore = Loreto
Cc: dispatch@ietf.org
Subject: Re: [dispatch] new charter = version for Session-id

At least one major thread = in the conversation in quebec isn't included in the proposed changes = below.
As you consider the other = feedback you're receiving, please go back and look at (or better, listen = to)
the discussion around = whether "aims to identify a Dialog" is really what you are trying to do. = Given
the answers to some of = the questions in the earlier discussion, it's not a dialog (at least = it's not the thing
that has a = dialog identifier). Perhaps you could try different text at "aims to = identify a <?>".

Consider in particular the case of a call I have with a = B2BUA that starts off relaying my media to one = endpoint,
and then (for whatever = reason) shifts it to another. I heard folks say they want that whole = conversation to have
one session identifier, but there were 3 different = dialogs there.
On Oct 7, = 2011, at 7:50 AM, Salvatore Loreto wrote:

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] 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., =93joining=94 two calls at a = B2BUA).
As for Dialogs, an end-to-end Session Identifier = should be =93created through the generation of non-failure responses to = requests with specific methods=94 (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 =93join=94 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)

dispatch@ietf.org
To: "'Robert Sparks'" References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <034101cc9e4b$2124d6e0$636e84a0$@packetizer.com> <06D8F4C8-5CEA-4E16-9DCF-A43C96AAA292@nostrum.com> In-Reply-To: <06D8F4C8-5CEA-4E16-9DCF-A43C96AAA292@nostrum.com> Date: Tue, 8 Nov 2011 20:43:02 -0500 Message-ID: <03e001cc9e80$ecffa080$c6fee180$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03E1_01CC9E57.042C0980" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCoMG+cK7yKcacnsncXJq0HayNvgHe9BdiAFxedeMCCJ8V7ZQVn0VA Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 01:43:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03E1_01CC9E57.042C0980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Robert, A Session-ID is intended to be unique between any two communicating endpoints. So, if Alice makes a call and connects to Bob, there would be a Session-ID that is end-to-end unique between Alice and Bob. If an intermediary re-routes the call such that Alice is now in communication with Sue, then there would be a new unique Session-ID between Alice and Sue. Likewise, if Alice calls Bob, but there is a forking proxy that causes the call to be forked to 15 "Bobs", then there would be 15 Session-IDs, one for each pair of { Alice, Bob(i) }. The Session-ID is unique between any two communicating endpoints. An endpoint includes "terminal" devices, "MCU" devices, etc. It would not include SBCs, as those are intermediary devices, not terminating devices. I agree that wording this is a challenge, and I'm definitely open to input on appropriate wording. Paul From: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: Tuesday, November 08, 2011 4:24 PM To: Paul E. Jones Cc: 'Salvatore Loreto'; dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id On Nov 8, 2011, at 1:17 PM, Paul E. Jones wrote: Robert, What I would expect is that we identifier the session end-to-end from one endpoint to another endpoint. If that passes through one or more B2BUAs, that would still be a single communication session for the purposes of this work. We need to get that wording right, but I assume there agreement on identifying the communication session end-to-end across zero or more B2BUAs. Do folks agree? I can't agree because I can't tell yet what you mean by "the communication session". That's what I'm asking you to clarify. Your response indicates you are still focusing only on a model where one-dialog-into a B2BUA results in exactly one-dialog-out-of that B2BUA. The scenario I call out below does not fit in that model. Do you think there's one session identifier or two? If it's one, then it's not an identifier from one endpoint to another endpoint, its an identifier from one endpoint to one-or-more other endpoints. Paul From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Tuesday, November 08, 2011 1:42 PM To: Salvatore Loreto Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id At least one major thread in the conversation in quebec isn't included in the proposed changes below. As you consider the other feedback you're receiving, please go back and look at (or better, listen to) the discussion around whether "aims to identify a Dialog" is really what you are trying to do. Given the answers to some of the questions in the earlier discussion, it's not a dialog (at least it's not the thing that has a dialog identifier). Perhaps you could try different text at "aims to identify a ". Consider in particular the case of a call I have with a B2BUA that starts off relaying my media to one endpoint, and then (for whatever reason) shifts it to another. I heard folks say they want that whole conversation to have one session identifier, but there were 3 different dialogs there. RjS On Oct 7, 2011, at 7:50 AM, Salvatore Loreto wrote: 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 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_03E1_01CC9E57.042C0980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Robert,

A Session-ID is intended to be unique between any two communicating = endpoints. So, if Alice makes a call and connects to Bob, there = would be a Session-ID that is end-to-end unique between Alice and = Bob. If an intermediary re-routes the call such that Alice is now = in communication with Sue, then there would be a new unique Session-ID = between Alice and Sue. Likewise, if Alice calls Bob, but there is = a forking proxy that causes the call to be forked to 15 = “Bobs”, then there would be 15 Session-IDs, one for each = pair of { Alice, Bob(i) }. The Session-ID is unique between any = two communicating endpoints. An endpoint includes = “terminal” devices, “MCU” devices, etc. It = would not include SBCs, as those are intermediary devices, not = terminating devices.

I agree that wording this is a challenge, and I’m definitely = open to input on appropriate wording.

Paul

From:= = Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: Tuesday, = November 08, 2011 4:24 PM
To: Paul E. Jones
Cc: = 'Salvatore Loreto'; dispatch@ietf.org
Subject: Re: [dispatch] = new charter version for Session-id

On = Nov 8, 2011, at 1:17 PM, Paul E. Jones wrote:

Robert,

What I would expect is that we identifier the session end-to-end from = one endpoint to another endpoint. If that passes through one or = more B2BUAs, that would still be a single communication session for the = purposes of this work.

We need to get that wording right, but I assume there agreement on = identifying the communication session end-to-end across zero or more = B2BUAs. Do folks agree?

I = can't agree because I can't tell yet what you mean by "the = communication session". That's what I'm asking you to clarify. Your = response indicates you are still focusing only on a = model
where = one-dialog-into a B2BUA results in exactly one-dialog-out-of that = B2BUA.

The scenario I call out below does not fit in that = model. Do you think there's one session identifier or = two?
If it's one, = then it's not an identifier from one endpoint to another endpoint, its = an identifier from one endpoint to one-or-more other = endpoints.

Paul

From:= dispatch-bounces@ietf.org [mailto:dispatch-bounc= es@ietf.org] On = Behalf Of Robert = Sparks
Sent: Tuesday, November 08, 2011 = 1:42 PM
To: Salvatore = Loreto
Cc: dispatch@ietf.org
Subject: Re: [dispatch] new = charter version for = Session-id

At least one major thread in the conversation in = quebec isn't included in the proposed changes = below.
As you = consider the other feedback you're receiving, please go back and look at = (or better, listen to)
the discussion around whether "aims to identify a = Dialog" is really what you are trying to do. = Given
the = answers to some of the questions in the earlier discussion, it's not a = dialog (at least it's not the = thing
that has = a dialog identifier). Perhaps you could try different text at "aims = to identify a <?>".

Consider in particular the case of a call I have with = a B2BUA that starts off relaying my media to one = endpoint,
and = then (for whatever reason) shifts it to another. I heard folks say they = want that whole conversation to = have
one = session identifier, but there were 3 different dialogs = there.

RjS

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

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



_______________________________________________
disp= atch mailing list
dispatch@ietf.org
https://www.ietf.= org/mailman/listinfo/dispatch

------=_NextPart_000_03E1_01CC9E57.042C0980-- From rjsparks@nostrum.com Tue Nov 8 17:55:31 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E6F21F8A66 for ; Tue, 8 Nov 2011 17:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ErlXCQmJ+S7 for ; Tue, 8 Nov 2011 17:55:30 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD3E21F8A4B for ; Tue, 8 Nov 2011 17:55:30 -0800 (PST) Received: from [192.168.2.105] (pool-173-71-45-197.dllstx.fios.verizon.net [173.71.45.197]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pA91tQ8B072149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Nov 2011 19:55:26 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-15-1046626049 From: Robert Sparks In-Reply-To: <03e001cc9e80$ecffa080$c6fee180$@packetizer.com> Date: Tue, 8 Nov 2011 19:55:25 -0600 Message-Id: References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <034101cc9e4b$2124d6e0$636e84a0$@packetizer.com> <06D8F4C8-5CEA-4E16-9DCF-A43C96AAA292@nostrum.com> <03e001cc9e80$ecffa080$c6fee180$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 173.71.45.197 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 01:55:32 -0000 --Apple-Mail-15-1046626049 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 So, if I call Frobgnobitz and get connected to their b2bua, which sets = up a dialog to a media server to play me a message while I'm in the queue to talk to an agent, and then when an = agent comes available, that B2BUA sets up a second dialog and replumbs itself internally so I'm getting = media from the agent instead of from the media server (as far as my endpoint is concerned, it's only ever been in = one dialog), you're saying I have=20 two session IDs. I have heard others say it's only one. RjS On Nov 8, 2011, at 7:43 PM, Paul E. Jones wrote: > Robert, > =20 > A Session-ID is intended to be unique between any two communicating = endpoints. So, if Alice makes a call and connects to Bob, there would = be a Session-ID that is end-to-end unique between Alice and Bob. If an = intermediary re-routes the call such that Alice is now in communication = with Sue, then there would be a new unique Session-ID between Alice and = Sue. Likewise, if Alice calls Bob, but there is a forking proxy that = causes the call to be forked to 15 =93Bobs=94, then there would be 15 = Session-IDs, one for each pair of { Alice, Bob(i) }. The Session-ID is = unique between any two communicating endpoints. An endpoint includes = =93terminal=94 devices, =93MCU=94 devices, etc. It would not include = SBCs, as those are intermediary devices, not terminating devices. > =20 > I agree that wording this is a challenge, and I=92m definitely open to = input on appropriate wording. > =20 > Paul > =20 > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: Tuesday, November 08, 2011 4:24 PM > To: Paul E. Jones > Cc: 'Salvatore Loreto'; dispatch@ietf.org > Subject: Re: [dispatch] new charter version for Session-id > =20 > =20 > On Nov 8, 2011, at 1:17 PM, Paul E. Jones wrote: >=20 >=20 > Robert, > =20 > What I would expect is that we identifier the session end-to-end from = one endpoint to another endpoint. If that passes through one or more = B2BUAs, that would still be a single communication session for the = purposes of this work. > =20 > We need to get that wording right, but I assume there agreement on = identifying the communication session end-to-end across zero or more = B2BUAs. Do folks agree? > =20 > I can't agree because I can't tell yet what you mean by "the = communication session". That's what I'm asking you to clarify. Your = response indicates you are still focusing only on a model > where one-dialog-into a B2BUA results in exactly one-dialog-out-of = that B2BUA. > =20 > The scenario I call out below does not fit in that model. Do you think = there's one session identifier or two?=20 > If it's one, then it's not an identifier from one endpoint to another = endpoint, its an identifier from one endpoint to one-or-more other = endpoints. > =20 > =20 > =20 > Paul > =20 > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Robert Sparks > Sent: Tuesday, November 08, 2011 1:42 PM > To: Salvatore Loreto > Cc: dispatch@ietf.org > Subject: Re: [dispatch] new charter version for Session-id > =20 > At least one major thread in the conversation in quebec isn't included = in the proposed changes below. > As you consider the other feedback you're receiving, please go back = and look at (or better, listen to) > the discussion around whether "aims to identify a Dialog" is really = what you are trying to do. Given > the answers to some of the questions in the earlier discussion, it's = not a dialog (at least it's not the thing > that has a dialog identifier). Perhaps you could try different text at = "aims to identify a ". > =20 > Consider in particular the case of a call I have with a B2BUA that = starts off relaying my media to one endpoint, > and then (for whatever reason) shifts it to another. I heard folks say = they want that whole conversation to have=20 > one session identifier, but there were 3 different dialogs there. > =20 > RjS > =20 > On Oct 7, 2011, at 7:50 AM, Salvatore Loreto wrote: >=20 >=20 >=20 > Hi, >=20 > 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. >=20 > 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) >=20 > comments and feedback are really welcome >=20 > cheers > /Sal >=20 >=20 > --=20 > Salvatore Loreto > www.sloreto.com > [1] = http://www.ietf.org/mail-archive/web/dispatch/current/msg03647.html >=20 >=20 >=20 > 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., =93joining=94 two calls at a B2BUA). > As for Dialogs, an end-to-end Session Identifier should be =93created = through the generation of non-failure responses to requests with = specific methods=94 (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 = =93join=94 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 =96 Specification of the new mechanism sent to the IESG >=20 > =20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > =20 > =20 --Apple-Mail-15-1046626049 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 So, if I call Frobgnobitz and get connected = to their b2bua, which sets up a dialog to a media server to play = me
a message while I'm in the queue to talk to an agent, and then = when an agent comes available, that B2BUA
sets up a second = dialog and replumbs itself internally so I'm getting media from the = agent instead of from the
media server (as far as my endpoint = is concerned, it's only ever been in one dialog),  you're = saying I have
two session = IDs.

I have heard others say it's only = one.

RjS

On Nov 8, = 2011, at 7:43 PM, Paul E. Jones wrote:

A = Session-ID is intended to be unique between any two communicating = endpoints. So, if Alice makes a call and connects to Bob, there = would be a Session-ID that is end-to-end unique between Alice and = Bob. If an intermediary re-routes the call such that Alice is now = in communication with Sue, then there would be a new unique Session-ID = between Alice and Sue. Likewise, if Alice calls Bob, but there is = a forking proxy that causes the call to be forked to 15 =93Bobs=94, then = there would be 15 Session-IDs, one for each pair of { Alice, Bob(i) = }. The Session-ID is unique between any two communicating = endpoints. An endpoint includes =93terminal=94 devices, =93MCU=94 = devices, etc. It would not include SBCs, as those are intermediary = devices, not terminating devices.
I = agree that wording this is a challenge, and I=92m definitely open to = input on appropriate wording.
Robert = Sparks [mailto:rjsparks@nostrum.com]
Sent: Tuesday, November 08, 2011 = 4:24 PM
To: Paul E. = Jones
Cc: 'Salvatore Loreto'; dispatch@ietf.org
Subject: Re: [dispatch] new charter = version for Session-id

On Nov 8, 2011, at 1:17 = PM, Paul E. Jones wrote:

What I would expect is that we = identifier the session end-to-end from one endpoint to another = endpoint. If that passes through one or more B2BUAs, that would = still be a single communication session for the purposes of this = work.
We need to get that wording right, but I assume = there agreement on identifying the communication session end-to-end = across zero or more B2BUAs. Do folks = agree?
I can't agree because I = can't tell yet what you mean by "the communication session". That's what = I'm asking you to clarify. Your response indicates you are still = focusing only on a model
where one-dialog-into a B2BUA results in exactly = one-dialog-out-of that B2BUA.

The scenario I call out below does not fit in that = model. Do you think there's one session identifier or = two?
If it's one, then it's = not an identifier from one endpoint to another endpoint, its an = identifier from one endpoint to one-or-more other = endpoints.
Paul
  On Behalf Of Robert = Sparks
Sent: Tuesday, November 08, 2011 = 1:42 PM
To: Salvatore = Loreto
Cc: dispatch@ietf.org
Subject: Re: [dispatch] new charter = version for = Session-id

At least one major thread in the conversation in quebec = isn't included in the proposed changes = below.
As you consider the other = feedback you're receiving, please go back and look at (or better, listen = to)
the discussion around = whether "aims to identify a Dialog" is really what you are trying to do. = Given
the answers to = some of the questions in the earlier discussion, it's not a dialog (at = least it's not the thing
that has a dialog identifier). Perhaps you could try = different text at "aims to identify a = <?>".

Consider in particular the case of a call I have with a = B2BUA that starts off relaying my media to one = endpoint,
and then (for = whatever reason) shifts it to another. I heard folks say they want that = whole conversation to = have
one session = identifier, but there were 3 different dialogs = there.
On Oct 7, 2011, at 7:50 AM, Salvatore Loreto = wrote:
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
[1] 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.
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., =93joining=94 two calls at a = B2BUA).
As for Dialogs, an end-to-end Session Identifier = should be =93created through the generation of non-failure responses to = requests with specific methods=94 (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 =93join=94 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 =96 = Specification of the new mechanism sent to the = IESG



=
dispatch@ietf.org
To: "'Paul Kyzivat'" , References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <034101cc9e4b$2124d6e0$636e84a0$@packetizer.com> <47DC2781-8ABD-4FE0-A551-33023053D18E@cisco.com> <037201cc9e52$2b8539c0$828fad40$@packetizer.com> <4EB9906E.6020903@alum.mit.edu> In-Reply-To: <4EB9906E.6020903@alum.mit.edu> Date: Tue, 8 Nov 2011 20:56:08 -0500 Message-ID: <03ff01cc9e82$c11a38c0$434eaa40$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCoMG+cK7yKcacnsncXJq0HayNvgHe9BdiAFxedeMCfmFkxwFNlyHYAvCi3YmT8AEmIA== Content-Language: en-us Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 01:56:18 -0000 Paul, > > In the case where we have multiple calls in a conference as you > > describe, this is not a B2BUA: it's an endpoint (an MCU, in > particular). > > This is part of the difficulty in having this discussion. > "Endpoint" has no formal definition in 3261. And IMO a conference focus > *is* a B2BUA. (I find it to fully agree with the definition of B2BUA in > 3261.) Its just a different kind of B2BUA than you have in mind. I understand. Lacking those definitions makes it difficult, though I'm surprised people would agree that an MCU is a B2BUA. I'm scratching my head over this one. > How do you feel about a 3PCC controller? Is it a B2BUA? If it does a > transfer then it goes through stages when it has two dialogs, then > three, then two. From past discussions, I think you expect there will be > more than one session-id covering that. A PBX-type device would be a B2BUA in my mind and, yes, there would be different Session-IDs since there would be different devices end-to-end. In this case, the B2BUA truly is just an intermediary device, not a terminating device. MCUs, on the other hand, are terminating devices. Yes, they might switch media vs. terminate, decode, re-encode, etc., but it is nonetheless an endpoint device. > > So in this > > case, the session originate at an endpoint and terminate on the > > MCU/endpoint. In a conference, each endpoint connected to a > > conference will have a unique Session-ID. The Session-ID is not a > > conference ID. (That said, we might be able to identify all > > participants in the same conference if we do something along the line > > of what we described in our draft, since we propose using a UUID at > > the MCU that would be the same for each participant in the same > > conference. We need some discussion on that, but if it proved > > unworkable it should not derail the work on a Session-ID.) > > To achieve this you will have to define what you mean by "endpoint", and > how to decide when something is an endpoint and not a B2BUA. Help me out here :-) We do not need to invent new device types, but perhaps you can articulate a definition that is a subset of a user agent that properly represents an endpoint. Paul From paulej@packetizer.com Tue Nov 8 18:03:32 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E8321F8AFD for ; Tue, 8 Nov 2011 18:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwcEjf-KHlDW for ; Tue, 8 Nov 2011 18:03:26 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D395321F8B00 for ; Tue, 8 Nov 2011 18:03:25 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pA923KkT028068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Nov 2011 21:03:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1320804203; bh=bomgPDCPw4izTWoAfpjUIazSo7QyHj5uYLofrw4pFj0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=GAU10k+1dRBohAzoB9R4yXJtYmyrmogeZ4wV2uoUAGytCo+e7yRqFNZlDAH2rXkyb t5S07uMF7bLKXwRIAkzK51WJt/DpHzO7DcO82b71BYKwKLN0wWIElwrQVMbhkJkExf r5Z6j/9x1KwYZtIlJeSdm8RvlGU4fD3O+DVfi2TM= From: "Paul E. Jones" To: "'Robert Sparks'" References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <034101cc9e4b$2124d6e0$636e84a0$@packetizer.com> <06D8F4C8-5CEA-4E16-9DCF-A43C96AAA292@nostrum.com> <03e001cc9e80$ecffa080$c6fee180$@packetizer.com> In-Reply-To: Date: Tue, 8 Nov 2011 21:03:15 -0500 Message-ID: <040401cc9e83$bf9bb9a0$3ed32ce0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0405_01CC9E59.D6CA6C90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCoMG+cK7yKcacnsncXJq0HayNvgHe9BdiAFxedeMCCJ8V7QFPBPcxAo05Lp6T9sKvkA== Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 02:03:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0405_01CC9E59.D6CA6C90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Robert, I would say it is two session IDs, because the end device changed: there was a media server and then there was an agent. If there is some device (and it does not matter if it is the B2BUA or media server in this case) that originates an offer or an answer, then it is terminating the call (effectively). When re-routed, there is another device that originates an offer or answer. It would be nice if the Session-ID never changed, but reality is that it has to. Any kind of forking or service interaction by intermediaries (like this one you described) means that session changed end-to-end, thus we need a new end-to-end Session-ID. What I would hope we can do is note such transitions (e.g., Alice would continue to use the same Session-UUID in the document we submitted) for logging purposes, debugging, tracing, etc. However, what is most important is that we can identify a session end-to-end at any given point in time, even if that time is relatively short. Paul From: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: Tuesday, November 08, 2011 8:55 PM To: Paul E. Jones Cc: 'Salvatore Loreto'; dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id So, if I call Frobgnobitz and get connected to their b2bua, which sets up a dialog to a media server to play me a message while I'm in the queue to talk to an agent, and then when an agent comes available, that B2BUA sets up a second dialog and replumbs itself internally so I'm getting media from the agent instead of from the media server (as far as my endpoint is concerned, it's only ever been in one dialog), you're saying I have two session IDs. I have heard others say it's only one. RjS On Nov 8, 2011, at 7:43 PM, Paul E. Jones wrote: Robert, A Session-ID is intended to be unique between any two communicating endpoints. So, if Alice makes a call and connects to Bob, there would be a Session-ID that is end-to-end unique between Alice and Bob. If an intermediary re-routes the call such that Alice is now in communication with Sue, then there would be a new unique Session-ID between Alice and Sue. Likewise, if Alice calls Bob, but there is a forking proxy that causes the call to be forked to 15 "Bobs", then there would be 15 Session-IDs, one for each pair of { Alice, Bob(i) }. The Session-ID is unique between any two communicating endpoints. An endpoint includes "terminal" devices, "MCU" devices, etc. It would not include SBCs, as those are intermediary devices, not terminating devices. I agree that wording this is a challenge, and I'm definitely open to input on appropriate wording. Paul From: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: Tuesday, November 08, 2011 4:24 PM To: Paul E. Jones Cc: 'Salvatore Loreto'; dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id On Nov 8, 2011, at 1:17 PM, Paul E. Jones wrote: Robert, What I would expect is that we identifier the session end-to-end from one endpoint to another endpoint. If that passes through one or more B2BUAs, that would still be a single communication session for the purposes of this work. We need to get that wording right, but I assume there agreement on identifying the communication session end-to-end across zero or more B2BUAs. Do folks agree? I can't agree because I can't tell yet what you mean by "the communication session". That's what I'm asking you to clarify. Your response indicates you are still focusing only on a model where one-dialog-into a B2BUA results in exactly one-dialog-out-of that B2BUA. The scenario I call out below does not fit in that model. Do you think there's one session identifier or two? If it's one, then it's not an identifier from one endpoint to another endpoint, its an identifier from one endpoint to one-or-more other endpoints. Paul From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Tuesday, November 08, 2011 1:42 PM To: Salvatore Loreto Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id At least one major thread in the conversation in quebec isn't included in the proposed changes below. As you consider the other feedback you're receiving, please go back and look at (or better, listen to) the discussion around whether "aims to identify a Dialog" is really what you are trying to do. Given the answers to some of the questions in the earlier discussion, it's not a dialog (at least it's not the thing that has a dialog identifier). Perhaps you could try different text at "aims to identify a ". Consider in particular the case of a call I have with a B2BUA that starts off relaying my media to one endpoint, and then (for whatever reason) shifts it to another. I heard folks say they want that whole conversation to have one session identifier, but there were 3 different dialogs there. RjS On Oct 7, 2011, at 7:50 AM, Salvatore Loreto wrote: 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 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_0405_01CC9E59.D6CA6C90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Robert,

I would say it is two session IDs, because the end device changed: = there was a media server and then there was an agent. If there is = some device (and it does not matter if it is the B2BUA or media server = in this case) that originates an offer or an answer, then it is = terminating the call (effectively). When re-routed, there is = another device that originates an offer or = answer.

It would be nice if the Session-ID never changed, but reality is that = it has to. Any kind of forking or service interaction by = intermediaries (like this one you described) means that session changed = end-to-end, thus we need a new end-to-end Session-ID. What I would = hope we can do is note such transitions (e.g., Alice would continue to = use the same Session-UUID in the document we submitted) for logging = purposes, debugging, tracing, etc. However, what is most important = is that we can identify a session end-to-end at any given point in time, = even if that time is relatively short.

Paul

From:= = Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: Tuesday, = November 08, 2011 8:55 PM
To: Paul E. Jones
Cc: = 'Salvatore Loreto'; dispatch@ietf.org
Subject: Re: [dispatch] = new charter version for Session-id

So, if I = call Frobgnobitz and get connected to their b2bua, which sets up a = dialog to a media server to play me
a message while I'm in the queue to talk to an agent, = and then when an agent comes available, that = B2BUA
sets up a second = dialog and replumbs itself internally so I'm getting media from the = agent instead of from the
media server (as far as my endpoint is concerned, it's = only ever been in one dialog),  you're saying I = have
two session = IDs.

I = have heard others say it's only one.

RjS

On = Nov 8, 2011, at 7:43 PM, Paul E. Jones wrote:

Robert,

A Session-ID is intended to be unique between any two communicating = endpoints. So, if Alice makes a call and connects to Bob, there = would be a Session-ID that is end-to-end unique between Alice and = Bob. If an intermediary re-routes the call such that Alice is now = in communication with Sue, then there would be a new unique Session-ID = between Alice and Sue. Likewise, if Alice calls Bob, but there is = a forking proxy that causes the call to be forked to 15 = “Bobs”, then there would be 15 Session-IDs, one for each = pair of { Alice, Bob(i) }. The Session-ID is unique between any = two communicating endpoints. An endpoint includes = “terminal” devices, “MCU” devices, etc. It = would not include SBCs, as those are intermediary devices, not = terminating devices.

I agree that wording this is a challenge, and I’m definitely = open to input on appropriate wording.

Paul

From:= Robert = Sparks [mailto:rjsparks@nostrum.co= m]
Sent: Tuesday, November 08, 2011 = 4:24 PM
To: Paul E. = Jones
Cc: 'Salvatore Loreto'; dispatch@ietf.org
Subject: Re: [dispatch] new = charter version for = Session-id

On Nov 8, 2011, at 1:17 PM, Paul E. Jones = wrote:

Robert,

What I would expect is that we identifier the session end-to-end from = one endpoint to another endpoint. If that passes through one or = more B2BUAs, that would still be a single communication session for the = purposes of this work.

We need to get that wording right, but I assume there agreement on = identifying the communication session end-to-end across zero or more = B2BUAs. Do folks = agree?

I can't agree because I can't tell yet what you mean = by "the communication session". That's what I'm asking you to = clarify. Your response indicates you are still focusing only on a = model
where = one-dialog-into a B2BUA results in exactly one-dialog-out-of that = B2BUA.

The scenario I call out below does not fit in that = model. Do you think there's one session identifier or = two?
If = it's one, then it's not an identifier from one endpoint to another = endpoint, its an identifier from one endpoint to one-or-more other = endpoints.

Paul

From:= dispatch-bounces@ietf.org [mailto:dispatch-bounc= es@ietf.org] On = Behalf Of Robert = Sparks
Sent: Tuesday, November 08, 2011 = 1:42 PM
To: Salvatore = Loreto
Cc: dispatch@ietf.org
Subject: Re: [dispatch] new = charter version for = Session-id

At least one major thread in the conversation in = quebec isn't included in the proposed changes = below.
As = you consider the other feedback you're receiving, please go back and = look at (or better, listen = to)
the discussion around whether "aims to identify a = Dialog" is really what you are trying to do. = Given
the answers to some of the questions in the earlier = discussion, it's not a dialog (at least it's not the = thing
that has a dialog identifier). Perhaps you could try = different text at "aims to identify a = <?>".

<= p class=3DMsoNormal>Consider in particular the case of a call I have = with a B2BUA that starts off relaying my media to one = endpoint,
and then (for whatever reason) shifts it to another. I = heard folks say they want that whole conversation to = have
one session identifier, but there were 3 = different dialogs = there.

<= p = class=3DMsoNormal>RjS

<= div>
On Oct 7, 2011, at 7:50 AM, Salvatore = Loreto wrote:

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

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



_______________________________________________
disp= atch mailing list
dispatch@ietf.org
https://www.ietf.= org/mailman/listinfo/dispatch

------=_NextPart_000_0405_01CC9E59.D6CA6C90-- From adam@nostrum.com Tue Nov 8 18:58:51 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B669A1F0C47 for ; Tue, 8 Nov 2011 18:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLnxiyhtXGf1 for ; Tue, 8 Nov 2011 18:58:51 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2211E1F0C4F for ; Tue, 8 Nov 2011 18:58:50 -0800 (PST) Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pA92wmEO080712 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 Nov 2011 20:58:49 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4EB9EC68.3010805@nostrum.com> Date: Tue, 08 Nov 2011 20:58:48 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <034101cc9e4b$2124d6e0$636e84a0$@packetizer.com> <47DC2781-8ABD-4FE0-A551-33023053D18E@cisco.com> <037201cc9e52$2b8539c0$828fad40$@packetizer.com> <4EB9906E.6020903@alum.mit.edu> <03ff01cc9e82$c11a38c0$434eaa40$@packetizer.com> In-Reply-To: <03ff01cc9e82$c11a38c0$434eaa40$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 02:58:51 -0000 On 11/8/11 19:56, Nov 8, Paul E. Jones wrote: > A PBX-type device would be a B2BUA in my mind and, yes, there would be > different Session-IDs since there would be different devices end-to-end. In > this case, the B2BUA truly is just an intermediary device, not a terminating > device. MCUs, on the other hand, are terminating devices. Yes, they might > switch media vs. terminate, decode, re-encode, etc., but it is nonetheless > an endpoint device. It's not that cut and dried. Let's imagine that I place a call, through our office PBX, to you. It's acting like a B2BUA in this context, and is proxying the media. I think you believe that this would be one session. Now, halfway through our conversation, Robert sends an INVITE/Join (RFC3911) to the PBX to add himself to the conversation. It becomes a three-way conversation, with the PBX mixing media and sending it to all three of us. According to what you've said before, a three way conference constitutes three sessions, one between each endpoint and the mixer. How would you imagine this working? Does the session ID that represents the session between us get terminated, and we each get brand new session IDs that represent our session to the PBX? Or does the session ID between us remain, but Robert gets a new one? Or do we propagate the existing session ID to include Robert's part of the call? Then, when Robert hangs up and we continue talking, what happens? It's now a two party call with a B2BUA in the middle. Do we go back to using the session ID that we had in the first place? Do we create a new one? Or do we keep using the two session IDs that represent our respective sessions with the PBX? How about if *I* hang up and you continue to talk to Robert? What identifiers apply then? The problem is that you're using terms as if a SIP node can do one, and exactly one, thing. And that it can never transition roles. And that those roles are very tightly constricted. Unfortunately, the reality of actually deployed systems is nowhere near that regimented. /a From keith.drage@alcatel-lucent.com Wed Nov 9 02:19:48 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A8521F8B94 for ; Wed, 9 Nov 2011 02:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.174 X-Spam-Level: X-Spam-Status: No, score=-106.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7GkbTZFuu5u for ; Wed, 9 Nov 2011 02:19:47 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3A98821F8B92 for ; Wed, 9 Nov 2011 02:19:46 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pA9AJGGS013573 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Nov 2011 11:19:42 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 9 Nov 2011 11:19:33 +0100 From: "DRAGE, Keith (Keith)" To: "Paul E. Jones" , "'Robert Sparks'" Date: Wed, 9 Nov 2011 11:19:31 +0100 Thread-Topic: [dispatch] new charter version for Session-id Thread-Index: AQKCoMG+cK7yKcacnsncXJq0HayNvgHe9BdiAFxedeMCCJ8V7QFPBPcxAo05Lp6T9sKvkIAAi95Q Message-ID: References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <034101cc9e4b$2124d6e0$636e84a0$@packetizer.com> <06D8F4C8-5CEA-4E16-9DCF-A43C96AAA292@nostrum.com> <03e001cc9e80$ecffa080$c6fee180$@packetizer.com> <040401cc9e83$bf9bb9a0$3ed32ce0$@packetizer.com> In-Reply-To: <040401cc9e83$bf9bb9a0$3ed32ce0$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 10:19:48 -0000 I would note that if you call it a session identifier, that is presumably a= unique identifier of something called a "session", which is currently defi= ned in RFC 3261 as: Session: From the SDP specification: "A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session." (RFC 2327 [1]) (A session as defined for SDP can comprise one or more RTP sessions.) As defined, a callee can be invited several times, by different calls, to the same session. If SDP is used, a session is defined by the concatenation of the SDP user name, session id, network type, address type, and address elements in the origin field. That looks to be something different to the way this thread is going. Regards Keith ________________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Paul E. Jones Sent: 09 November 2011 02:03 To: 'Robert Sparks' Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id Robert, I would say it is two session IDs, because the end device changed: there wa= s a media server and then there was an agent.=A0 If there is some device (a= nd it does not matter if it is the B2BUA or media server in this case) that= originates an offer or an answer, then it is terminating the call (effecti= vely).=A0 When re-routed, there is another device that originates an offer = or answer. It would be nice if the Session-ID never changed, but reality is that it ha= s to.=A0 Any kind of forking or service interaction by intermediaries (like= this one you described) means that session changed end-to-end, thus we nee= d a new end-to-end Session-ID.=A0 What I would hope we can do is note such = transitions (e.g., Alice would continue to use the same Session-UUID in the= document we submitted) for logging purposes, debugging, tracing, etc.=A0 H= owever, what is most important is that we can identify a session end-to-end= at any given point in time, even if that time is relatively short. Paul From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 Sent: Tuesday, November 08, 2011 8:55 PM To: Paul E. Jones Cc: 'Salvatore Loreto'; dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id So, if I call Frobgnobitz =A0and get connected to their b2bua, which sets u= p a dialog to a media server to play me a message while I'm in the queue to talk to an agent, and then when an agen= t comes available, that B2BUA sets up a second dialog and replumbs itself internally so I'm getting media= from the agent instead of from the media server (as far as my endpoint is concerned, it's only ever been in on= e dialog),=A0=A0you're saying I have=A0 two session IDs. I have heard others say it's only one. RjS On Nov 8, 2011, at 7:43 PM, Paul E. Jones wrote: Robert, =A0 A Session-ID is intended to be unique between any two communicating endpoin= ts.=A0 So, if Alice makes a call and connects to Bob, there would be a Sess= ion-ID that is end-to-end unique between Alice and Bob.=A0 If an intermedia= ry re-routes the call such that Alice is now in communication with Sue, the= n there would be a new unique Session-ID between Alice and Sue.=A0 Likewise= , if Alice calls Bob, but there is a forking proxy that causes the call to = be forked to 15 "Bobs", then there would be 15 Session-IDs, one for each pa= ir of { Alice, Bob(i) }.=A0 The Session-ID is unique between any two commun= icating endpoints.=A0 An endpoint includes "terminal" devices, "MCU" device= s, etc.=A0 It would not include SBCs, as those are intermediary devices, no= t terminating devices. =A0 I agree that wording this is a challenge, and I'm definitely open to input = on appropriate wording. =A0 Paul =A0 From:=A0Robert Sparks [mailto:rjsparks@nostrum.com]=A0 Sent:=A0Tuesday, November 08, 2011 4:24 PM To:=A0Paul E. Jones Cc:=A0'Salvatore Loreto';=A0dispatch@ietf.org Subject:=A0Re: [dispatch] new charter version for Session-id =A0 =A0 On Nov 8, 2011, at 1:17 PM, Paul E. Jones wrote: Robert, =A0 What I would expect is that we identifier the session end-to-end from one e= ndpoint to another endpoint.=A0 If that passes through one or more B2BUAs, = that would still be a single communication session for the purposes of this= work. =A0 We need to get that wording right, but I assume there agreement on identify= ing the communication session end-to-end across zero or more B2BUAs. Do fol= ks agree? =A0 I can't agree because I can't tell yet what you mean by "the communication = session". That's what I'm asking you to clarify. Your response indicates yo= u are still focusing only on a model where =A0one-dialog-into a B2BUA results in exactly one-dialog-out-of that = B2BUA. =A0 The scenario I call out below does not fit in that model. Do you think ther= e's one session identifier or two?=A0 If it's one, then it's not an identifier from one endpoint to another endpo= int, its an identifier from one endpoint to=A0one-or-more other endpoints. =A0 =A0 =A0 Paul =A0 From:=A0dispatch-bounces@ietf.org=A0[mailto:dispatch-bounces@ietf.org]=A0On= Behalf Of=A0Robert Sparks Sent:=A0Tuesday, November 08, 2011 1:42 PM To:=A0Salvatore Loreto Cc:=A0dispatch@ietf.org Subject:=A0Re: [dispatch] new charter version for Session-id =A0 At least one major thread in the conversation in quebec isn't included in t= he proposed changes below. As you consider the other feedback you're receiving, please go back and loo= k at (or better, listen to) the discussion around whether "aims to identify a Dialog" is really what yo= u are trying to do. Given the answers to some of the questions in the earlier discussion, it's not a = dialog (at least it's not the thing that has a dialog identifier). Perhaps you could try different text at "aim= s to identify a ". =A0 Consider in particular the case of a call I have with a B2BUA that starts o= ff relaying my media to one endpoint, and then (for whatever reason) shifts it to another. I heard folks say they= want that whole conversation to have=A0 one session identifier,=A0but there were 3 different dialogs there. =A0 RjS =A0 On Oct 7, 2011, at 7:50 AM, Salvatore Loreto wrote: 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 --=20 Salvatore Loreto www.sloreto.com [1]=A0http://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 net= works refers to the ability for endpoints, intermediary devices, management= and monitoring system to identify and correlate SIP messages and dialogs o= f 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 th= at the current dialog identifiers defined in SIP are not suitable for end-t= o-end session identification.=A0 Perhaps the most important factor worth de= scribing is that in real-world deployments devices like Back-to-Back User A= gents (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 dialo= g-id) as the session signaling passes through. An end-to-end Session Identifier aims to identify a Dialog (as defined in R= FC 3261 Section 5), but does so in such a way as to overcome the limitation= s of the present means of Dialog identification.=A0 The Session Identifier = allows for the possibility of uniquely identifying the communication sessio= n from the originating endpoint, passing through any number of intermediari= es, to the terminating endpoint.=A0 The Session Identifier will address iss= ues related to transferring or forwarding of sessions, as well as changes d= uring mid-call of either of the endpoints by an intermediary (e.g., "joinin= g" 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).=A0 That said, the end-to-end Session Identifier m= ay change if an endpoint receives an INVITE or other request indicating thr= ough some means that the remote endpoint has changed.=A0 This may occur, fo= r example, when a B2BUA performs a call "join" or otherwise re-routes one e= nd of the communication session.=A0 Taking note of such changes is importan= t 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 inter= working between protocols.=A0 The ITU-T has identified a need for an end-to= -end session Identifier and is progressing work to be aligned with the outp= ut 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 tracki= ng, troubleshooting, billing, session recording, and so forth. Some of thes= e requirements have also been identified and come directly from other exist= ing working group within the RAI area (e.g., SIPRec and Splices).=A0 The re= quirements 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 d= iscuss all the requirements and use cases. Once the needs are clear and ide= ntified, the working group will specify the end-to-end Session Identifier m= echanism. The working group will produce the following deliverables: 1. A requirement and use case document with key consideration for SIP Sessi= on 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 (Informatio= n) November 2012 - Specification of the new mechanism sent to the IESG =A0=A0 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =A0 =A0 From atle.monrad@ericsson.com Wed Nov 9 04:48:21 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D5021F8B2B for ; Wed, 9 Nov 2011 04:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ib75uJuyzi-Z for ; Wed, 9 Nov 2011 04:48:21 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D2FB221F8B14 for ; Wed, 9 Nov 2011 04:48:20 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-f8-4eba769356be Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 60.47.13753.3967ABE4; Wed, 9 Nov 2011 13:48:20 +0100 (CET) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.1.27]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 9 Nov 2011 13:48:18 +0100 From: Atle Monrad To: Gonzalo Camarillo , DISPATCH Date: Wed, 9 Nov 2011 13:48:17 +0100 Thread-Topic: [dispatch] Status of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid Thread-Index: Acyd6ZjYkFvrZCEGRh2aogMhhSbgzQA82KWQ Message-ID: <7A051DFAA46D0246A82293C7CEF621E9067E527543@ESESSCMS0352.eemea.ericsson.se> References: <4EB8DCBF.5030202@ericsson.com> In-Reply-To: <4EB8DCBF.5030202@ericsson.com> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "dwarren@gsm.org" Subject: Re: [dispatch] Status of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 12:48:21 -0000 Gonzalo Thanks for picking this up. Note also that 3GPP2 has similar requirements. The draft:=20 https://datatracker.ietf.org/doc/draft-atarius-dispatch-meid-urn/=20 might benefit from being in the same "package" ?? I hope a solution to this can be found, as a solution is required by the in= dustry. cheers /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson =20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Gonzalo Camarillo Sent: 8. november 2011 08:40 To: DISPATCH Subject: [dispatch] Status of draft-montemurro-gsma-imei-urn and draft-alle= n-dispatch-imei-urn-as-instanceid Folks, some people have been wondering about the status and the process to advance= the following two drafts: http://datatracker.ietf.org/doc/draft-montemurro-gsma-imei-urn/ http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid= / As most of you probably know, the montemurro draft predates the DISPATCH pr= ocess. It was reviewed as Experimental by the IESG back in 2007. The draft = was reviewed again by the IESG in 2009, this time as Informational. At tha= t point, there was a (late) IPR declaration on the draft and the progress o= f the draft stopped there. Now, we (the ADs) have been asked to resume progressing this and the Allen = draft as AD sponsored drafts. As you know, typically, we only AD sponsor dr= afts that are not controversial. So, the decision we need to make is whethe= r or not there is consensus on the non-controversial nature of the draft. I= f there is, we could AD sponsor it. Otherwise, we would need a venue to dis= cuss this piece of work. As the next step, we are going to organize a conference call among the prop= onents of this work and those who have expressed concerns so far (unfortuna= tely, a face-to-face meeting in Taipei will not be possible since some of t= hem won't be there). Based on the result of that discussion, we will decide= how to progress this. Cheers, Gonzalo _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From paulej@packetizer.com Wed Nov 9 05:30:19 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A9221F8C4E for ; Wed, 9 Nov 2011 05:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rgk8OOisAOFA for ; Wed, 9 Nov 2011 05:30:14 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A28E021F8C5F for ; Wed, 9 Nov 2011 05:30:14 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pA9DUC87014479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Nov 2011 08:30:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1320845413; bh=bC4EUMtv2GZ95cw8r6z21Sv+lADKxpocXIKNxg8Wi/0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=e3pAdnXP8H6R7j/Bua5+5SqV/6U2QhgR4LwgVShA0lrRT4cyv5aajVbtC+UO7LjGr pnR4gofGaqNmAt/xqp5r013BLVAesGdOwWcN/ciMrglj+amyraCSxl3LUgTjbcOON8 /2MhUpilkyKy4duapbkryfkeG1iqmDuQDu0ZHH/g= From: "Paul E. Jones" To: "'Adam Roach'" References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <034101cc9e4b$2124d6e0$636e84a0$@packetizer.com> <47DC2781-8ABD-4FE0-A551-33023053D18E@cisco.com> <037201cc9e52$2b8539c0$828fad40$@packetizer.com> <4EB9906E.6020903@alum.mit.edu> <03ff01cc9e82$c11a38c0$434eaa40$@packetizer.com> <4EB9EC68.3010805@nostrum.com> In-Reply-To: <4EB9EC68.3010805@nostrum.com> Date: Wed, 9 Nov 2011 08:30:06 -0500 Message-ID: <04a901cc9ee3$b28e8070$17ab8150$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCoMG+cK7yKcacnsncXJq0HayNvgHe9BdiAFxedeMCfmFkxwFNlyHYAvCi3YkBq5RwVwK+RZwpk81pKtA= Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 13:30:19 -0000 Adam, > Let's imagine that I place a call, through our office PBX, to you. It's > acting like a B2BUA in this context, and is proxying the media. > > I think you believe that this would be one session. Yes, that would be one session, with the B2BUA acting as an intermediary. > Now, halfway through our conversation, Robert sends an INVITE/Join > (RFC3911) to the PBX to add himself to the conversation. It becomes a > three-way conversation, with the PBX mixing media and sending it to all > three of us. At this point, it would appear the PBX changed roles from acting as an intermediary to acting as an MCU, since it is doing the mixing. I assume the PBX also responded to the JOIN. I assume this might also mean that the PBX/MCU sends a re-INVITE to the original two endpoints. > According to what you've said before, a three way conference constitutes > three sessions, one between each endpoint and the mixer. How would you > imagine this working? Does the session ID that represents the session > between us get terminated, and we each get brand new session IDs that > represent our session to the PBX? Or does the session ID between us > remain, but Robert gets a new one? Or do we propagate the existing > session ID to include Robert's part of the call? Assuming the PBX is acting as an MCU, I would expect that the original Session-ID would go away. The PBX would send a Re-INVITE to each of the original two participants and assign part or all of the Session-ID. Following the draft we wrote, it would send a Session-UUID header that replaces the previous value. So, we would have the following three Session-IDs in the conference (where each component below is a Session-UUID value): [ Adam || MCU ] [ Paul || MCU ] [ Robert || MCU ] Note that we're proposing that the MCU/PBX use the same Session-UUID value for each participant in a conference. The concatenated strings are all globally unique, but the "MCU" UUID would be the same and allow one to relate sessions. (Note the order of concatenation is prescribed, but certainly subject to discussion.) > Then, when Robert hangs up and we continue talking, what happens? It's > now a two party call with a B2BUA in the middle. Do we go back to using > the session ID that we had in the first place? Do we create a new one? > Or do we keep using the two session IDs that represent our respective > sessions with the PBX? I assume that the MCU/PBX transitions back to just being an intermediary device, taking itself out of the loop as a media mixer or processor and just acting like an SBC. In that case, I would assume the PBX would forward the Session-UUID for the opposite party in the call as it had originally done. So, we would have a single end-to-end Session-ID value that actually matched the original value: [ Adam || Paul ] If the PBX/MCU still remained in the role of MCU ("focus"), then we might have two Session-IDs: [ Adam || MCU ] [ Paul || MCU ] It really depends on the behavior of the PBX/MCU. If it acts like an MCU (an endpoint), then we would have two Session-IDs, because the remote endpoint is, in fact, the MCU. > How about if *I* hang up and you continue to talk to Robert? What > identifiers apply then? Assuming the PBX/MCU transitions its role from MCU to serving as an intermediary B2BUA, then it would send an INVITE to both of us and we would have a single Session-ID of the form: [ Paul || Robert ] Again, if the PBX/MCU remained in the role of MCU where it acts as an endpoint, then we might have two Session-IDs: [ Paul || MCU ] [ Robert || MCU ] > The problem is that you're using terms as if a SIP node can do one, and > exactly one, thing. And that it can never transition roles. And that > those roles are very tightly constricted. Unfortunately, the reality of > actually deployed systems is nowhere near that regimented. I fully appreciate that roles can and do change. This is the reason, in fact, that we abandoned the idea of defining a Session-ID that is assigned by Alice in the original INVITE and would persist throughout a call. There are simply too many possible service interactions like this one you discussed. You're entirely right that the system must be flexible to accommodate those transitions. As the communication sessions transition, the end-to-end identifier must change. We do lose the original Session-ID sometimes, but what I think is important is that at any given point in time where we have a steady state, it is possible to identify a call end-to-end. By using UUIDs at each endpoint, though, we at least have a means of correlating information. Paul From kpfleming@digium.com Wed Nov 9 05:40:15 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABFE21F8B40 for ; Wed, 9 Nov 2011 05:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1GOkAAbyedA for ; Wed, 9 Nov 2011 05:40:10 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A47B21F8B2A for ; Wed, 9 Nov 2011 05:40:10 -0800 (PST) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RO8Nt-0000a9-OG for dispatch@ietf.org; Wed, 09 Nov 2011 07:40:09 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id A4EACD8004 for ; Wed, 9 Nov 2011 07:40:09 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvNJ5YX3cBbU for ; Wed, 9 Nov 2011 07:40:07 -0600 (CST) Received: from [192.168.1.16] (173-18-150-64.client.mchsi.com [173.18.150.64]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 6374BD8005 for ; Wed, 9 Nov 2011 07:40:07 -0600 (CST) Message-ID: <4EBA82B6.6000704@digium.com> Date: Wed, 09 Nov 2011 07:40:06 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <034101cc9e4b$2124d6e0$636e84a0$@packetizer.com> <47DC2781-8ABD-4FE0-A551-33023053D18E@cisco.com> <037201cc9e52$2b8539c0$828fad40$@packetizer.com> <4EB9906E.6020903@alum.mit.edu> <03ff01cc9e82$c11a38c0$434eaa40$@packetizer.com> <4EB9EC68.3010805@nostrum.com> <04a901cc9ee3$b28e8070$17ab8150$@packetizer.com> In-Reply-To: <04a901cc9ee3$b28e8070$17ab8150$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 13:40:15 -0000 On 11/09/2011 07:30 AM, Paul E. Jones wrote: > Adam, > >> Let's imagine that I place a call, through our office PBX, to you. It's >> acting like a B2BUA in this context, and is proxying the media. >> >> I think you believe that this would be one session. > > Yes, that would be one session, with the B2BUA acting as an intermediary. > >> Now, halfway through our conversation, Robert sends an INVITE/Join >> (RFC3911) to the PBX to add himself to the conversation. It becomes a >> three-way conversation, with the PBX mixing media and sending it to all >> three of us. > > At this point, it would appear the PBX changed roles from acting as an > intermediary to acting as an MCU, since it is doing the mixing. I assume > the PBX also responded to the JOIN. I assume this might also mean that the > PBX/MCU sends a re-INVITE to the original two endpoints. In my experience, devices acting in the PBX role in this scenario do not do this; the two existing endpoints are not made aware of the third party joining the call (although presumably the users of those endpoints become aware of it ). While they certainly *could* issue a re-INVITE in this situation in order to construct/communicate a new Session-ID, this would be new behavior required to support Session-ID usage, and is potentially significantly more complicated to implement than just communicating some header values between sessions. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From pravindran@sonusnet.com Wed Nov 9 05:42:59 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9170C21F8C4F for ; Wed, 9 Nov 2011 05:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcQwdno0Lvuy for ; Wed, 9 Nov 2011 05:42:53 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id A6CD821F8C4C for ; Wed, 9 Nov 2011 05:42:53 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA9DhRYn017204; Wed, 9 Nov 2011 08:43:27 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 08:42:50 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 19:12:59 +0530 Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by inba-hub01.sonusnet.com (10.70.51.86) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 9 Nov 2011 19:12:59 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Wed, 9 Nov 2011 19:12:59 +0530 From: "Ravindran, Parthasarathi" To: "Kevin P. Fleming" , "dispatch@ietf.org" Thread-Topic: [dispatch] new charter version for Session-id Thread-Index: AcyE77ETG/9rMQbjRI2+08i3OA2EoQZKE2IAAAFCA4AAAO8EgAAA03MAAACg7gAAC4RYAAACMEkAABYMQwAAAFloAAALlYzA Date: Wed, 9 Nov 2011 13:42:58 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0134A4E2@inba-mail01.sonusnet.com> References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <034101cc9e4b$2124d6e0$636e84a0$@packetizer.com> <47DC2781-8ABD-4FE0-A551-33023053D18E@cisco.com> <037201cc9e52$2b8539c0$828fad40$@packetizer.com> <4EB9906E.6020903@alum.mit.edu> <03ff01cc9e82$c11a38c0$434eaa40$@packetizer.com> <4EB9EC68.3010805@nostrum.com> <04a901cc9ee3$b28e8070$17ab8150$@packetizer.com> <4EBA82B6.6000704@digium.com> In-Reply-To: <4EBA82B6.6000704@digium.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2011 13:42:59.0724 (UTC) FILETIME=[7EB2ACC0:01CC9EE5] Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 13:42:59 -0000 Kevin, Could you please clarify whether UPDATE or any other method in your mind to= communicate in case RE-INVITE is complicated. Thanks Partha >-----Original Message----- >From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >Behalf Of Kevin P. Fleming >Sent: Wednesday, November 09, 2011 7:10 PM >To: dispatch@ietf.org >Subject: Re: [dispatch] new charter version for Session-id > >On 11/09/2011 07:30 AM, Paul E. Jones wrote: >> Adam, >> >>> Let's imagine that I place a call, through our office PBX, to you. >It's >>> acting like a B2BUA in this context, and is proxying the media. >>> >>> I think you believe that this would be one session. >> >> Yes, that would be one session, with the B2BUA acting as an >intermediary. >> >>> Now, halfway through our conversation, Robert sends an INVITE/Join >>> (RFC3911) to the PBX to add himself to the conversation. It becomes a >>> three-way conversation, with the PBX mixing media and sending it to >all >>> three of us. >> >> At this point, it would appear the PBX changed roles from acting as an >> intermediary to acting as an MCU, since it is doing the mixing. I >assume >> the PBX also responded to the JOIN. I assume this might also mean >that the >> PBX/MCU sends a re-INVITE to the original two endpoints. > >In my experience, devices acting in the PBX role in this scenario do not >do this; the two existing endpoints are not made aware of the third >party joining the call (although presumably the users of those endpoints >become aware of it ). While they certainly *could* issue a re-INVITE >in this situation in order to construct/communicate a new Session-ID, >this would be new behavior required to support Session-ID usage, and is >potentially significantly more complicated to implement than just >communicating some header values between sessions. > >-- >Kevin P. Fleming >Digium, Inc. | Director of Software Technologies >Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: >kpfleming >445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >Check us out at www.digium.com & www.asterisk.org >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From kpfleming@digium.com Wed Nov 9 06:04:49 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD7121F8C43 for ; Wed, 9 Nov 2011 06:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVrCEl7jmeNq for ; Wed, 9 Nov 2011 06:04:45 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA7421F8B7A for ; Wed, 9 Nov 2011 06:04:45 -0800 (PST) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RO8lg-0000tz-MO; Wed, 09 Nov 2011 08:04:44 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id A11A0D8004; Wed, 9 Nov 2011 08:04:44 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2UkkPWiF-LI; Wed, 9 Nov 2011 08:04:40 -0600 (CST) Received: from [192.168.1.16] (173-18-150-64.client.mchsi.com [173.18.150.64]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 9F17BD8002; Wed, 9 Nov 2011 08:04:40 -0600 (CST) Message-ID: <4EBA8878.9090209@digium.com> Date: Wed, 09 Nov 2011 08:04:40 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Ravindran, Parthasarathi" References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <034101cc9e4b$2124d6e0$636e84a0$@packetizer.com> <47DC2781-8ABD-4FE0-A551-33023053D18E@cisco.com> <037201cc9e52$2b8539c0$828fad40$@packetizer.com> <4EB9906E.6020903@alum.mit.edu> <03ff01cc9e82$c11a38c0$434eaa40$@packetizer.com> <4EB9EC68.3010805@nostrum.com> <04a901cc9ee3$b28e8070$17ab8150$@packetizer.com> <4EBA82B6.6000704@digium.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A4E2@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0134A4E2@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 14:04:49 -0000 On 11/09/2011 07:42 AM, Ravindran, Parthasarathi wrote: > Could you please clarify whether UPDATE or any other method in your mind to communicate in case RE-INVITE is complicated. It isn't the choice of SIP request method that is the issue; it's that the PBX would need to implement logic to notify endpoints in an existing call that a party has joined or left the call. In the case of Asterisk, for example, if we were to plan to support this Session-ID mechanism as proposed, our MeetMe/ConfBridge applications would have to start to provide indications to call connected parties (over signaling, not just in the audio path) when this sort of change in the structure of the call occurs. It's certainly possible (it's just software, after all), but it's significantly more work than just carrying a Session-UUID value from an incoming session to an outgoing session. > > Thanks > Partha > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Kevin P. Fleming >> Sent: Wednesday, November 09, 2011 7:10 PM >> To: dispatch@ietf.org >> Subject: Re: [dispatch] new charter version for Session-id >> >> On 11/09/2011 07:30 AM, Paul E. Jones wrote: >>> Adam, >>> >>>> Let's imagine that I place a call, through our office PBX, to you. >> It's >>>> acting like a B2BUA in this context, and is proxying the media. >>>> >>>> I think you believe that this would be one session. >>> >>> Yes, that would be one session, with the B2BUA acting as an >> intermediary. >>> >>>> Now, halfway through our conversation, Robert sends an INVITE/Join >>>> (RFC3911) to the PBX to add himself to the conversation. It becomes a >>>> three-way conversation, with the PBX mixing media and sending it to >> all >>>> three of us. >>> >>> At this point, it would appear the PBX changed roles from acting as an >>> intermediary to acting as an MCU, since it is doing the mixing. I >> assume >>> the PBX also responded to the JOIN. I assume this might also mean >> that the >>> PBX/MCU sends a re-INVITE to the original two endpoints. >> >> In my experience, devices acting in the PBX role in this scenario do not >> do this; the two existing endpoints are not made aware of the third >> party joining the call (although presumably the users of those endpoints >> become aware of it). While they certainly *could* issue a re-INVITE >> in this situation in order to construct/communicate a new Session-ID, >> this would be new behavior required to support Session-ID usage, and is >> potentially significantly more complicated to implement than just >> communicating some header values between sessions. >> >> -- >> Kevin P. Fleming >> Digium, Inc. | Director of Software Technologies >> Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: >> kpfleming >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >> Check us out at www.digium.com& www.asterisk.org >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From paulej@packetizer.com Wed Nov 9 06:06:51 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2813B21F849B for ; Wed, 9 Nov 2011 06:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Vs-CIPbQFd6 for ; Wed, 9 Nov 2011 06:06:46 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 82CA121F8497 for ; Wed, 9 Nov 2011 06:06:46 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pA9E69Sw015638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Nov 2011 09:06:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1320847570; bh=U2uEiweB9B+e3eB4AThpp/1nAiKu4ae5ce88/OAoJxw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=WXVbFXOGMHqaI95uy+0brllwEyKsB1gY070F0beAfc0uOVftMscz/Xcwj1YUdJk4K G8v7k4onm9Dgen5TQEwTtCAzi7GNCFrxAZ1Q/T4DdppHP2+Mxt9w8XX2Q30hw0MZbt s3X/KdNvUD5E426mIkGToAbT3Xd934nCiWe0yr2s= From: "Paul E. Jones" To: "'DRAGE, Keith $Keith$'" , "'Robert Sparks'" References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <034101cc9e4b$2124d6e0$636e84a0$@packetizer.com> <06D8F4C8-5CEA-4E16-9DCF-A43C96AAA292@nostrum.com> <03e001cc9e80$ecffa080$c6fee180$@packetizer.com> <040401cc9e83$bf9bb9a0$3ed32ce0$@packetizer.com> In-Reply-To: Date: Wed, 9 Nov 2011 09:06:03 -0500 Message-ID: <04c001cc9ee8$b8395c70$28ac1550$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCoMG+cK7yKcacnsncXJq0HayNvgHe9BdiAFxedeMCCJ8V7QFPBPcxAo05Lp4BAmRdWAInSXH7k943NTA= Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 14:06:51 -0000 Keith, The term "session" is a bit overloaded (SIP session, RTP session, SDP session, RSVP session). In my opinion, the "session" should closely = track the collection of RTP sessions that comprise and SIP session. I'm not opposed to any name for the end-to-end session ID work, but use = of a different term may not remove the confusion. It's especially = appropriate since we're referring to the "Session Initiation Protocol". Whatever it = is we're initiating, we'd like to identify. ;-) Paul > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Wednesday, November 09, 2011 5:20 AM > To: Paul E. Jones; 'Robert Sparks' > Cc: dispatch@ietf.org > Subject: RE: [dispatch] new charter version for Session-id >=20 > I would note that if you call it a session identifier, that is > presumably a unique identifier of something called a "session", which = is > currently defined in RFC 3261 as: >=20 > Session: From the SDP specification: "A multimedia session is a > set of multimedia senders and receivers and the data streams > flowing from senders to receivers. A multimedia conference = is > an example of a multimedia session." (RFC 2327 [1]) (A = session > as defined for SDP can comprise one or more RTP sessions.) = As > defined, a callee can be invited several times, by different > calls, to the same session. If SDP is used, a session is > defined by the concatenation of the SDP user name, session = id, > network type, address type, and address elements in the = origin > field. >=20 > That looks to be something different to the way this thread is going. >=20 > Regards >=20 > Keith >=20 > ________________________________________ > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul E. Jones > Sent: 09 November 2011 02:03 > To: 'Robert Sparks' > Cc: dispatch@ietf.org > Subject: Re: [dispatch] new charter version for Session-id >=20 > Robert, >=20 > I would say it is two session IDs, because the end device changed: = there > was a media server and then there was an agent.=A0 If there is some = device > (and it does not matter if it is the B2BUA or media server in this = case) > that originates an offer or an answer, then it is terminating the call > (effectively).=A0 When re-routed, there is another device that = originates > an offer or answer. >=20 > It would be nice if the Session-ID never changed, but reality is that = it > has to.=A0 Any kind of forking or service interaction by = intermediaries > (like this one you described) means that session changed end-to-end, > thus we need a new end-to-end Session-ID.=A0 What I would hope we can = do > is note such transitions (e.g., Alice would continue to use the same > Session-UUID in the document we submitted) for logging purposes, > debugging, tracing, etc.=A0 However, what is most important is that we = can > identify a session end-to-end at any given point in time, even if that > time is relatively short. >=20 > Paul >=20 > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: Tuesday, November 08, 2011 8:55 PM > To: Paul E. Jones > Cc: 'Salvatore Loreto'; dispatch@ietf.org > Subject: Re: [dispatch] new charter version for Session-id >=20 > So, if I call Frobgnobitz =A0and get connected to their b2bua, which = sets > up a dialog to a media server to play me a message while I'm in the > queue to talk to an agent, and then when an agent comes available, = that > B2BUA sets up a second dialog and replumbs itself internally so I'm > getting media from the agent instead of from the media server (as far = as > my endpoint is concerned, it's only ever been in one = dialog),=A0=A0you're > saying I have two session IDs. >=20 > I have heard others say it's only one. >=20 > RjS >=20 > On Nov 8, 2011, at 7:43 PM, Paul E. Jones wrote: >=20 > Robert, >=20 > A Session-ID is intended to be unique between any two communicating > endpoints.=A0 So, if Alice makes a call and connects to Bob, there = would > be a Session-ID that is end-to-end unique between Alice and Bob.=A0 If = an > intermediary re-routes the call such that Alice is now in = communication > with Sue, then there would be a new unique Session-ID between Alice = and > Sue.=A0 Likewise, if Alice calls Bob, but there is a forking proxy = that > causes the call to be forked to 15 "Bobs", then there would be 15 > Session-IDs, one for each pair of { Alice, Bob(i) }.=A0 The Session-ID = is > unique between any two communicating endpoints.=A0 An endpoint = includes > "terminal" devices, "MCU" devices, etc.=A0 It would not include SBCs, = as > those are intermediary devices, not terminating devices. >=20 > I agree that wording this is a challenge, and I'm definitely open to > input on appropriate wording. >=20 > Paul >=20 > From:=A0Robert Sparks [mailto:rjsparks@nostrum.com] > Sent:=A0Tuesday, November 08, 2011 4:24 PM > To:=A0Paul E. Jones > Cc:=A0'Salvatore Loreto';=A0dispatch@ietf.org > Subject:=A0Re: [dispatch] new charter version for Session-id >=20 >=20 > On Nov 8, 2011, at 1:17 PM, Paul E. Jones wrote: >=20 >=20 > Robert, >=20 > What I would expect is that we identifier the session end-to-end from > one endpoint to another endpoint.=A0 If that passes through one or = more > B2BUAs, that would still be a single communication session for the > purposes of this work. >=20 > We need to get that wording right, but I assume there agreement on > identifying the communication session end-to-end across zero or more > B2BUAs. Do folks agree? >=20 > I can't agree because I can't tell yet what you mean by "the > communication session". That's what I'm asking you to clarify. Your > response indicates you are still focusing only on a model where = =A0one- > dialog-into a B2BUA results in exactly one-dialog-out-of that B2BUA. >=20 > The scenario I call out below does not fit in that model. Do you think > there's one session identifier or two? If it's one, then it's not an > identifier from one endpoint to another endpoint, its an identifier = from > one endpoint to=A0one-or-more other endpoints. >=20 >=20 >=20 > Paul >=20 > = From:=A0dispatch-bounces@ietf.org=A0[mailto:dispatch-bounces@ietf.org]=A0= On > Behalf Of=A0Robert Sparks > Sent:=A0Tuesday, November 08, 2011 1:42 PM > To:=A0Salvatore Loreto > Cc:=A0dispatch@ietf.org > Subject:=A0Re: [dispatch] new charter version for Session-id >=20 > At least one major thread in the conversation in quebec isn't included > in the proposed changes below. > As you consider the other feedback you're receiving, please go back = and > look at (or better, listen to) the discussion around whether "aims to > identify a Dialog" is really what you are trying to do. Given the > answers to some of the questions in the earlier discussion, it's not a > dialog (at least it's not the thing that has a dialog identifier). > Perhaps you could try different text at "aims to identify a ". >=20 > Consider in particular the case of a call I have with a B2BUA that > starts off relaying my media to one endpoint, and then (for whatever > reason) shifts it to another. I heard folks say they want that whole > conversation to have one session identifier,=A0but there were 3 = different > dialogs there. >=20 > RjS >=20 > On Oct 7, 2011, at 7:50 AM, Salvatore Loreto wrote: >=20 >=20 >=20 > Hi, >=20 > 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. >=20 > 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) >=20 > comments and feedback are really welcome >=20 > cheers > /Sal >=20 >=20 > -- > Salvatore Loreto > www.sloreto.com > = [1]=A0http://www.ietf.org/mail-archive/web/dispatch/current/msg03647.html= >=20 >=20 >=20 > 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.=A0 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.=A0 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.=A0 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).=A0 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.=A0 This may occur, for example, when a B2BUA performs a call > "join" or otherwise re-routes one end of the communication > session.=A0 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.=A0 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).=A0 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 >=20 >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 From pkyzivat@alum.mit.edu Wed Nov 9 07:06:54 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D6B21F8B6E for ; Wed, 9 Nov 2011 07:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pz6pyioI7Mmd for ; Wed, 9 Nov 2011 07:06:53 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6320621F89B8 for ; Wed, 9 Nov 2011 07:06:53 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta10.westchester.pa.mail.comcast.net with comcast id v0jo1h0041ei1Bg5A36t3A; Wed, 09 Nov 2011 15:06:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta24.westchester.pa.mail.comcast.net with comcast id v36t1h00207duvL3k36tJ5; Wed, 09 Nov 2011 15:06:53 +0000 Message-ID: <4EBA9707.3040504@alum.mit.edu> Date: Wed, 09 Nov 2011 10:06:47 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <034101cc9e4b$2124d6e0$636e84a0$@packetizer.com> <47DC2781-8ABD-4FE0-A551-33023053D18E@cisco.com> <037201cc9e52$2b8539c0$828fad40$@packetizer.com> <4EB9906E.6020903@alum.mit.edu> <03ff01cc9e82$c11a38c0$434eaa40$@packetizer.com> <4EB9EC68.3010805@nostrum.com> <04a901cc9ee3$b28e8070$17ab8150$@packetizer.com> In-Reply-To: <04a901cc9ee3$b28e8070$17ab8150$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 15:06:54 -0000 Paul J, Based on your recent replies, I am coming to the conclusion that at least part of the distinction you are drawing between "endpoint" and "intermediary" is based on the extent to which the device processes media. Is that right? If so, then how much processing must it do to be declared an endpoint? If it terminates and then simply forwards packets to a single destination, is it an intermediary? What if it acts as a transcoder, which does a lot of processing of the media? Does this have to do with whether the media has *one* final destination? What if there is no media? (E.g. a subscription.) I'm looking for a clear definition of when you class a box as an endpoint, and when you class it as an intermediary. Once we have a clear definition we can discuss what to call the intermediary. Thanks, Paul K On 11/9/11 8:30 AM, Paul E. Jones wrote: > Adam, > >> Let's imagine that I place a call, through our office PBX, to you. It's >> acting like a B2BUA in this context, and is proxying the media. >> >> I think you believe that this would be one session. > > Yes, that would be one session, with the B2BUA acting as an intermediary. > >> Now, halfway through our conversation, Robert sends an INVITE/Join >> (RFC3911) to the PBX to add himself to the conversation. It becomes a >> three-way conversation, with the PBX mixing media and sending it to all >> three of us. > > At this point, it would appear the PBX changed roles from acting as an > intermediary to acting as an MCU, since it is doing the mixing. I assume > the PBX also responded to the JOIN. I assume this might also mean that the > PBX/MCU sends a re-INVITE to the original two endpoints. > >> According to what you've said before, a three way conference constitutes >> three sessions, one between each endpoint and the mixer. How would you >> imagine this working? Does the session ID that represents the session >> between us get terminated, and we each get brand new session IDs that >> represent our session to the PBX? Or does the session ID between us >> remain, but Robert gets a new one? Or do we propagate the existing >> session ID to include Robert's part of the call? > > Assuming the PBX is acting as an MCU, I would expect that the original > Session-ID would go away. The PBX would send a Re-INVITE to each of the > original two participants and assign part or all of the Session-ID. > Following the draft we wrote, it would send a Session-UUID header that > replaces the previous value. So, we would have the following three > Session-IDs in the conference (where each component below is a Session-UUID > value): > [ Adam || MCU ] > [ Paul || MCU ] > [ Robert || MCU ] > > Note that we're proposing that the MCU/PBX use the same Session-UUID value > for each participant in a conference. The concatenated strings are all > globally unique, but the "MCU" UUID would be the same and allow one to > relate sessions. (Note the order of concatenation is prescribed, but > certainly subject to discussion.) > >> Then, when Robert hangs up and we continue talking, what happens? It's >> now a two party call with a B2BUA in the middle. Do we go back to using >> the session ID that we had in the first place? Do we create a new one? >> Or do we keep using the two session IDs that represent our respective >> sessions with the PBX? > > I assume that the MCU/PBX transitions back to just being an intermediary > device, taking itself out of the loop as a media mixer or processor and just > acting like an SBC. In that case, I would assume the PBX would forward the > Session-UUID for the opposite party in the call as it had originally done. > So, we would have a single end-to-end Session-ID value that actually matched > the original value: > [ Adam || Paul ] > > If the PBX/MCU still remained in the role of MCU ("focus"), then we might > have two Session-IDs: > [ Adam || MCU ] > [ Paul || MCU ] > > It really depends on the behavior of the PBX/MCU. If it acts like an MCU > (an endpoint), then we would have two Session-IDs, because the remote > endpoint is, in fact, the MCU. > >> How about if *I* hang up and you continue to talk to Robert? What >> identifiers apply then? > > Assuming the PBX/MCU transitions its role from MCU to serving as an > intermediary B2BUA, then it would send an INVITE to both of us and we would > have a single Session-ID of the form: > [ Paul || Robert ] > > Again, if the PBX/MCU remained in the role of MCU where it acts as an > endpoint, then we might have two Session-IDs: > [ Paul || MCU ] > [ Robert || MCU ] > >> The problem is that you're using terms as if a SIP node can do one, and >> exactly one, thing. And that it can never transition roles. And that >> those roles are very tightly constricted. Unfortunately, the reality of >> actually deployed systems is nowhere near that regimented. > > I fully appreciate that roles can and do change. This is the reason, in > fact, that we abandoned the idea of defining a Session-ID that is assigned > by Alice in the original INVITE and would persist throughout a call. There > are simply too many possible service interactions like this one you > discussed. You're entirely right that the system must be flexible to > accommodate those transitions. As the communication sessions transition, > the end-to-end identifier must change. We do lose the original Session-ID > sometimes, but what I think is important is that at any given point in time > where we have a steady state, it is possible to identify a call end-to-end. > By using UUIDs at each endpoint, though, we at least have a means of > correlating information. > > Paul > > From paulej@packetizer.com Wed Nov 9 07:19:48 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745F121F8C19 for ; Wed, 9 Nov 2011 07:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhqsaG43+Zhe for ; Wed, 9 Nov 2011 07:19:43 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B7ACB21F8C4C for ; Wed, 9 Nov 2011 07:19:43 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pA9FJcIV017552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Nov 2011 10:19:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1320851980; bh=mjm4Chcz+1DSdo/cyFiXrZFm3mHXHnblWrbjsvKKvT4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=fhF8A8AD3sXFcTbZskABcEuQ2sqRvJkcjYxTkbbeO51stcp39IW/SAEgja1zlupyu 2Xi5FMcNwSqQ7Vfdz1K4sz3rWbyNUwEdEIY7H6UR2pgfM1+uMNeNPYWJQ2aJCNTb+W qy0mOOke5DfoR4yMJPTqm6qxotcs0s9QPxTB3W78= From: "Paul E. Jones" To: "'Kevin P. Fleming'" , "'Ravindran, Parthasarathi'" References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <034101cc9e4b$2124d6e0$636e84a0$@packetizer.com> <47DC2781-8ABD-4FE0-A551-33023053D18E@cisco.com> <037201cc9e52$2b8539c0$828fad40$@packetizer.com> <4EB9906E.6020903@alum.mit.edu> <03ff01cc9e82$c11a38c0$434eaa40$@packetizer.com> <4EB9EC68.3010805@nostrum.com> <04a901cc9ee3$b28e8070$17ab8150$@packetizer.com> <4EBA82B6.6000704@digium.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A4E2@inba-mail01.sonusnet.com> <4EBA8878.9090209@digium.com> In-Reply-To: <4EBA8878.9090209@digium.com> Date: Wed, 9 Nov 2011 10:19:32 -0500 Message-ID: <04d101cc9ef2$fc7bae60$f5730b20$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCoMG+cK7yKcacnsncXJq0HayNvgHe9BdiAFxedeMCfmFkxwFNlyHYAvCi3YkBq5RwVwK+RZwpAchrFY0CUnAEsQKXA96nAkwblfWThZK8gA== Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 15:19:48 -0000 Kevin, I think one could easily build a case for why Asterisk might always have two session-ids (one on the left and one on the right), then one for any additional participants. I would not personally be unhappy with that, since the PBX is arguably an endpoint device. If a phone other than a SIP phone was connected to it (e.g., one controlled via a device control protocol), then one would definitely not argue that the PBX is the endpoint device. As with any protocol feature, some decisions must be left up to the implementer. I'd personally prefer two communicating SIP phones have a common understanding of the session ID, of course. This is particularly important if this might be communicated directly between each other through protocols like RSVP. But, if Asterisk is handling all of the media, that also presents no issue for RSVP (since those would terminate on Asterisk). Paul > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Kevin P. Fleming > Sent: Wednesday, November 09, 2011 9:05 AM > To: Ravindran, Parthasarathi > Cc: dispatch@ietf.org > Subject: Re: [dispatch] new charter version for Session-id > > On 11/09/2011 07:42 AM, Ravindran, Parthasarathi wrote: > > > Could you please clarify whether UPDATE or any other method in your > mind to communicate in case RE-INVITE is complicated. > > It isn't the choice of SIP request method that is the issue; it's that > the PBX would need to implement logic to notify endpoints in an existing > call that a party has joined or left the call. In the case of Asterisk, > for example, if we were to plan to support this Session-ID mechanism as > proposed, our MeetMe/ConfBridge applications would have to start to > provide indications to call connected parties (over signaling, not just > in the audio path) when this sort of change in the structure of the call > occurs. It's certainly possible (it's just software, after all), but > it's significantly more work than just carrying a Session-UUID value > from an incoming session to an outgoing session. > > > > > Thanks > > Partha > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > >> Behalf Of Kevin P. Fleming > >> Sent: Wednesday, November 09, 2011 7:10 PM > >> To: dispatch@ietf.org > >> Subject: Re: [dispatch] new charter version for Session-id > >> > >> On 11/09/2011 07:30 AM, Paul E. Jones wrote: > >>> Adam, > >>> > >>>> Let's imagine that I place a call, through our office PBX, to you. > >> It's > >>>> acting like a B2BUA in this context, and is proxying the media. > >>>> > >>>> I think you believe that this would be one session. > >>> > >>> Yes, that would be one session, with the B2BUA acting as an > >> intermediary. > >>> > >>>> Now, halfway through our conversation, Robert sends an INVITE/Join > >>>> (RFC3911) to the PBX to add himself to the conversation. It becomes > >>>> a three-way conversation, with the PBX mixing media and sending it > >>>> to > >> all > >>>> three of us. > >>> > >>> At this point, it would appear the PBX changed roles from acting as > >>> an intermediary to acting as an MCU, since it is doing the mixing. > >>> I > >> assume > >>> the PBX also responded to the JOIN. I assume this might also mean > >> that the > >>> PBX/MCU sends a re-INVITE to the original two endpoints. > >> > >> In my experience, devices acting in the PBX role in this scenario do > >> not do this; the two existing endpoints are not made aware of the > >> third party joining the call (although presumably the users of those > >> endpoints become aware of it). While they certainly *could* issue > >> a re-INVITE in this situation in order to construct/communicate a new > >> Session-ID, this would be new behavior required to support Session-ID > >> usage, and is potentially significantly more complicated to implement > >> than just communicating some header values between sessions. > >> > >> -- > >> Kevin P. Fleming > >> Digium, Inc. | Director of Software Technologies > >> Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: > >> kpfleming > >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at > >> www.digium.com& www.asterisk.org > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: > kpfleming > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at > www.digium.com & www.asterisk.org > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From kpfleming@digium.com Wed Nov 9 07:24:38 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E15521F8C44 for ; Wed, 9 Nov 2011 07:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFra9ZNa68wl for ; Wed, 9 Nov 2011 07:24:38 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id E667B21F8C28 for ; Wed, 9 Nov 2011 07:24:37 -0800 (PST) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1ROA0z-00022W-DY; Wed, 09 Nov 2011 09:24:37 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 66BFFD8005; Wed, 9 Nov 2011 09:24:37 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPyeOIlbFNWK; Wed, 9 Nov 2011 09:24:36 -0600 (CST) Received: from [192.168.1.16] (173-18-150-64.client.mchsi.com [173.18.150.64]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 7B3EBD8004; Wed, 9 Nov 2011 09:24:36 -0600 (CST) Message-ID: <4EBA9B33.2090405@digium.com> Date: Wed, 09 Nov 2011 09:24:35 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <034101cc9e4b$2124d6e0$636e84a0$@packetizer.com> <47DC2781-8ABD-4FE0-A551-33023053D18E@cisco.com> <037201cc9e52$2b8539c0$828fad40$@packetizer.com> <4EB9906E.6020903@alum.mit.edu> <03ff01cc9e82$c11a38c0$434eaa40$@packetizer.com> <4EB9EC68.3010805@nostrum.com> <04a901cc9ee3$b28e8070$17ab8150$@packetizer.com> <4EBA82B6.6000704@digium.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A4E2@inba-mail01.sonusnet.com> <4EBA8878.9090209@digium.com> <04d101cc9ef2$fc7bae60$f5730b20$@packetizer.com> In-Reply-To: <04d101cc9ef2$fc7bae60$f5730b20$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 15:24:38 -0000 On 11/09/2011 09:19 AM, Paul E. Jones wrote: > Kevin, > > I think one could easily build a case for why Asterisk might always have two > session-ids (one on the left and one on the right), then one for any > additional participants. I would not personally be unhappy with that, since > the PBX is arguably an endpoint device. If a phone other than a SIP phone > was connected to it (e.g., one controlled via a device control protocol), > then one would definitely not argue that the PBX is the endpoint device. > > As with any protocol feature, some decisions must be left up to the > implementer. I'd personally prefer two communicating SIP phones have a > common understanding of the session ID, of course. This is particularly > important if this might be communicated directly between each other through > protocols like RSVP. But, if Asterisk is handling all of the media, that > also presents no issue for RSVP (since those would terminate on Asterisk). I don't disagree; having Asterisk construct Session-UUID values on each side of a two-channel bridge would certainly be compliant with your proposal. However, in the interests of enabling users to achieve what the Session-ID proposal is designed to achieve, we'd probably want to strive to be transparent when possible (and I'd think it would be encouraged for other B2BUAs to do the same). I wouldn't really want to publicize that Asterisk version X.Y is 'compliant with RFC ZZZZ', but in a real-world deployment calls passing through Asterisk would lose the ability to tracked through their Session-ID values. Compliant yes... helpful, not so much :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From paulej@packetizer.com Wed Nov 9 08:28:31 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436FD21F8B39 for ; Wed, 9 Nov 2011 08:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdpE6dYGSp-x for ; Wed, 9 Nov 2011 08:28:27 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id EF88021F8B33 for ; Wed, 9 Nov 2011 08:28:26 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pA9GSOlT019280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Nov 2011 11:28:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1320856105; bh=jOpt1pEtz5e9sBKBu3kjyGEeASeue6PKn8nl3/9940M=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=SYvhxDv72NRzC9fqAu52lACU/lenyU5LYdXyc+Onke/HFUZuaAxpmnbA7YrxnDWDL YnX7CX8dHXz+ZCngXeu5+OeijEl5jUDhl4nkfitJfDSSVidfjDS4Y4FnKxyCY6oS2R uHH2M7jyuLIHeCdHfIO637mmMWAd633ZtMgnK88A= From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <034101cc9e4b$2124d6e0$636e84a0$@packetizer.com> <47DC2781-8ABD-4FE0-A551-33023053D18E@cisco.com> <037201cc9e52$2b8539c0$828fad40$@packetizer.com> <4EB9906E.6020903@alum.mit.edu> <03ff01cc9e82$c11a38c0$434eaa40$@packetizer.com> <4EB9EC68.3010805@nostrum.com> <04a901cc9ee3$b28e8070$17ab8150$@packetizer.com> <4EBA9707.3040504@alum.mit.edu> In-Reply-To: <4EBA9707.3040504@alum.mit.edu> Date: Wed, 9 Nov 2011 11:28:18 -0500 Message-ID: <04f201cc9efc$976222c0$c6266840$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCoMG+cK7yKcacnsncXJq0HayNvgHe9BdiAFxedeMCfmFkxwFNlyHYAvCi3YkBq5RwVwK+RZwpAchrFY0CgYnw5ZOrUkpA Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 16:28:31 -0000 Paul, > Based on your recent replies, I am coming to the conclusion that at > least part of the distinction you are drawing between "endpoint" and > "intermediary" is based on the extent to which the device processes > media. > > Is that right? If so, then how much processing must it do to be declared > an endpoint? If it terminates and then simply forwards packets to a > single destination, is it an intermediary? What if it acts as a > transcoder, which does a lot of processing of the media? Media processing is one measure, though admittedly not entirely perfect. An SBC that performs transcoding would still be classified as an intermediary to me, for example. A device that brings together multiple calls and mixes or switches media would be acting as an endpoint (specifically, and MCU). > Does this have to do with whether the media has *one* final destination? First having been asked that question, I'm thinking "yes". > What if there is no media? (E.g. a subscription.) See, you just went and broke the above answer ;-) If there is no media, there is still a SIP session. I don't think the logic would change. A device in the middle of the network is either acting as a more-or-less pass-through device or it's acting as a termination point, even if there is no media. For subscriptions, I do not have an answer. I've only personally been focused on exchanges where we establish sessions. > I'm looking for a clear definition of when you class a box as an > endpoint, and when you class it as an intermediary. Once we have a clear > definition we can discuss what to call the intermediary. This does get challenging, because there are so many exceptions to any rule. In the general case, I would say an endpoint is an entity that is callable or can be called. That would include physical devices like phones, MCUs, and gateways. However, an SBC is a gateway, but it does not terminate a call: it merely interconnects to a different network (same or different protocol). As such, an SBC I would classify as an intermediary. A PBX is sometimes the endpoint and sometimes an intermediary: it depends on whether that is where the SIP or H.323 signaling terminates. In the case where the PBX is acting as the MCU, the signaling effectively terminates there, because it takes full control over the multipoint conference. Somewhere out of all of this, perhaps a definition can materialize. However, I think we will always find an exception to any rule and something that does not strictly fit a given definition. Paul From richard@shockey.us Wed Nov 9 09:38:31 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CFB21F8C44 for ; Wed, 9 Nov 2011 09:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.005 X-Spam-Level: X-Spam-Status: No, score=-98.005 tagged_above=-999 required=5 tests=[AWL=-1.342, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_UNA=1.231, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbdbZ4-dYzjY for ; Wed, 9 Nov 2011 09:38:29 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 00B6921F8C3E for ; Wed, 9 Nov 2011 09:38:28 -0800 (PST) Received: (qmail 31887 invoked by uid 0); 9 Nov 2011 17:38:28 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 9 Nov 2011 17:38:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=+OOk5w1mmCVm7U+KdNavr5ao3MyxLnpLQwzliuSQqkQ=; b=d1M/56bLRbFMXu9EKuksS9SmpbD5qA2/9hWo4ZsjNGvWvT6F2Snq7kWpITfQ1kV3XAgOAds8tUmiTPq1MiaWJsz85ShFGQojamimP5exTVuGrAkNZxEKCgHWFJqRhN2W; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1ROC6W-0005kn-7q for dispatch@ietf.org; Wed, 09 Nov 2011 10:38:28 -0700 From: "Richard Shockey" To: Date: Wed, 9 Nov 2011 12:38:24 -0500 Message-ID: <01b001cc9f06$62927f90$27b77eb0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B1_01CC9EDC.79BC7790" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyfAmaaF4red6jNRt+95dvKNUGTZgAA81mQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Subject: [dispatch] Save the Date for SIPNOC US 2012! X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 17:38:31 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01B1_01CC9EDC.79BC7790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI . The SIP Forum has announced that it will host the second annual SIP Network Operators Conference (SIPNOC US 2012), a two-day educational conference focusing on the challenges and opportunities related to the deployment of SIP-based carrier services globally. SIPNOC US 2012 will be held in Herndon, VA on June 25-27, 2012 and will build on the success of the inaugural event last spring, which attracted leading technical and operations personnel from the global carrier community and earned high praise from attendees for its educational, non-commercial and technical content that focused on the real-world challenges operators face when deploying SIP services in global IP networks. Unlike other events, this conference is designed for SIP network operations personnel, such as NOC engineers and network architects, instead of a high-level conference for marketing executives. SIPNOC US 2012 will build on themes first discussed at last year's inaugural event: addressing issues critical to the reliable and successful deployment and operation of SIP-based services in carrier networks and the opportunities that come with it. Among the topics expected to be on the agenda at this year's conference are SIP trunking interoperability and the SIP Forum's recently ratified SIPconnect 1.1 technical specification, Fax over Internet protocol (FoIP) interworking, implementing SIP with IPv6, security, testing, application development, call routing and peering, troubleshooting and monitoring, emergency services, and the sharing of best practices for the utilization of Wireshark for network diagnostics within IP network environments. The event will focus on the needs of service providers of all stripes, including telecommunications providers, major backbone operators, interconnect and wholesale solution providers, ISPs, cable operators, wireless network operators as well as large enterprises deploying major SIP initiatives. To access the full text of the SIPNOC US 2012 "Save the Date" Announcement, please click HERE . The presentations given at the inaugural SIPNOC 2011 event have been posted to the SIPNOC document repository, and are available for viewing HERE . For more information about SIPNOC US 2012, please visit the event webpage HERE. ************************* Marc Robins President and Managing Director SIP Forum http://www.sipforum.org Tel: 718-548-7245 Mobile: 203-829-6307 SkypeMe! marcrobins ************************* Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 skype-linkedin-facebook: rshockey101 http//www.sipforum.org ------=_NextPart_000_01B1_01CC9EDC.79BC7790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
FYI …
The SIP Forum has announced = that it will host the second annual SIP Network Operators Conference = (SIPNOC US 2012), a two-day educational conference focusing on the = challenges and opportunities related to the deployment of SIP-based = carrier services globally. SIPNOC US 2012 will be held in = Herndon, VA on June 25-27, 2012 and will build on the success of = the inaugural event last spring, which attracted leading technical and = operations personnel from the global carrier community and earned high = praise from attendees for its educational, non-commercial and technical = content that focused on the real-world challenges operators face when = deploying SIP services in global IP networks. Unlike other events, this = conference is designed for SIP network operations personnel, such as NOC = engineers and network architects, instead of a high-level conference for = marketing executives.
SIPNOC US = 2012 will = build on themes first discussed at last year’s inaugural event: = addressing issues critical to the reliable and successful deployment and = operation of SIP-based services in carrier networks and the = opportunities that come with it. Among the topics expected to be on the = agenda at this year’s conference are SIP trunking interoperability = and the SIP Forum’s recently ratified SIPconnect 1.1 technical = specification, Fax over Internet protocol (FoIP) interworking, = implementing SIP with IPv6, security, testing, application development, = call routing and peering, troubleshooting and monitoring, emergency = services, and the sharing of best practices for the utilization of = Wireshark for network diagnostics within IP network environments. =
The event will focus on the = needs of service providers of all stripes, including telecommunications = providers, major backbone operators, interconnect and wholesale solution = providers, ISPs, cable operators, wireless network operators as well as = large enterprises deploying major SIP initiatives. =
To access the = full text of the SIPNOC US 2012 "Save the Date" Announcement, = please click HERE.
= The = presentations given at the inaugural SIPNOC 2011 event have been posted = to the SIPNOC document repository, and are available for viewing HERE.
= For more = information about SIPNOC US 2012, please visit the event webpage HERE.

*************= ************
Marc = Robins
President = and Managing Director
SIP = Forum
http://www.si= pforum.org

Tel: = 718-548-7245
Mobile: = 203-829-6307
SkypeMe! = marcrobins

*************= ************
Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP = Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>= ;
skype-linkedin-facebook: = rshockey101
http//www.sipforum.org

------=_NextPart_000_01B1_01CC9EDC.79BC7790-- From dworley@avaya.com Wed Nov 9 10:20:53 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3619E21F888A for ; Wed, 9 Nov 2011 10:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.325 X-Spam-Level: X-Spam-Status: No, score=-103.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSQ-feXb7AIq for ; Wed, 9 Nov 2011 10:20:42 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8D221F88AB for ; Wed, 9 Nov 2011 10:20:42 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAJAHDCuk6HCzI1/2dsb2JhbABCqiR+B4F5EihRARUpQicEGxqfMoQVnDGJHGMEiAyRbYw8 X-IronPort-AV: E=Sophos;i="4.69,484,1315195200"; d="scan'208";a="276746778" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Nov 2011 13:20:40 -0500 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Nov 2011 13:09:37 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 9 Nov 2011 13:20:39 -0500 From: "Worley, Dale R (Dale)" To: "dispatch@ietf.org" Date: Wed, 9 Nov 2011 13:20:39 -0500 Thread-Topic: Session-Id: Problem 1: What is a "session"? Thread-Index: AQHMnwxIW2GeNU/FEE2MwYATl89i5w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Session-Id: Problem 1: What is a "session"? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 18:20:54 -0000 As Keith notes, the word "session" is overloaded. The *original* meaning is clear, it is a set of media streams described by SDP, the *Session Description Protocol*. SIP, the Session Initiation Protocol, is a "wrapper" that allows two devices to negotiate a session between themselves. That is why SIP INVITE requests carry SDP payloads. (In the hierarchy of grouping, "dialog" sits here.) The *other* meaning of "session" is not rigidly defined, but corresponds more to what people think of as phone calls. In particular, in the common situation of a B2BUA whose intent is to pass a call onward, the "incoming" and "outgoing" SIP dialogs are considered part of the same "session". Should we call them "little sessions" (=3D SDP sessions) and "big sessions"? ;-) Dale From dworley@avaya.com Wed Nov 9 10:26:59 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B111F0C35 for ; Wed, 9 Nov 2011 10:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.336 X-Spam-Level: X-Spam-Status: No, score=-103.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mB-nXAiQ7Ea1 for ; Wed, 9 Nov 2011 10:26:59 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 613D021F8AF3 for ; Wed, 9 Nov 2011 10:26:59 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIJAHTFuk7GmAcF/2dsb2JhbAA4CqokfgeBcgEBAQECARIoRA0BFQghQicEEwgah2CXTIQVnC+GToJOYwSIDJFtjDw X-IronPort-AV: E=Sophos;i="4.69,484,1315195200"; d="scan'208";a="313684971" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Nov 2011 13:26:52 -0500 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Nov 2011 13:26:03 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 9 Nov 2011 13:26:51 -0500 From: "Worley, Dale R (Dale)" To: "dispatch@ietf.org" Date: Wed, 9 Nov 2011 13:26:08 -0500 Thread-Topic: Session-Id: Problem 2: What is a "session"? Thread-Index: AQHMnw0mG6tgCOyVukqFEnoyBdYvuA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Session-Id: Problem 2: What is a "session"? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 18:27:00 -0000 Paul notes: > From: Paul E. Jones [paulej@packetizer.com] >=20 > What I would expect is that we [identify] the session end-to-end from > one endpoint to another endpoint. > =20 > We need to get that wording right, but I assume there agreement on > identifying the communication session end-to-end across zero or more > B2BUAs. Do folks agree? The bizarre fact is that Paul's description both is completely accurate and evades the core problem. Everyone agrees that a "[big ;-)] session" is the communication between one "endpoint" and another "endpoint". The meanings of "session" and "endpoint" are tightly linked by this fact. The problem is that we do not have a common understanding of what constitutes a session, or equivalently, which particular device functionalities count as "endpoint" as opposed to "B2BUA". Dale From dworley@avaya.com Wed Nov 9 10:56:07 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E279D1F0C35 for ; Wed, 9 Nov 2011 10:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.046 X-Spam-Level: X-Spam-Status: No, score=-103.046 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0R2BEEe6Yik for ; Wed, 9 Nov 2011 10:56:07 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4718721F8B0C for ; Wed, 9 Nov 2011 10:56:07 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEJACbMuk7GmAcF/2dsb2JhbABCqiR+B4FyAQEBAQIBEmwNARUIYycECgkIGodgl0uEFZwuiRxjBIgMkW2MPA X-IronPort-AV: E=Sophos;i="4.69,484,1315195200"; d="scan'208";a="313691101" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Nov 2011 13:55:58 -0500 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Nov 2011 13:55:07 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 9 Nov 2011 13:55:55 -0500 From: "Worley, Dale R (Dale)" To: "dispatch@ietf.org" Date: Wed, 9 Nov 2011 13:54:47 -0500 Thread-Topic: Session-Id: Problem 3: A session is limited to two endpoints Thread-Index: AQHMnxE1qBsBnjbYVkC2azVfIMC/oQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 18:56:08 -0000 part 1: > From: Paul E. Jones [paulej@packetizer.com] >=20 > A Session-ID is intended to be unique between any two communicating > endpoints. So, if Alice makes a call and connects to Bob, there would > be a Session-ID that is end-to-end unique between Alice and Bob. If > an intermediary re-routes the call such that Alice is now in > communication with Sue, then there would be a new unique Session-ID > between Alice and Sue. Likewise, if Alice calls Bob, but there is a > forking proxy that causes the call to be forked to 15 =93Bobs=94, then > there would be 15 Session-IDs, one for each pair of { Alice, Bob(i) }. > The Session-ID is unique between any two communicating endpoints. So to summarize, if a single INVITE forks to two destinations, the resulting dialogs are two sessions, and need separate Session-Ids. The interesting point is that the dialogs have the *same* Call-Id. Logically, the mapping from Call-Id to Session-Id is not many-to-one, although the mapping from dialog identifiers (Call-Id, caller-tag, callee-tag) to Session-Id is still many-to-one. Functionally, a Session-Id cannot be assigned before the INVITE reaches the endpoint; the Session-Id first appears in the 2xx response from the destination endpoint. part 2: Another case which bedevils the definitions: 1. Alice calls Bob through a B2BUA functioning as an SBC. There are two SIP dialogs, Alice-SBC and SBC-Bob. 2. Bob transfers the call to Carol by sending toward Alice a REFER with Refer-To: sip:carol. 3. The SBC "shortstops" the REFER by obeying it itself, so it creates a dialog to Carol, SBC-Carol. Through passing SDP through or altering its RTP relaying, the dialog Alice-SBC is used for the communication with Carol. In the initial phase, the dialogs Alice-SBC and SBC-Bob are part of one session, and share a Session-Id. In the second phase, the dialogs Alice-SBC and SBC-Carol are part of a *different* session, despite that the dialog Alice-SBC has not changed. In this situation, even the mapping from dialog identifiers to Session-Ids is not many-to-one, and the Session-Id of a dialog changes over time. How are we to signal to Alice that the Session-Id of her dialog has changed? part 3: Now to combine these to make a really nasty example! 1. Alice calls Bob. The Alice-Bob dialog is assigned a Session-Id by Bob. 2. Alice wants to do an attended transfer of the call to Carol. She puts the dialog with Bob on hold, and initiates a call to sip:carol. (BTW, is the hold music from the MOH server to Bob yet another session?) 3. The call to sip:carol forks to two UAs. Carol answers the call on one, and her UA assigns a Session-Id to the Alice-Carol dialog. 4. Dave answers the call on the other UA, and his UA assigns a Session-Id to the Alice-Dave dialog. 5. Alice ends the Alice-Dave dialog. 6. Alice executes the transfer, sending an INVITE-with-Replaces to Carol to make her UA establish a dialog with Bob. The new Carol-Bob dialog is assigned a further Session-Id. (This can be made more complicated by inserting SBCs into the flow in various places.) I believe that this example excludes all proposed definitions of "session": For every definition of "session", there is no implementation that can assign Session-Ids correctly in this example. Dale "In cooperation with an intelligent joiner I would undertake to defeat any definition of chair or chairishness that you gave me." -- H. G. Wells, "A Modern Utopia" From dworley@avaya.com Wed Nov 9 10:57:15 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD8411E8089 for ; Wed, 9 Nov 2011 10:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.844 X-Spam-Level: X-Spam-Status: No, score=-102.844 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4duu+14IuaIe for ; Wed, 9 Nov 2011 10:57:15 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id D988211E8087 for ; Wed, 9 Nov 2011 10:57:14 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIJAILMuk7GmAcF/2dsb2JhbABCqiR+B4FyAQEBAQMSKE8CAQgNKRAyJQEBBBsao0OcLokcYwSIDJFtjDw X-IronPort-AV: E=Sophos;i="4.69,484,1315195200"; d="scan'208";a="217072863" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 Nov 2011 13:57:13 -0500 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Nov 2011 13:56:24 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Wed, 9 Nov 2011 13:57:12 -0500 From: "Worley, Dale R (Dale)" To: "dispatch@ietf.org" Date: Wed, 9 Nov 2011 13:56:18 -0500 Thread-Topic: [dispatch] new charter version for Session-id Thread-Index: AcyeRjA4CR6Vs2OVR1mxOnGPngPVcgAyxMbl Message-ID: References: <4E8EF582.6050403@ericsson.com>, <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> In-Reply-To: <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 18:57:15 -0000 If we're gong to make progress, I think we will have to include "Working out a good definition of 'session'." as one of the tasks for the WG. Dale From pkyzivat@alum.mit.edu Wed Nov 9 11:10:31 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414D021F8511 for ; Wed, 9 Nov 2011 11:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXrQHa8A7EUu for ; Wed, 9 Nov 2011 11:10:30 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id A63ED21F84FC for ; Wed, 9 Nov 2011 11:10:30 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta06.westchester.pa.mail.comcast.net with comcast id v6hs1h00316LCl0567AWtp; Wed, 09 Nov 2011 19:10:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta06.westchester.pa.mail.comcast.net with comcast id v7AV1h01G07duvL3S7AVPr; Wed, 09 Nov 2011 19:10:30 +0000 Message-ID: <4EBAD023.3010508@alum.mit.edu> Date: Wed, 09 Nov 2011 14:10:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <4E8EF582.6050403@ericsson.com>, <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 19:10:31 -0000 On 11/9/11 1:56 PM, Worley, Dale R (Dale) wrote: > If we're gong to make progress, I think we will have to include > "Working out a good definition of 'session'." as one of the tasks > for the WG. Yes. It would be ideal if the definition was complete - able to classify all possible cases, with the classification for the "common" ones being something that we can agree is reasonable. This is fundamental problem I have had with all the attempts to define a session id - its *hard* to come up with a widely agreeable definition of session. Thanks, Paul From keith.drage@alcatel-lucent.com Wed Nov 9 11:20:01 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D8821F8A6C for ; Wed, 9 Nov 2011 11:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.168 X-Spam-Level: X-Spam-Status: No, score=-106.168 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXtPREVV19g1 for ; Wed, 9 Nov 2011 11:20:01 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2F43621F85F1 for ; Wed, 9 Nov 2011 11:20:00 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pA9JJvDZ005557 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Nov 2011 20:19:57 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 9 Nov 2011 20:19:57 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "dispatch@ietf.org" Date: Wed, 9 Nov 2011 20:19:54 +0100 Thread-Topic: [dispatch] new charter version for Session-id Thread-Index: AcyfE0RX133wMsbOSpKsgvKwJDbjWAAALdNg Message-ID: References: <4E8EF582.6050403@ericsson.com>, <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <4EBAD023.3010508@alum.mit.edu> In-Reply-To: <4EBAD023.3010508@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 19:20:02 -0000 There was one definition I used to like in ITU-T which was one of the their= "call" definitions, which was something along the lines of "the associatio= n between two or more end users". Now if we use that definition to be the t= erminal (or UA) associated with that end user, it has the following charact= eristics: 1) It enshrines the path into PSTN, or whatever else, that lies beyond the = SIP gateway 2) It enshrines all the users attached to a conference focus, and the confe= rence focus itself. 3) All the forks in a reguest would be part of the same "call". While this may not be what we are trying to achieve with this new identifie= r, it may help identify what it is not. Regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 09 November 2011 19:10 > To: dispatch@ietf.org > Subject: Re: [dispatch] new charter version for Session-id >=20 > On 11/9/11 1:56 PM, Worley, Dale R (Dale) wrote: > > If we're gong to make progress, I think we will have to include > > "Working out a good definition of 'session'." as one of the tasks > > for the WG. >=20 > Yes. It would be ideal if the definition was complete - able to classify > all possible cases, with the classification for the "common" ones being > something that we can agree is reasonable. >=20 > This is fundamental problem I have had with all the attempts to define a > session id - its *hard* to come up with a widely agreeable definition of > session. >=20 > Thanks, > Paul > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Wed Nov 9 11:31:59 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE0C11E8080 for ; Wed, 9 Nov 2011 11:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.122 X-Spam-Level: X-Spam-Status: No, score=-103.122 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK1NrCDrV616 for ; Wed, 9 Nov 2011 11:31:58 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C09CC21F8797 for ; Wed, 9 Nov 2011 11:31:58 -0800 (PST) Received: by vws5 with SMTP id 5so2075466vws.31 for ; Wed, 09 Nov 2011 11:31:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Bt9/D7yN+HVLXKYVsSXum5F2G5JMAsMY4WdsdOo2WrI=; b=KVT/bbxnraDL5J2yFJUELoqkP6pwtTlLa0+BAE+JpZ+bi4HHi7Y4xhV2LMmaiiRsW7 Upi5eQI9wK/cqzlrP23kspf9ExmgN0OqzCP1OEcQoheZVM7P+4T62Q7Snr55YIIsOiez iO2ukkyeHbyn6R86Apei741CFU4MiN/XPo3DQ= MIME-Version: 1.0 Received: by 10.52.97.35 with SMTP id dx3mr6959682vdb.2.1320867118178; Wed, 09 Nov 2011 11:31:58 -0800 (PST) Received: by 10.52.175.131 with HTTP; Wed, 9 Nov 2011 11:31:58 -0800 (PST) In-Reply-To: <4EBAD023.3010508@alum.mit.edu> References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <4EBAD023.3010508@alum.mit.edu> Date: Wed, 9 Nov 2011 13:31:58 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 19:31:59 -0000 What is the definition used by the SIPREC (SIP (Session) Recording) WG? It would seem that you all should have struggled with the same problem. From the requirements, where the word is used 100 times in that document. Although, it looks like you all finagled your way out of it by defining "Communication Session" as: Communication Session (CS): A session created between two or more SIP User Agents (UAs) that is the subject of recording. Mary. On Wed, Nov 9, 2011 at 1:10 PM, Paul Kyzivat wrote: > On 11/9/11 1:56 PM, Worley, Dale R (Dale) wrote: >> >> If we're gong to make progress, I think we will have to include >> "Working out a good definition of 'session'." as one of the tasks >> for the WG. > > Yes. It would be ideal if the definition was complete - able to classify = all > possible cases, with the classification for the "common" ones being > something that we can agree is reasonable. > > This is fundamental problem I have had with all the attempts to define a > session id - its *hard* to come up with a widely agreeable definition of > session. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From oej@edvina.net Wed Nov 9 12:56:12 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307A81F0C86 for ; Wed, 9 Nov 2011 12:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifTJFdICfTUE for ; Wed, 9 Nov 2011 12:56:11 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 97A141F0C60 for ; Wed, 9 Nov 2011 12:56:11 -0800 (PST) Received: from [192.168.40.76] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 48583754BD1C; Wed, 9 Nov 2011 20:56:06 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: Date: Wed, 9 Nov 2011 21:56:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1E4821AB-FC90-44A3-9736-CDEED9B1B8E1@edvina.net> References: To: "Worley, Dale R (Dale)" X-Mailer: Apple Mail (2.1251.1) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Session-Id: Problem 1: What is a "session"? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 20:56:12 -0000 9 nov 2011 kl. 19:20 skrev Worley, Dale R (Dale): > As Keith notes, the word "session" is overloaded. >=20 > The *original* meaning is clear, it is a set of media streams > described by SDP, the *Session Description Protocol*. SIP, the > Session Initiation Protocol, is a "wrapper" that allows two devices to > negotiate a session between themselves. That is why SIP INVITE > requests carry SDP payloads. >=20 > (In the hierarchy of grouping, "dialog" sits here.) >=20 > The *other* meaning of "session" is not rigidly defined, but > corresponds more to what people think of as phone calls. In > particular, in the common situation of a B2BUA whose intent is to pass > a call onward, the "incoming" and "outgoing" SIP dialogs are > considered part of the same "session". >=20 > Should we call them "little sessions" (=3D SDP sessions) and "big > sessions"? ;-) Media sessions - msessions - or just sessions Dialog sessions - dsessions But that gets to confusing Dialog groups is propably a better term to use. I could explain a dialog = group as a group of dialogs. -------- Dialog-group: Identifier for a group of Dialogs Dialogs: identied by a call-iD and more Session: A media session, described by SDP /O= From oej@edvina.net Wed Nov 9 12:59:51 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2D31F0C53 for ; Wed, 9 Nov 2011 12:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFC-fanZJPK8 for ; Wed, 9 Nov 2011 12:59:51 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5451F0C4D for ; Wed, 9 Nov 2011 12:59:51 -0800 (PST) Received: from [192.168.40.76] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id CE35E754BD1C; Wed, 9 Nov 2011 20:59:48 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Wed, 9 Nov 2011 21:59:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <12C3A4BB-DD30-43A6-8F08-4AA1CFE64D52@edvina.net> References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <4EBAD023.3010508@alum.mit.edu> To: Mary Barnes X-Mailer: Apple Mail (2.1251.1) Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 20:59:51 -0000 9 nov 2011 kl. 20:31 skrev Mary Barnes: > What is the definition used by the SIPREC (SIP (Session) Recording) > WG? It would seem that you all should have struggled with the same > problem. =46rom the requirements, where the word is used 100 times in > that document. Although, it looks like you all finagled your way out > of it by defining "Communication Session" as: > Communication Session (CS): A session created between two or more SIP > User Agents (UAs) that is the subject of recording. I would like to avoid "session" - it will be confusing for my SIP = students... Do I open a can of worms if I ask how a "Session-ID" or = "Dialog-group-ID" will relate to "SIP-history" ? /O= From pkyzivat@alum.mit.edu Wed Nov 9 14:07:32 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA2E21F8496 for ; Wed, 9 Nov 2011 14:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-mLfdInnwxR for ; Wed, 9 Nov 2011 14:07:31 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 95F4721F8495 for ; Wed, 9 Nov 2011 14:07:30 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta01.westchester.pa.mail.comcast.net with comcast id v7e41h0031vXlb851A7WEE; Wed, 09 Nov 2011 22:07:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id vA7V1h01n07duvL3dA7VnN; Wed, 09 Nov 2011 22:07:30 +0000 Message-ID: <4EBAF9A0.4060202@alum.mit.edu> Date: Wed, 09 Nov 2011 17:07:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mary Barnes References: <4E8EF582.6050403@ericsson.com> <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <4EBAD023.3010508@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 22:07:32 -0000 On 11/9/11 2:31 PM, Mary Barnes wrote: > What is the definition used by the SIPREC (SIP (Session) Recording) > WG? It would seem that you all should have struggled with the same > problem. From the requirements, where the word is used 100 times in > that document. Although, it looks like you all finagled your way out > of it by defining "Communication Session" as: > Communication Session (CS): A session created between two or more SIP > User Agents (UAs) that is the subject of recording. We did (intentionally) leave the definition of Communication Session (CS) loose in siprec. In general the SRC is then free to represent a particular situation as one CS or multiple as it sees fit. There is (currently) no expectation that the (mythical) session-id is used as the way to determine which things are part of the same CS. *If* the session-id mechanism was suitably defined, and widely implemented, then maybe it could be used as one input to the identification of a CS. But I am far from convinced that a definition useful to siprec would be useful for everybody else. Thanks, Paul > Mary. > > On Wed, Nov 9, 2011 at 1:10 PM, Paul Kyzivat wrote: >> On 11/9/11 1:56 PM, Worley, Dale R (Dale) wrote: >>> >>> If we're gong to make progress, I think we will have to include >>> "Working out a good definition of 'session'." as one of the tasks >>> for the WG. >> >> Yes. It would be ideal if the definition was complete - able to classify all >> possible cases, with the classification for the "common" ones being >> something that we can agree is reasonable. >> >> This is fundamental problem I have had with all the attempts to define a >> session id - its *hard* to come up with a widely agreeable definition of >> session. >> >> Thanks, >> Paul >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > From dworley@avaya.com Wed Nov 9 14:36:51 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5239911E808E for ; Wed, 9 Nov 2011 14:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.336 X-Spam-Level: X-Spam-Status: No, score=-103.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8lj1-3Ayel7 for ; Wed, 9 Nov 2011 14:36:50 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id AC8BD11E8087 for ; Wed, 9 Nov 2011 14:36:50 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMJAM7/uk7GmAcF/2dsb2JhbABEqiR+B4FyAQEBAQIBEihECwIBCA0IIRAyJQEBBBMIDA6HYJtonCiJHGMEiAyRbYw8 X-IronPort-AV: E=Sophos;i="4.69,485,1315195200"; d="scan'208";a="313733860" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Nov 2011 17:36:49 -0500 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Nov 2011 17:35:59 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 9 Nov 2011 17:36:48 -0500 From: "Worley, Dale R (Dale)" To: "dispatch@ietf.org" Date: Wed, 9 Nov 2011 17:35:59 -0500 Thread-Topic: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AcyTSop6CtS58aw5RJ+KzjYRIm6TcAL5Wla+ Message-ID: References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com> <4EA6D17C.3050107@nostrum.com> , <4EA70AE7.6050007@nostrum.com> In-Reply-To: <4EA70AE7.6050007@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 22:36:51 -0000 > From: Adam Roach [adam@nostrum.com] >=20 > In the spirit of "send text," I would propose extending the first > paragraph of the "Security Considerations" section in > draft-montemurro-gsma-imei-uri by adding: >=20 > Further, because IMEIs can generally be correlated to a user, > they should be treated as any other personally identifiable > information. In particular, the IMEI SHOULD NOT be included in > messages intended to convey any level of anonymity. > Further, because IMEIs can loosely be correlated to a user, > they should be treated as any other personally identifiable > information. In particular, the IMEI SHOULD NOT be included in > messages intended to convey any level of anonymity. Though this text preserves the illusion that IMEI-based instance-ids are somehow more privacy-invasive than other types of instance-id. Whereas an instance-id *must* be correlated to a UA (and thus a user) to be of any use. So we should replace "IMEI" with "instance-id" in the above paragraph. > The other major outstanding issue is interoperability. The main issue, I > believe, is whether you will end up with systems that only accept IMEI > URNs when use of the protocol in a broader context requires the use of > general URNs or even URIs. >=20 > The "Community considerations" section of draft-montemurro-gsma-imei-uri > currently deals exclusively with the ability for general-purpose > Internet implementations to deal with 3GPP-specific identifiers. We need > text that addresses the complementary issue of 3GPP implementations > dealing with general-purpose Internet identifiers. >=20 > I would propose adding text to the end of this section, along the lines o= f: >=20 > Conversely, Internet implementations will not generally posses > IMEI identifiers. The identifiers generated by such implementations > will typically be URNs within namespaces other than "gsma," and > may, depending on context, even be non-URN URIs. Implementations > are advised to correctly process URIs other than "gsma"-namespaced > URNs, so as to aid in interoperability. That makes sense, but I'm curious about the umbrella statement under which the "community considerations" are written: Many of these protocols require the use of URN's as identifiers. I don't know of *any* end-to-end protocols that require the use of URN's as identifiers, with the sole exception of SIP registration. Does anyone have any other examples? Dale From dworley@avaya.com Thu Nov 10 09:10:23 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B5F21F8B53 for ; Thu, 10 Nov 2011 09:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.044 X-Spam-Level: X-Spam-Status: No, score=-103.044 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbPFLRqU7oRR for ; Thu, 10 Nov 2011 09:10:22 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 354EF21F8B57 for ; Thu, 10 Nov 2011 09:10:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowIANcEvE6HCzI1/2dsb2JhbABEqid+B4F5EihRARUpQicEChEaoByEFZt0iRtjBIgPkXCMPA X-IronPort-AV: E=Sophos;i="4.69,489,1315195200"; d="scan'208";a="276933326" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Nov 2011 12:07:48 -0500 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 10 Nov 2011 11:56:43 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 10 Nov 2011 12:07:47 -0500 From: "Worley, Dale R (Dale)" To: "dispatch@ietf.org" Date: Thu, 10 Nov 2011 12:06:51 -0500 Thread-Topic: Expanded dialog/session example Thread-Index: AQHMn8tE+dGYgecuGkWWEZTXG782yg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Expanded dialog/session example X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 17:10:23 -0000 1. Alice calls Bob. This call goes through an SBC, a B2BUA on the boundary between two administrative domains which desires to minimize the passage of signaling events between the domains. Thus, there are two dialogs, Alice-SBC and SBC-Bob. 2. Alice places the call on hold. Alice's UA creates a dialog Alice-MOH-1 with the music-on-hold server, and uses 3PCC techniques (SDP relaying) to cause MOH to send its RTP to the far end of Alice-SBC (that is, the SBC), which then relays it to Bob. 3. Alice takes the call off hold. Alice's UA terminates the dialog Alice-MOH-1, and updates the SDP of Alice-SBC so media is sent to/from Alice's UA. 4. Alice wants to do an attended transfer of the call to Carol. She puts the dialog with Bob on hold. Alice's UA creates a new dialog Alice-MOH-2 with the music-on-hold server, and uses 3PCC techniques (SDP relaying) to cause MOH to send its RTP to the far end of Alice-SBC (that is, the SBC), which then relays it to Bob. 5. Alice's UA initiates a call to sip:carol. This call forks to two UAs. Carol answers the call on one UA, creating the dialog Alice-Carol. 6. Dave answers the call on the other UA, creating a dialog Alice-Dave (which has the same Call-Id as Alice-Carol, but a different to-tag). 7. Alice ends the Alice-Dave dialog, because she does not want to transfer the call with Bob to Dave. 8. Alice executes the transfer between the calls to Bob (Alice-SBC) and Carol (Alice-Carol), by sending a REFER to Carol specifying SBC's contact URI with a Replaces header-parameter identifying Alice-SBC. 9. Carol's UA sends an INVITE to SBC, creating a dialog Carol-SBC. The dialog Carol-SBC replaces the dialog Carol-Alice on Carol's UA interface. 10. The SBC "shortstops" the INVITE-with-Replaces, changing its relaying so that SBC-Bob relays to/from Carol-SBC rather than Alice-SBC. The dialog SBC-Bob continues. 11. The dialogs Alice-SBC and Alice-Carol are terminated by one or both of their UAs. Alice's UA terminates Alice-MOH-2. 12. Carol places the call on hold. Carol's UA creates a dialog Carol-MOH with the same music-on-hold server that Alice used, and uses 3PCC techniques (SDP relaying) to cause MOH to send its RTP to the far end of Carol-SBC (that is, the SBC), which then relays it to Bob. Eight dialogs are created: Alice-SBC SBC-Bob Alice-MOH-1 Alice-MOH-2 Alice-Carol Alice-Dave Carol-SBC Carol-MOH How do the "sessions" group the dialogs? Does any dialog change its session association over time? Which elements assign session identifiers based on what criteria, and how do those identifiers get communicated to the other elements? Dale "In cooperation with an intelligent joiner I would undertake to defeat any definition of chair or chairishness that you gave me." -- H. G. Wells, "A Modern Utopia" From jmpolk@cisco.com Thu Nov 10 14:12:03 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFBE21F8A7E for ; Thu, 10 Nov 2011 14:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.23 X-Spam-Level: X-Spam-Status: No, score=-106.23 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSI47H3BhbhL for ; Thu, 10 Nov 2011 14:12:02 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C52D121F8A7D for ; Thu, 10 Nov 2011 14:12:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=5520; q=dns/txt; s=iport; t=1320963122; x=1322172722; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=i5ScACsshfnG4iikjLQDWfXK+0kCLzP06eeOIXJczaU=; b=NxNtvMRMHzCMcWh5uHp74RcV+C0OcLUm9/hCGa1A0Vo+adOOKFJtZ+tL y+epPun6Sln0CldiTgd6XE4VICN+xDMOAFZouTHG4ape8+HF2bNCSlmDL 6siKmkferziVxJ/kKs9Y8meo2CkI9cxIdo0Ze6b5zacCM89juyH7PL1lr U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJ9LvE6rRDoG/2dsb2JhbABEqiyBBYFyAQEBAQIBAQEBDwEUEQI0EAsHBBgeEBkOMAYBCQkih2AImWwBnkkEiRtjBIgPni0 X-IronPort-AV: E=Sophos;i="4.69,490,1315180800"; d="scan'208";a="13542621" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 10 Nov 2011 22:12:01 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8713.cisco.com [10.99.80.20]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAAMC1bB004554; Thu, 10 Nov 2011 22:12:01 GMT Message-Id: <201111102212.pAAMC1bB004554@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 Nov 2011 16:11:58 -0600 To: "Worley, Dale R (Dale)" , "dispatch@ietf.org" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dispatch] Expanded dialog/session example X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 22:12:03 -0000 At 11:06 AM 11/10/2011, Worley, Dale R (Dale) wrote: >1. Alice calls Bob. This call goes through an SBC, a B2BUA on the >boundary between two administrative domains which desires to minimize >the passage of signaling events between the domains. Thus, there are >two dialogs, Alice-SBC and SBC-Bob. > >2. Alice places the call on hold. Alice's UA creates a dialog >Alice-MOH-1 with the music-on-hold server, and uses 3PCC techniques >(SDP relaying) to cause MOH to send its RTP to the far end of >Alice-SBC (that is, the SBC), which then relays it to Bob. > >3. Alice takes the call off hold. Alice's UA terminates the dialog >Alice-MOH-1, and updates the SDP of Alice-SBC so media is sent to/from >Alice's UA. > >4. Alice wants to do an attended transfer of the call to Carol. She >puts the dialog with Bob on hold. Alice's UA creates a new dialog >Alice-MOH-2 with the music-on-hold server, and uses 3PCC techniques >(SDP relaying) to cause MOH to send its RTP to the far end of >Alice-SBC (that is, the SBC), which then relays it to Bob. > >5. Alice's UA initiates a call to sip:carol. This call forks to two >UAs. Carol answers the call on one UA, creating the dialog >Alice-Carol. > >6. Dave answers the call on the other UA, creating a dialog Alice-Dave >(which has the same Call-Id as Alice-Carol, but a different to-tag). > >7. Alice ends the Alice-Dave dialog, because she does not want to >transfer the call with Bob to Dave. > >8. Alice executes the transfer between the calls to Bob (Alice-SBC) >and Carol (Alice-Carol), by sending a REFER to Carol specifying SBC's >contact URI with a Replaces header-parameter identifying Alice-SBC. > >9. Carol's UA sends an INVITE to SBC, creating a dialog Carol-SBC. >The dialog Carol-SBC replaces the dialog Carol-Alice on Carol's UA >interface. > >10. The SBC "shortstops" the INVITE-with-Replaces, changing its >relaying so that SBC-Bob relays to/from Carol-SBC rather than >Alice-SBC. The dialog SBC-Bob continues. > >11. The dialogs Alice-SBC and Alice-Carol are terminated by one or both >of their UAs. Alice's UA terminates Alice-MOH-2. > >12. Carol places the call on hold. Carol's UA creates a dialog >Carol-MOH with the same music-on-hold server that Alice used, and uses >3PCC techniques (SDP relaying) to cause MOH to send its RTP to the far >end of Carol-SBC (that is, the SBC), which then relays it to Bob. > >Eight dialogs are created: > Alice-SBC > SBC-Bob the above two dialogs would use 1 Session-ID When Alice call gets diverted or transferred to another UA (Carol, Dave or MOH1 or MOH2) she retains her half of the same Session-ID, but since each far end UA is different, the *whole* Session-ID would be different for each combination of UAs > Alice-MOH-1 > Alice-MOH-2 > Alice-Carol > Alice-Dave > Carol-SBC Once the Alice to Carol Session-ID is constructed, it traverses B2BUAs and SBCs without changing, which is unlike what happens to Dialog IDs (and Call-IDs). > Carol-MOH In other words, once Alice (using Session-ID 'A') creates a session (through any type of SIP server) with Bob (using Session-ID 'B'), each retains use of that Session-ID half even if the session is transferred to another entity (to Carol using Session-ID 'C', or MOH-1 server using Session-ID '1') (and so on...). Thus, you get these Session-IDs: Alice to Bob -> whole Session-ID = AB Alice to MOH-1 -> whole Session-ID = A1 Alice to Carol -> whole Session-ID = AC Alice to Dave -> whole Session-ID = AD And if Bob is transferred by Alice to Carol or Dave, but first has a session with MOH-2, it would be either Bob to MOH-2 -> whole Session-ID = B2 then Bob to Carol -> whole Session-ID = BC or Bob to MOH-2 -> whole Session-ID = B2 then Bob to Dave -> whole Session-ID = BD I admit I haven't covered every one of your 12 example scenarios, but this comes close to all of them. I hope you get the idea from this, and can fill in the rest. >How do the "sessions" group the dialogs? Does any dialog change its >session association over time? >Which elements assign session identifiers I think this is either within the UA for user or MOH server (which is a UA), or if a B2BUA controls much of what UAs do (as is the case in most enterprise environments - it's the B2BUA that assigns or creates the Session-ID half for each UA on their side of the session. >based on what criteria, This would be what the new Session-ID WG would decide, but I imagine it would/might include: - one for every new (media) dialog (I'm not sure SUB/NOT needs this, but there could be viable use-cases. - might depend on who this UA is bringing up a session with. - etc... >and how do those identifiers get communicated to the other elements? This would be what the new Session-ID WG would decide, but I imagine it would be in a new SIP "Session-ID" header. Some of this I could be wrong, but other parts - this is the proposal. Comments? James >Dale > >"In cooperation with an intelligent joiner I would undertake to defeat >any definition of chair or chairishness that you gave me." >-- H. G. Wells, "A Modern Utopia" >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From dworley@avaya.com Thu Nov 10 15:23:18 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F5A21F8ACC for ; Thu, 10 Nov 2011 15:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.843 X-Spam-Level: X-Spam-Status: No, score=-102.843 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEfZ7HEDv9N8 for ; Thu, 10 Nov 2011 15:23:18 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id E31F321F8A80 for ; Thu, 10 Nov 2011 15:23:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACBbvE6HCzI1/2dsb2JhbABEqiyBBYFyAQEBAQIBEihECwIBCA0IIRAyJQEBBAESCBqHYJ1Cm1qJG2MEiA+RcIw8 X-IronPort-AV: E=Sophos;i="4.69,490,1315195200"; d="scan'208";a="217332950" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 Nov 2011 18:23:17 -0500 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 10 Nov 2011 18:12:12 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 10 Nov 2011 18:23:16 -0500 From: "Worley, Dale R (Dale)" To: "James M. Polk" , "dispatch@ietf.org" Date: Thu, 10 Nov 2011 18:21:35 -0500 Thread-Topic: [dispatch] Expanded dialog/session example Thread-Index: Acyf9cbzWxsg1PbnQgyappoxRcbOpQACbXA4 Message-ID: References: , <201111102212.pAAMC1bB004554@mtv-core-1.cisco.com> In-Reply-To: <201111102212.pAAMC1bB004554@mtv-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Expanded dialog/session example X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 23:23:18 -0000 > From: James M. Polk [jmpolk@cisco.com] >=20 > I admit I haven't covered every one of your 12 example scenarios, but > this comes close to all of them. I hope you get the idea from this, > and can fill in the rest. Now, you don't get to cheat and say "And the rest can be filled in similarly", because the whole point of the exercise is to verify that a proposed system can handle all of the ugly cases. If you skip a case, you're admitting you don't know how to handle it. Dale From pkyzivat@alum.mit.edu Thu Nov 10 15:47:04 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9871F0C5B for ; Thu, 10 Nov 2011 15:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1H43hPpam+OF for ; Thu, 10 Nov 2011 15:47:02 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 93FC61F0C5D for ; Thu, 10 Nov 2011 15:47:02 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta09.westchester.pa.mail.comcast.net with comcast id vZXB1h0051YDfWL59bn28d; Thu, 10 Nov 2011 23:47:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id vbn21h01T07duvL3gbn2o6; Thu, 10 Nov 2011 23:47:02 +0000 Message-ID: <4EBC6273.8010500@alum.mit.edu> Date: Thu, 10 Nov 2011 18:46:59 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <201111102212.pAAMC1bB004554@mtv-core-1.cisco.com> In-Reply-To: <201111102212.pAAMC1bB004554@mtv-core-1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Expanded dialog/session example X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 23:47:04 -0000 James, We need to refine this to an operational model that each device can follow to get an expected result, such as you outline. Trying to fill that in below: On 11/10/11 5:11 PM, James M. Polk wrote: > At 11:06 AM 11/10/2011, Worley, Dale R (Dale) wrote: >> 1. Alice calls Bob. This call goes through an SBC, a B2BUA on the >> boundary between two administrative domains which desires to minimize >> the passage of signaling events between the domains. Thus, there are >> two dialogs, Alice-SBC and SBC-Bob. Alice sends an ID of A* toward Bob via the SBC SBC propagates A* to Bob Bob returns an ID of AB toward Alice via the SBC The SBC propagates AB to Alice >> 2. Alice places the call on hold. Alice's UA creates a dialog >> Alice-MOH-1 with the music-on-hold server, and uses 3PCC techniques >> (SDP relaying) to cause MOH to send its RTP to the far end of >> Alice-SBC (that is, the SBC), which then relays it to Bob. Alice sends an ID of A* toward MOH-1. (Why not a new one? There must be logic that decides this is part of the same session.) MOH-1 returns an ID of A1 to Alice Alice then sends a reinvite with new offer toward Bob, with the SDP from MOH-1, but *does not* change the ID. (What logic determines when to do this and when not?) >> 3. Alice takes the call off hold. Alice's UA terminates the dialog >> Alice-MOH-1, and updates the SDP of Alice-SBC so media is sent to/from >> Alice's UA. Not so interesting if the ID was not changed above. (It still isn't changed here.) >> 4. Alice wants to do an attended transfer of the call to Carol. She >> puts the dialog with Bob on hold. Alice's UA creates a new dialog >> Alice-MOH-2 with the music-on-hold server, and uses 3PCC techniques >> (SDP relaying) to cause MOH to send its RTP to the far end of >> Alice-SBC (that is, the SBC), which then relays it to Bob. Alice sends an ID of A* toward MOH-2. (Why not a new one? There must be logic that decides this is part of the same session.) MOH-2 returns an ID of A2 to Alice Alice then sends a reinvite with new offer toward Bob, with the SDP from MOH-2, but *does not* change the ID. (What logic determines when to do this and when not?) >> 5. Alice's UA initiates a call to sip:carol. This call forks to two >> UAs. Carol answers the call on one UA, creating the dialog >> Alice-Carol. Alice sends an ID of A* toward Carol. (Why not a new one? There must be logic that decides this is part of the same session.) Carol returns an ID of AC to Alice. >> 6. Dave answers the call on the other UA, creating a dialog Alice-Dave >> (which has the same Call-Id as Alice-Carol, but a different to-tag). Dave returns an ID of AD to Alice. >> 7. Alice ends the Alice-Dave dialog, because she does not want to >> transfer the call with Bob to Dave. Not interesting. >> 8. Alice executes the transfer between the calls to Bob (Alice-SBC) >> and Carol (Alice-Carol), by sending a REFER to Carol specifying SBC's >> contact URI with a Replaces header-parameter identifying Alice-SBC. Don't think there is anything interesting here. >> 9. Carol's UA sends an INVITE to SBC, creating a dialog Carol-SBC. >> The dialog Carol-SBC replaces the dialog Carol-Alice on Carol's UA >> interface. Carol sends and ID of C* toward Bob via Alice's SBC. (I guess it knows to use C rather than a new id because this is a Replaces of a dialog that has C as Carol's part of the ID.) >> 10. The SBC "shortstops" the INVITE-with-Replaces, changing its >> relaying so that SBC-Bob relays to/from Carol-SBC rather than >> Alice-SBC. The dialog SBC-Bob continues. The SBC has to return *something* as the ID back to Carol. I guess it could return CB because this is resplicing the existing AB session, replacing A. But unless the SBC sends a new ID to Bob, he will still think it is AB. So maybe the SBC must send a reinvite to Bob with CB as the ID, using similar logic to above. (It might need this anyway if it doesn't want to terminate and relay the media.) >> 11. The dialogs Alice-SBC and Alice-Carol are terminated by one or both >> of their UAs. Alice's UA terminates Alice-MOH-2. Not interesting. >> 12. Carol places the call on hold. Carol's UA creates a dialog >> Carol-MOH with the same music-on-hold server that Alice used, and uses >> 3PCC techniques (SDP relaying) to cause MOH to send its RTP to the far >> end of Carol-SBC (that is, the SBC), which then relays it to Bob. Nothing new here. There are some key things to work out: - When a UA is making multiple calls, when does it use a common value for its half of the ID, and when does it use a different one? This seems to depend on knowing whether the "new" call is to be part of an existing call, or not. The MOH call should be clear in this regard. But the call to Carol in step 4 is not so clear. In some common phone UIs, at the time the call to Carol is made the phone doesn't know if this is for a transfer, or is an independent call. That isn't known until later. - When should a B2BUA form a new ID from parts of existing ones, and when should it not? There are probably more such issues. Thanks, Paul >> Eight dialogs are created: >> Alice-SBC >> SBC-Bob > > the above two dialogs would use 1 Session-ID > > When Alice call gets diverted or transferred to another UA (Carol, Dave > or MOH1 or MOH2) she retains her half of the same Session-ID, but since > each far end UA is different, the *whole* Session-ID would be different > for each combination of UAs > >> Alice-MOH-1 >> Alice-MOH-2 >> Alice-Carol >> Alice-Dave >> Carol-SBC > > Once the Alice to Carol Session-ID is constructed, it traverses B2BUAs > and SBCs without changing, which is unlike what happens to Dialog IDs > (and Call-IDs). > >> Carol-MOH > > In other words, once Alice (using Session-ID 'A') creates a session > (through any type of SIP server) with Bob (using Session-ID 'B'), each > retains use of that Session-ID half even if the session is transferred > to another entity (to Carol using Session-ID 'C', or MOH-1 server using > Session-ID '1') (and so on...). > > Thus, you get these Session-IDs: > > Alice to Bob -> whole Session-ID = AB > Alice to MOH-1 -> whole Session-ID = A1 > Alice to Carol -> whole Session-ID = AC > Alice to Dave -> whole Session-ID = AD > > And if Bob is transferred by Alice to Carol or Dave, but first has a > session with MOH-2, it would be either > > Bob to MOH-2 -> whole Session-ID = B2 then > Bob to Carol -> whole Session-ID = BC > > or > > Bob to MOH-2 -> whole Session-ID = B2 then > Bob to Dave -> whole Session-ID = BD > > I admit I haven't covered every one of your 12 example scenarios, but > this comes close to all of them. I hope you get the idea from this, and > can fill in the rest. > > > >> How do the "sessions" group the dialogs? Does any dialog change its >> session association over time? > >> Which elements assign session identifiers > > I think this is either within the UA for user or MOH server (which is a > UA), or if a B2BUA controls much of what UAs do (as is the case in most > enterprise environments - it's the B2BUA that assigns or creates the > Session-ID half for each UA on their side of the session. > >> based on what criteria, > > This would be what the new Session-ID WG would decide, but I imagine it > would/might include: > > - one for every new (media) dialog (I'm not sure > SUB/NOT needs this, but there could be viable > use-cases. > > - might depend on who this UA is bringing up a > session with. > > - etc... > >> and how do those identifiers get communicated to the other elements? > > This would be what the new Session-ID WG would decide, but I imagine it > would be in a new SIP "Session-ID" header. > > Some of this I could be wrong, but other parts - this is the proposal. > > Comments? > > James > > >> Dale >> >> "In cooperation with an intelligent joiner I would undertake to defeat >> any definition of chair or chairishness that you gave me." >> -- H. G. Wells, "A Modern Utopia" >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From jmpolk@cisco.com Thu Nov 10 16:12:54 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57921F0C5C for ; Thu, 10 Nov 2011 16:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.517 X-Spam-Level: X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnW+dIoOZ0Tu for ; Thu, 10 Nov 2011 16:12:54 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF341F0C5B for ; Thu, 10 Nov 2011 16:12:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=3364; q=dns/txt; s=iport; t=1320970374; x=1322179974; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=L3t+V4BaCWCZOLFkuGUhS0LvrgY05i4Atzjr8V3sQdQ=; b=dlymRqpPYzxf62PiG026CvLzBq1aqqMlBHh5SkHHhWELTIOmxWU5OhdK EkMJfo/VlPvWuiD2Tz/ATUuB3VKA0FLRIr0l0hjWS80BYnyoQArRHAOHR Bs+gdKedlUk5gnaETT9GhJq82lumnZxWn/3gsLUkrrWB2ICLqnkTMtZlB U=; X-IronPort-AV: E=Sophos;i="4.69,491,1315180800"; d="scan'208";a="13549696" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 11 Nov 2011 00:12:54 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8713.cisco.com [10.99.80.20]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAB0Cr0c013093; Fri, 11 Nov 2011 00:12:53 GMT Message-Id: <201111110012.pAB0Cr0c013093@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 Nov 2011 18:12:50 -0600 To: "Worley, Dale R (Dale)" , "James M. Polk" , "dispatch@ietf.org" From: "James M. Polk" In-Reply-To: References: <201111102212.pAAMC1bB004554@mtv-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dispatch] Expanded dialog/session example X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 00:12:55 -0000 At 05:21 PM 11/10/2011, Worley, Dale R (Dale) wrote: > > From: James M. Polk [jmpolk@cisco.com] > > > > I admit I haven't covered every one of your 12 example scenarios, but > > this comes close to all of them. I hope you get the idea from this, > > and can fill in the rest. > >Now, you don't get to cheat and say "And the rest can be filled in >similarly", because the whole point of the exercise is to verify that >a proposed system can handle all of the ugly cases. If you skip a >case, you're admitting you don't know how to handle it. well - this certainly isn't true, I just left out the order and the interaction with MOH-2 I think. So, to cover this (for you and others, but knowing this certainly isn't going to be the last time I or someone else needs to cover this exact topic ;-). I'll order the 12 for you, as long as you allow the same Session-ID construction to continue as each creates or provides each half of the overall Session-ID, as follows: Alice's half Session-ID = 'A' Bob's half Session-ID = 'B' Carol's 1st UA half Session-ID = 'Cc' Carol's 2nd UA half Session-ID = 'Ccc' Dave's half Session-ID = 'D' MOH-1's half Session-ID = '1' MOH-2's half Session-ID = '2' 1. = AB from Alice to Bob (regardless of SIP servers) 2. = A1 to Alice, 1B to Bob 3. = "...so media to/from Alice's UA" and what? You don't say. Though if Bob, this goes back to AB 4. = 2B (if I understand you correctly). IOW, it's 2B if the RTP is between Bob and MOH-2. 5. = ACc 6. = ACcc - but here you have two forked UAs answering the same call from Alice. Isn't the forking proxy supposed to kill the latter of these sessions (i.e., a second 200 OK causes a BYE from the forking proxy?) 7. = "Alice ends the Alice-Dave dialog" why isn't that a BYE? If so, why are you proposing to send Dave to Bob? Terminating a dialog terminates the Session-ID; but I'm not sure where you're going here. 8. = BCc 9. = In step 8, Alice REFER'd Bob to Carol, thereby removing Alice from any dialogs, and therefore any Session-IDs (if I'm following you correctly. 10. = SBCs have no affect on the Session-ID construction, and as Bob and Carol are already talking to each other from step 8, there is no Session-ID to give here; BCc remains up. 11. = the ACcc was terminated in step 7. The ACc was transferred to BCc in step 8, so there is no Alice-SBC anything at this point. I don't see where "Alice's UA terminates Alice-MOH-2" can happen because A2 was never up, unless it occurred in step 4. If you propose that it was in step 4, then how did Alice discover the Alice-Carol was forked to both Carol and (specifically) Dave (that she didn't want Bob to talk to in step 7)? Wouldn't see have had to talk to Dave to know it was him? At the end of the day, when you put Alice-SBC and Carol-SBC you seem to think this is a full Session-ID and it is not. 12. = Carol to MOH (which? server-1 or server-2) would be either Cc1 or Cc2. Bob to MOH (which? server-1 or server-2) would be either B1 or B2. I can't tell which at this point you want it to be to. no cheating... comments? James >Dale From jmpolk@cisco.com Thu Nov 10 16:30:41 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E567A1F0C5F for ; Thu, 10 Nov 2011 16:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.221 X-Spam-Level: X-Spam-Status: No, score=-106.221 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13Z7ELPJYKtS for ; Thu, 10 Nov 2011 16:30:40 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E98E81F0C5A for ; Thu, 10 Nov 2011 16:30:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=9694; q=dns/txt; s=iport; t=1320971440; x=1322181040; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=wu8qZrI+fl5r//861v8AwDfgxfcePJ4R5xQSYLwQfgU=; b=QVrfUKp4PrthiENZcTyTW5Ezar65+9HDwcQhYG5KpM7cV2JSjWq/quFI 7wyPpUwcd0j3/uRGEs791qj0gbdkn7sjRDJyUuM+b6dDQkN4QyN0oDI+/ 8P9qwLgYbE9SKTFDFo+Gm9a3osJ81jLSZ9Y1aeMM+4YxJARvkHnBeNCu0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJtrvE6rRDoG/2dsb2JhbABEDqoegQWBcgEBAQEDAQEBDwEUEQI0GwcEDgoeEBkOMAYBCQkih2iaPwGeRwSJG2MEiA+dV1Y X-IronPort-AV: E=Sophos;i="4.69,491,1315180800"; d="scan'208";a="13545662" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 11 Nov 2011 00:30:40 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8713.cisco.com [10.99.80.20]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAB0UdkF009249; Fri, 11 Nov 2011 00:30:40 GMT Message-Id: <201111110030.pAB0UdkF009249@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 Nov 2011 18:30:38 -0600 To: Paul Kyzivat , dispatch@ietf.org From: "James M. Polk" In-Reply-To: <4EBC6273.8010500@alum.mit.edu> References: <201111102212.pAAMC1bB004554@mtv-core-1.cisco.com> <4EBC6273.8010500@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dispatch] Expanded dialog/session example X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 00:30:42 -0000 Paul While I can appreciate what you are asking for, it seems like Dale's example (perhaps minus the few small errors I found in it, or just misunderstandings in it) would pretty much solve 80-90-95-99% of the problem space. Do you want me to accomplish all that in one email? (of course you would, it would make everything easy!) ;-) Seriously - review the note I just send that did go through 12 steps (hmmm, a 12 step program... I wonder if that was a consciously determined number of steps), and let me know if and where I'm wet behind the ears. I think that if I satisfy everyone with this 12 step problem, the WG (if it becomes a WG) will have little more to do than the ABNF... (I'm only half kidding, and with someone else kidding that will make a fully Session-ID of kidding). I couldn't help myself, sorry James At 05:46 PM 11/10/2011, Paul Kyzivat wrote: >James, > >We need to refine this to an operational model that each device can >follow to get an expected result, such as you outline. Trying to >fill that in below: > >On 11/10/11 5:11 PM, James M. Polk wrote: >>At 11:06 AM 11/10/2011, Worley, Dale R (Dale) wrote: >>>1. Alice calls Bob. This call goes through an SBC, a B2BUA on the >>>boundary between two administrative domains which desires to minimize >>>the passage of signaling events between the domains. Thus, there are >>>two dialogs, Alice-SBC and SBC-Bob. > >Alice sends an ID of A* toward Bob via the SBC >SBC propagates A* to Bob >Bob returns an ID of AB toward Alice via the SBC >The SBC propagates AB to Alice > >>>2. Alice places the call on hold. Alice's UA creates a dialog >>>Alice-MOH-1 with the music-on-hold server, and uses 3PCC techniques >>>(SDP relaying) to cause MOH to send its RTP to the far end of >>>Alice-SBC (that is, the SBC), which then relays it to Bob. > >Alice sends an ID of A* toward MOH-1. >(Why not a new one? There must be logic that decides this is part of >the same session.) >MOH-1 returns an ID of A1 to Alice >Alice then sends a reinvite with new offer toward Bob, >with the SDP from MOH-1, but *does not* change the ID. >(What logic determines when to do this and when not?) > >>>3. Alice takes the call off hold. Alice's UA terminates the dialog >>>Alice-MOH-1, and updates the SDP of Alice-SBC so media is sent to/from >>>Alice's UA. > >Not so interesting if the ID was not changed above. >(It still isn't changed here.) > >>>4. Alice wants to do an attended transfer of the call to Carol. She >>>puts the dialog with Bob on hold. Alice's UA creates a new dialog >>>Alice-MOH-2 with the music-on-hold server, and uses 3PCC techniques >>>(SDP relaying) to cause MOH to send its RTP to the far end of >>>Alice-SBC (that is, the SBC), which then relays it to Bob. > >Alice sends an ID of A* toward MOH-2. >(Why not a new one? There must be logic that decides this is part of >the same session.) >MOH-2 returns an ID of A2 to Alice >Alice then sends a reinvite with new offer toward Bob, >with the SDP from MOH-2, but *does not* change the ID. >(What logic determines when to do this and when not?) > >>>5. Alice's UA initiates a call to sip:carol. This call forks to two >>>UAs. Carol answers the call on one UA, creating the dialog >>>Alice-Carol. > >Alice sends an ID of A* toward Carol. >(Why not a new one? There must be logic that decides this is part of >the same session.) >Carol returns an ID of AC to Alice. > >>>6. Dave answers the call on the other UA, creating a dialog Alice-Dave >>>(which has the same Call-Id as Alice-Carol, but a different to-tag). > >Dave returns an ID of AD to Alice. > >>>7. Alice ends the Alice-Dave dialog, because she does not want to >>>transfer the call with Bob to Dave. > >Not interesting. > >>>8. Alice executes the transfer between the calls to Bob (Alice-SBC) >>>and Carol (Alice-Carol), by sending a REFER to Carol specifying SBC's >>>contact URI with a Replaces header-parameter identifying Alice-SBC. > >Don't think there is anything interesting here. > >>>9. Carol's UA sends an INVITE to SBC, creating a dialog Carol-SBC. >>>The dialog Carol-SBC replaces the dialog Carol-Alice on Carol's UA >>>interface. > >Carol sends and ID of C* toward Bob via Alice's SBC. >(I guess it knows to use C rather than a new id because this is a >Replaces of a dialog that has C as Carol's part of the ID.) > >>>10. The SBC "shortstops" the INVITE-with-Replaces, changing its >>>relaying so that SBC-Bob relays to/from Carol-SBC rather than >>>Alice-SBC. The dialog SBC-Bob continues. > >The SBC has to return *something* as the ID back to Carol. >I guess it could return CB because this is resplicing the existing >AB session, replacing A. > >But unless the SBC sends a new ID to Bob, he will still think it is AB. >So maybe the SBC must send a reinvite to Bob with CB as the ID, >using similar logic to above. (It might need this anyway if it >doesn't want to terminate and relay the media.) > >>>11. The dialogs Alice-SBC and Alice-Carol are terminated by one or both >>>of their UAs. Alice's UA terminates Alice-MOH-2. > >Not interesting. > >>>12. Carol places the call on hold. Carol's UA creates a dialog >>>Carol-MOH with the same music-on-hold server that Alice used, and uses >>>3PCC techniques (SDP relaying) to cause MOH to send its RTP to the far >>>end of Carol-SBC (that is, the SBC), which then relays it to Bob. > >Nothing new here. > >There are some key things to work out: > >- When a UA is making multiple calls, when does it use a common > value for its half of the ID, and when does it use a different one? > This seems to depend on knowing whether the "new" call is to be > part of an existing call, or not. The MOH call should be clear > in this regard. But the call to Carol in step 4 is not so clear. > In some common phone UIs, at the time the call to Carol is made > the phone doesn't know if this is for a transfer, or is an > independent call. That isn't known until later. > >- When should a B2BUA form a new ID from parts of existing ones, > and when should it not? > >There are probably more such issues. > > Thanks, > Paul > >>>Eight dialogs are created: >>>Alice-SBC >>>SBC-Bob >> >>the above two dialogs would use 1 Session-ID >> >>When Alice call gets diverted or transferred to another UA (Carol, Dave >>or MOH1 or MOH2) she retains her half of the same Session-ID, but since >>each far end UA is different, the *whole* Session-ID would be different >>for each combination of UAs >> >>>Alice-MOH-1 >>>Alice-MOH-2 >>>Alice-Carol >>>Alice-Dave >>>Carol-SBC >> >>Once the Alice to Carol Session-ID is constructed, it traverses B2BUAs >>and SBCs without changing, which is unlike what happens to Dialog IDs >>(and Call-IDs). >> >>>Carol-MOH >> >>In other words, once Alice (using Session-ID 'A') creates a session >>(through any type of SIP server) with Bob (using Session-ID 'B'), each >>retains use of that Session-ID half even if the session is transferred >>to another entity (to Carol using Session-ID 'C', or MOH-1 server using >>Session-ID '1') (and so on...). >> >>Thus, you get these Session-IDs: >> >>Alice to Bob -> whole Session-ID = AB >>Alice to MOH-1 -> whole Session-ID = A1 >>Alice to Carol -> whole Session-ID = AC >>Alice to Dave -> whole Session-ID = AD >> >>And if Bob is transferred by Alice to Carol or Dave, but first has a >>session with MOH-2, it would be either >> >>Bob to MOH-2 -> whole Session-ID = B2 then >>Bob to Carol -> whole Session-ID = BC >> >>or >> >>Bob to MOH-2 -> whole Session-ID = B2 then >>Bob to Dave -> whole Session-ID = BD >> >>I admit I haven't covered every one of your 12 example scenarios, but >>this comes close to all of them. I hope you get the idea from this, and >>can fill in the rest. >> >> >> >>>How do the "sessions" group the dialogs? Does any dialog change its >>>session association over time? >> >>>Which elements assign session identifiers >> >>I think this is either within the UA for user or MOH server (which is a >>UA), or if a B2BUA controls much of what UAs do (as is the case in most >>enterprise environments - it's the B2BUA that assigns or creates the >>Session-ID half for each UA on their side of the session. >> >>>based on what criteria, >> >>This would be what the new Session-ID WG would decide, but I imagine it >>would/might include: >> >>- one for every new (media) dialog (I'm not sure >>SUB/NOT needs this, but there could be viable >>use-cases. >> >>- might depend on who this UA is bringing up a >>session with. >> >>- etc... >> >>>and how do those identifiers get communicated to the other elements? >> >>This would be what the new Session-ID WG would decide, but I imagine it >>would be in a new SIP "Session-ID" header. >> >>Some of this I could be wrong, but other parts - this is the proposal. >> >>Comments? >> >>James >> >> >>>Dale >>> >>>"In cooperation with an intelligent joiner I would undertake to defeat >>>any definition of chair or chairishness that you gave me." >>>-- H. G. Wells, "A Modern Utopia" >>>_______________________________________________ >>>dispatch mailing list >>>dispatch@ietf.org >>>https://www.ietf.org/mailman/listinfo/dispatch >> >>_______________________________________________ >>dispatch mailing list >>dispatch@ietf.org >>https://www.ietf.org/mailman/listinfo/dispatch > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Thu Nov 10 20:57:22 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72F81F0C3D for ; Thu, 10 Nov 2011 20:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDbcLfBC7omW for ; Thu, 10 Nov 2011 20:57:22 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id F36E51F0C54 for ; Thu, 10 Nov 2011 20:57:21 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta09.westchester.pa.mail.comcast.net with comcast id vgx61h0010EZKEL59gxNd9; Fri, 11 Nov 2011 04:57:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta01.westchester.pa.mail.comcast.net with comcast id vgxN1h00107duvL3MgxNVG; Fri, 11 Nov 2011 04:57:22 +0000 Message-ID: <4EBCAB30.6060606@alum.mit.edu> Date: Thu, 10 Nov 2011 23:57:20 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <201111102212.pAAMC1bB004554@mtv-core-1.cisco.com> <201111110012.pAB0Cr0c013093@mtv-core-2.cisco.com> In-Reply-To: <201111110012.pAB0Cr0c013093@mtv-core-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Expanded dialog/session example X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 04:57:23 -0000 James, Its not sufficient to say how you want the ID assignments to end up. You have to explain how they come to be that way. That is what is different about my prior mail. Thanks, Paul On 11/10/11 7:12 PM, James M. Polk wrote: > At 05:21 PM 11/10/2011, Worley, Dale R (Dale) wrote: >> > From: James M. Polk [jmpolk@cisco.com] >> > >> > I admit I haven't covered every one of your 12 example scenarios, but >> > this comes close to all of them. I hope you get the idea from this, >> > and can fill in the rest. >> >> Now, you don't get to cheat and say "And the rest can be filled in >> similarly", because the whole point of the exercise is to verify that >> a proposed system can handle all of the ugly cases. If you skip a >> case, you're admitting you don't know how to handle it. > > well - this certainly isn't true, I just left out the order and the > interaction with MOH-2 I think. > > So, to cover this (for you and others, but knowing this certainly isn't > going to be the last time I or someone else needs to cover this exact > topic ;-). > > I'll order the 12 for you, as long as you allow the same Session-ID > construction to continue as each creates or provides each half of the > overall Session-ID, as follows: > > Alice's half Session-ID = 'A' > Bob's half Session-ID = 'B' > Carol's 1st UA half Session-ID = 'Cc' > Carol's 2nd UA half Session-ID = 'Ccc' > Dave's half Session-ID = 'D' > MOH-1's half Session-ID = '1' > MOH-2's half Session-ID = '2' > > 1. = AB from Alice to Bob (regardless of SIP servers) > 2. = A1 to Alice, 1B to Bob > 3. = "...so media to/from Alice's UA" and what? You don't say. > Though if Bob, this goes back to AB > 4. = 2B (if I understand you correctly). IOW, it's 2B if the > RTP is between Bob and MOH-2. > 5. = ACc > 6. = ACcc - but here you have two forked UAs answering the > same call from Alice. Isn't the forking proxy supposed > to kill the latter of these sessions (i.e., a second > 200 OK causes a BYE from the forking proxy?) > 7. = "Alice ends the Alice-Dave dialog" why isn't that a BYE? > If so, why are you proposing to send Dave to Bob? > Terminating a dialog terminates the Session-ID; but > I'm not sure where you're going here. > 8. = BCc > 9. = In step 8, Alice REFER'd Bob to Carol, thereby removing > Alice from any dialogs, and therefore any Session-IDs > (if I'm following you correctly. > 10. = SBCs have no affect on the Session-ID construction, and > as Bob and Carol are already talking to each other from > step 8, there is no Session-ID to give here; BCc remains > up. > 11. = the ACcc was terminated in step 7. The ACc was > transferred to BCc in step 8, so there is no Alice-SBC > anything at this point. I don't see where "Alice's UA > terminates Alice-MOH-2" can happen because A2 was never > up, unless it occurred in step 4. If you propose that it > was in step 4, then how did Alice discover the Alice-Carol > was forked to both Carol and (specifically) Dave (that > she didn't want Bob to talk to in step 7)? Wouldn't see > have had to talk to Dave to know it was him? > At the end of the day, when you put Alice-SBC and > Carol-SBC you seem to think this is a full Session-ID > and it is not. > 12. = Carol to MOH (which? server-1 or server-2) would be > either Cc1 or Cc2. Bob to MOH (which? server-1 or > server-2) would be either B1 or B2. I can't tell which > at this point you want it to be to. > > no cheating... > > comments? > > James > > > >> Dale > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From samirs.lists@gmail.com Fri Nov 11 00:27:12 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0BE21F846C for ; Fri, 11 Nov 2011 00:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOfhEsJZy0Dj for ; Fri, 11 Nov 2011 00:27:11 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6EA921F846A for ; Fri, 11 Nov 2011 00:27:08 -0800 (PST) Received: by gye5 with SMTP id 5so3177662gye.31 for ; Fri, 11 Nov 2011 00:27:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=HsF84/jbHcM2VmyeOrh6CbJzZ7QI4VfkD/h+sqaqXJA=; b=LU3B8A88n3UMB8pUA70QzBtMEPyF5CKpMp4lkJvoMSBcWiaobzJkyQfLH+KfctRDmu yi/11FzUzrwncujEMFAdKVSv1Cjl6AWUpIfEAAndL0FFY5hCpGuouhlRtcCVHC7FDozl DuhHFyUIgwAfwcFshXM34bOR0gtIMrwLApqZA= MIME-Version: 1.0 Received: by 10.146.54.32 with SMTP id c32mr830392yaa.15.1321000026358; Fri, 11 Nov 2011 00:27:06 -0800 (PST) Received: by 10.236.106.70 with HTTP; Fri, 11 Nov 2011 00:27:06 -0800 (PST) Date: Fri, 11 Nov 2011 00:27:06 -0800 Message-ID: From: Samir Srivastava To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=000e0cd3b8e451c4b704b1714995 Subject: [dispatch] Update on Security etc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 08:27:12 -0000 --000e0cd3b8e451c4b704b1714995 Content-Type: text/plain; charset=ISO-8859-1 Hi I submitted below draft, but didn't hear anything on the list. http://www.ietf.org/id/draft-srivastava-dispatch-avoidance-of-threats-00.txt I got some feedback from my personal invitation, so I am putting it here as the update timeline is closed. 1) Why 3.2 work is brought to IETF as IETF is for concrete protocol development. If 3.2 is acceptable by Technocrats, then it is easier to take to law / policy makers. If proposal doesn't passes the engineering gate, then no point to take to the law/policy makers. So I am seeking the engineeriners feedback to break the ideas with threat scenarios etc. If 3.2 is accepted at the high level, then we need to work on the concrete protocol item A) How to use/extend etc work of SIPREC group for complete multimedia recordings. B) If Cashless Economy work is accepted at the high level, then do we need SIP extensions for Business transactions. There was a draft from Cullen for SIP payment etc as a possible solution for SPAM problem. 2) I am waiting for the acknowldged party to disclose if they know any IPRs etc. If IPR makes this work Controversial for IETF. 3) Complete multimedia Recordings might make "Prision Always" etc. IMHO, recordings are shared after the classification with the consent from concerned parties. Law enforecement folks can look into the recordings after proper legal (as per laws of geographic regions) authorization only, It just makes sure that PRIVACY CANNOT BE MISUSED. 4) If 3.2 fails here then we need to address issues brought to unanswered issues listed in section 2. Regards Samir Srivastava --000e0cd3b8e451c4b704b1714995 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi
=A0
I submitted below draft, but didn't hea= r anything on the list.
=A0
http://www.ie= tf.org/id/draft-srivastava-dispatch-avoidance-of-threats-00.txt

=A0
=A0 I got some feedback from my personal invitation, so = I am=A0putting it here as the update timeline is closed.
=A0
1) Why =A03.2 work is brought to IETF as IETF is for concrete protoco= l development.

=A0
=A0=A0 If 3.2 is acceptable by Technocrats, then it is e= asier to take to law / policy makers. If proposal doesn't passes the en= gineering gate, then =A0no point to take to the law/policy makers. So I am = seeking the engineeriners feedback to break the ideas with threat scenarios= etc.

=A0
=A0 If 3.2 is accepted at the high level, then we need t= o work on the concrete protocol item
=A0 A) How to use/extend etc= work of SIPREC group for complete multimedia recordings.
=A0 B) = If Cashless Economy work is accepted at the high level, then do we need SIP= extensions for Business transactions. There was a draft from Cullen for SI= P payment etc as a possible solution for SPAM problem.

=A0
2) I am waiting for the acknowldged party to disclose if= they know any IPRs etc.=A0 If IPR makes this work Controversial for IETF. =
=A0
3) Complete multimedia Recordings might make "= ;Prision Always" etc. IMHO, recordings are shared after the classifica= tion with the consent from concerned parties. Law enforecement folks can lo= ok into the recordings after proper legal (as per laws of=A0geographic regi= ons) authorization only, It just makes sure that PRIVACY CANNOT BE MISUSED.=

=A0
4) If 3.2 fails here then we need to address issues brou= ght to unanswered issues listed in section 2.
=A0
Regar= ds
Samir Srivastava
=A0
--000e0cd3b8e451c4b704b1714995-- From adam@nostrum.com Fri Nov 11 00:33:43 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F259221F848C for ; Fri, 11 Nov 2011 00:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.531 X-Spam-Level: X-Spam-Status: No, score=-101.531 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJcWnoVJTlt2 for ; Fri, 11 Nov 2011 00:33:42 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5D221F848B for ; Fri, 11 Nov 2011 00:33:42 -0800 (PST) Received: from Svantevit.local (i118-21-136-4.s30.a048.ap.plala.or.jp [118.21.136.4]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pAB8Xcjp046292 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 11 Nov 2011 02:33:40 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4EBC5774.7090102@nostrum.com> Date: Thu, 10 Nov 2011 17:00:04 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com> <4EA6D17C.3050107@nostrum.com> , <4EA70AE7.6050007@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 118.21.136.4 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 08:33:43 -0000 On 11/9/11 4:35 PM, Worley, Dale R (Dale) wrote: >> From: Adam Roach [adam@nostrum.com] >> >> In the spirit of "send text," I would propose extending the first >> paragraph of the "Security Considerations" section in >> draft-montemurro-gsma-imei-uri by adding: >> >> ... >> Further, because IMEIs can loosely be correlated to a user, >> they should be treated as any other personally identifiable >> information. In particular, the IMEI SHOULD NOT be included in >> messages intended to convey any level of anonymity. > Though this text preserves the illusion that IMEI-based instance-ids > are somehow more privacy-invasive than other types of instance-id. > Whereas an instance-id *must* be correlated to a UA (and thus a user) > to be of any use. So we should replace "IMEI" with "instance-id" in > the above paragraph. If you'd like, sure. But there's a reason it's coming up now and didn't before. In the past, I don't think anyone would have ever dreamed of sending an instance ID in an INVITE request. They're used for outbound and GRUU, and only appear in REGISTER messages. What happened here is that Ricky Kaura's message of February 2nd, 2011 made it clear that 3GPP has specified the unprecedented and unanticipated inclusion of instance IDs in INVITE. This inclusion has some potentially chilling privacy implications, and I haven't seen any treatment of them anywhere. (I also think this behavior is a bit of an overreach on the part of 3GPP, as it defines new protocol semantics for SIP message components, but I'm not going to get too bent out of shape over that particular jurisdictional transgression). This kind of transmission was never supposed to happen. It simply didn't make any kind of sense. So it never occurred to anyone to discuss the privacy implications of doing so. Now that it has become clear that such transmission will be inherent in some uses of the URNs that these drafts propose, I think it would be irresponsible to omit a discussion of the privacy properties of these identifiers. /a From srivastava_samir@hush.com Fri Nov 11 00:43:06 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E2621F84A5 for ; Fri, 11 Nov 2011 00:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=1.465, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQqflRRV8rXP for ; Fri, 11 Nov 2011 00:43:05 -0800 (PST) Received: from smtp12.hushmail.com (smtp12.hushmail.com [65.39.178.135]) by ietfa.amsl.com (Postfix) with ESMTP id 99B7221F849E for ; Fri, 11 Nov 2011 00:43:05 -0800 (PST) Received: from smtp12.hushmail.com (localhost.localdomain [127.0.0.1]) by smtp12.hushmail.com (Postfix) with SMTP id 27B86C02AA for ; Fri, 11 Nov 2011 08:43:05 +0000 (UTC) X-Hush-Verified-Domain: hush.com Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) by smtp12.hushmail.com (Postfix) with ESMTP for ; Fri, 11 Nov 2011 08:43:03 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 22CA46F442; Fri, 11 Nov 2011 08:43:03 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 11 Nov 2011 00:43:02 -0800 To: dispatch@ietf.org From: srivastava_samir@hush.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20111111084303.22CA46F442@smtp.hushmail.com> Subject: [dispatch] Update On Security (From Secure id) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 08:46:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Excuse if you receive multiple copies. from my list a/c samirs.lists@gmail.com it didn't show up on the ietf.org list server. So resending. I submitted below draft, but didn't hear anything on the list. http://www.ietf.org/id/draft-srivastava-dispatch-avoidance-of- threats-00.txt I got some feedback from my personal invitation, so I am putting it here as the update timeline is closed. 1) Why 3.2 work is brought to IETF as IETF is for concrete protocol development. If 3.2 is acceptable by Technocrats, then it is easier to take to law / policy makers. If proposal doesn't passes the engineering gate, then no point to take to the law/policy makers. So I am seeking the engineeriners feedback to break the ideas with threat scenarios etc. If 3.2 is accepted at the high level, then we need to work on the concrete protocol item A) How to use/extend etc work of SIPREC group for complete multimedia recordings. B) If Cashless Economy work is accepted at the high level, then do we need SIP extensions for Business transactions. There was a draft from Cullen for SIP payment etc as a possible solution for SPAM problem. 2) I am waiting for the acknowldged party to disclose if they know any IPRs etc. If IPR makes this work Controversial for IETF. 3) Complete multimedia Recordings might make "Prision Always" etc. IMHO, recordings are shared after the classification with the consent from concerned parties. Law enforecement folks can look into the recordings after proper legal (as per laws of geographic regions) authorization only, It just makes sure that PRIVACY CANNOT BE MISUSED. 4) If 3.2 fails here then we need to address issues brought to unanswered issues listed in section 2. Regards Samir Srivastava -----BEGIN PGP SIGNATURE----- Charset: UTF8 Version: Hush 3.0 Note: This signature can be verified at https://www.hushtools.com/verify wpwEAQMCAAYFAk684BYACgkQvdot3LfSFCS+GAP7BOu7LRhb9TM2QRb6H/ISFpIYpsKx 2csKv4yXo2hFi564U956LbJFjdSHeSDhil8cwfEpdKosYSzU1VGuqiUzM35I7o2i+yQD 2FCLT7SUAQf0woKNDqftXtAzjShhp18CPybSJgiWjFCa3P3KuMOYhJICBfANGaan3swo GygP24o= =GVFp -----END PGP SIGNATURE----- From paulej@packetizer.com Fri Nov 11 09:03:23 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293C621F8573 for ; Fri, 11 Nov 2011 09:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpzrhzJE1FxH for ; Fri, 11 Nov 2011 09:03:22 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3546F21F84AC for ; Fri, 11 Nov 2011 09:03:22 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pABH3JH9015441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Nov 2011 12:03:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321031000; bh=iiSelxLQnch+dyEGJKrIzqR1JH1Yq8XlGvmXZbUFevs=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=TuM4BtNDTweCAOXCIoxExQuGXlC29KxMFoe4YKm4rxLSsibSx/lEYAkKR+nAuq0/n ANRHV7i3qCI/EmFN83p6nKyEpMKoUIRs03hWTvre+cmkiEaD4jE/tlpiNJ3PLmYxh6 ucV1T491KrR8jPqlSotPqi8rNBGvibJBCzSB9zoQ= From: "Paul E. Jones" To: "'Worley, Dale R $Dale$'" , References: In-Reply-To: Date: Fri, 11 Nov 2011 12:03:16 -0500 Message-ID: <01af01cca093$ce85e5a0$6b91b0e0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM4kK2PtwYoA4yO/2keicmD4G9X/pLQAV9w Content-Language: en-us Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 17:03:23 -0000 Dale, I appreciate your intervention... you're helping to bring clarity to the issues. I do have some comments below: > So to summarize, if a single INVITE forks to two destinations, the > resulting dialogs are two sessions, and need separate Session-Ids. > The interesting point is that the dialogs have the *same* Call-Id. Two different Session-IDs (since there are two different remote devices), but the same Call-ID. > Functionally, a Session-Id cannot be assigned before the INVITE reaches > the endpoint; the Session-Id first appears in the 2xx response from the > destination endpoint. It might arrive even before a 2xx, such as via a 180. Following our proposal, the called devices would each return a Session-UUID. The concatenation of Alice's UUID and the UUID received from each called device would result in the creation of a set of Session IDs. Of course, only one would be long-lived, but they will all exist in parallel for a short period of time. > part 2: > > Another case which bedevils the definitions: > > 1. Alice calls Bob through a B2BUA functioning as an SBC. > There are two SIP dialogs, Alice-SBC and SBC-Bob. > 2. Bob transfers the call to Carol by sending toward Alice a REFER with > Refer-To: sip:carol. > 3. The SBC "shortstops" the REFER by obeying it itself, so it creates a > dialog to Carol, SBC-Carol. Through passing SDP through or altering its > RTP relaying, the dialog Alice-SBC is used for the communication with > Carol. > > In the initial phase, the dialogs Alice-SBC and SBC-Bob are part of one > session, and share a Session-Id. In the second phase, the dialogs > Alice-SBC and SBC-Carol are part of a *different* session, despite that > the dialog Alice-SBC has not changed. Correct. However, I would want Alice to be aware that the Session-ID has changed. So via some signaling message, I would want the SBC to inform Alice of the new Session-UUID that is associated with Carol. > In this situation, even the mapping from dialog identifiers to Session- > Ids is not many-to-one, and the Session-Id of a dialog changes over > time. Correct. > How are we to signal to Alice that the Session-Id of her dialog has > changed? One solution is to just send a new INVITE from the SBC to Alice containing the revised Session-UUID. This would not require changes in SDP if the codecs do not change and the SBC is proxying media. However, that might not be the ideal solution. I'd accept any proposal (e.g., INFO or other). > part 3: > > Now to combine these to make a really nasty example! > > 1. Alice calls Bob. The Alice-Bob dialog is assigned a Session-Id by > Bob. To be clear, we are proposing that Alice assign half of the Session-ID and Bob assign the other half. Each half would be a UUID. > 2. Alice wants to do an attended transfer of the call to Carol. She > puts the dialog with Bob on hold, and initiates a call to sip:carol. > (BTW, is the hold music from the MOH server to Bob yet another > session?) The MOH going to Bob may be a new session. If Bob is REFERred to a parking lot, then yes. If Alice somehow interacts with a media server and re-negotiates flows so that music goes from the server to Bob, but Alice remains the "endpoint" in the call, then the Session-ID does not change. > 3. The call to sip:carol forks to two UAs. Carol answers the call on > one, and her UA assigns a Session-Id to the Alice-Carol dialog. Carol would assign one UUID, but you're nonetheless correct that we will have an new and entirely different Session-ID between Alice-Carol that is distinct from Alice-Bob. > 4. Dave answers the call on the other UA, and his UA assigns a Session- > Id to the Alice-Dave dialog. > > 5. Alice ends the Alice-Dave dialog. > > 6. Alice executes the transfer, sending an INVITE-with-Replaces to Carol > to make her UA establish a dialog with Bob. The new Carol-Bob dialog is > assigned a further Session-Id. In this scenario, what I would like to see happen is that the Carol-Bob session would use the UUID Carol created and the UUID Bob created when Carol was talking with Alice and when Bob was talking with Alice. We could create an entirely new Session-ID, but re-using the UUIDs allows us to trace the progress of a call, since these values are globally unique and would allow us to better trace the progression of a call. In all cases, the concatenation of two UUIDs results in a unique Session-ID that is not repeated between any other two devices. > (This can be made more complicated by inserting SBCs into the flow in > various places.) > > I believe that this example excludes all proposed definitions of > "session": For every definition of "session", there is no > implementation that can assign Session-Ids correctly in this example. We may need a revised definition :-) Paul From paulej@packetizer.com Fri Nov 11 09:04:25 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A863D21F858C for ; Fri, 11 Nov 2011 09:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HYv78ePLIYC for ; Fri, 11 Nov 2011 09:04:25 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0F37721F84AC for ; Fri, 11 Nov 2011 09:04:24 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pABH4Lm3015524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Nov 2011 12:04:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321031062; bh=LHZe3A0noGtZDA9BHgUsCskCTNj5/E6Y+Uw6yBqbtb0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=r+seh5wq1F/fL1dRxO0Nz1KqrA93s4GvEMBCAjE47oCm5c0WJ8yl4g8L25QRbgbSY +vYHVlwqWTH/vj5/PoP/5hVm4gigmT45eywQOvTkmeaKz/3M+iD8lnDwWiJkgtuTm9 l7Pdszz3dyDgla0Bg2xjChnb9CV9FPQdlCBm9Fe4= From: "Paul E. Jones" To: "'Worley, Dale R $Dale$'" , References: <4E8EF582.6050403@ericsson.com>, <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> In-Reply-To: Date: Fri, 11 Nov 2011 12:04:18 -0500 Message-ID: <01b101cca093$f391b130$dab51390$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCoMG+cK7yKcacnsncXJq0HayNvgHe9BdiAOi1ow+UJajZMA== Content-Language: en-us Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 17:04:25 -0000 Agreed! And I don't care if we pick a different word other than "session" if that causes too much confusion. I just have no better word to offer at the moment. > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Worley, Dale R (Dale) > Sent: Wednesday, November 09, 2011 1:56 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] new charter version for Session-id > > If we're gong to make progress, I think we will have to include "Working > out a good definition of 'session'." as one of the tasks for the WG. > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From paulej@packetizer.com Fri Nov 11 09:15:22 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A1421F8A97 for ; Fri, 11 Nov 2011 09:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47PUqctJW7Yq for ; Fri, 11 Nov 2011 09:15:21 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2261E21F8A96 for ; Fri, 11 Nov 2011 09:15:21 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pABHFC35016293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Nov 2011 12:15:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321031713; bh=iWxVPT3VKk5rkYOJksH2ir1itA7G4eMM1L3WI9O2c90=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=lqF9/9bc66zbv7FbLIuAEsRFut8/GqvJJJq15KOzBTFML6iRPMta8D3aZbtTRgpit sv1a5M4mXQVHyVm5X4ss9ipKczRWYzYyzpWFW0SynPfKI2FVJT9bCL6HwOp3K31dZA k7tQBsXwZdTstQXXk0/pNJ4CnKNI5oQa7XezvtiQ= From: "Paul E. Jones" To: "'DRAGE, Keith $Keith$'" , "'Paul Kyzivat'" , References: <4E8EF582.6050403@ericsson.com>, <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <4EBAD023.3010508@alum.mit.edu> In-Reply-To: Date: Fri, 11 Nov 2011 12:15:08 -0500 Message-ID: <01b301cca095$779ad9b0$66d08d10$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCoMG+cK7yKcacnsncXJq0HayNvgHe9BdiAOi1ow8Czs+QmAL6uGSBk/ddLeA= Content-Language: en-us Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 17:15:22 -0000 Keith, With that definition, I think we would re-define the "conference identifier". A single identifier associated with a conference focus and all entities that are a part of that focus would be a conference identifier. We're not trying to tackle that problem, though we tough on it in the Session-ID draft. If a conference focus uses the same UUID for all participants, we would be able to see an association between those different sessions. However, that use is not a proper replacement for a conference ID and isn't intended to be. I do want to be careful not to mix these too much: the focus is on identifying a session end-to-end, and a conference focus might be one end. Paul > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of DRAGE, Keith (Keith) > Sent: Wednesday, November 09, 2011 2:20 PM > To: Paul Kyzivat; dispatch@ietf.org > Subject: Re: [dispatch] new charter version for Session-id > > There was one definition I used to like in ITU-T which was one of the > their "call" definitions, which was something along the lines of "the > association between two or more end users". Now if we use that > definition to be the terminal (or UA) associated with that end user, it > has the following characteristics: > > 1) It enshrines the path into PSTN, or whatever else, that lies > beyond the SIP gateway > > 2) It enshrines all the users attached to a conference focus, and the > conference focus itself. > > 3) All the forks in a reguest would be part of the same "call". > > While this may not be what we are trying to achieve with this new > identifier, it may help identify what it is not. > > Regards > > Keith > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: 09 November 2011 19:10 > > To: dispatch@ietf.org > > Subject: Re: [dispatch] new charter version for Session-id > > > > On 11/9/11 1:56 PM, Worley, Dale R (Dale) wrote: > > > If we're gong to make progress, I think we will have to include > > > "Working out a good definition of 'session'." as one of the tasks > > > for the WG. > > > > Yes. It would be ideal if the definition was complete - able to > > classify all possible cases, with the classification for the "common" > > ones being something that we can agree is reasonable. > > > > This is fundamental problem I have had with all the attempts to define > > a session id - its *hard* to come up with a widely agreeable > > definition of session. > > > > Thanks, > > Paul > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From dworley@avaya.com Fri Nov 11 09:53:16 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A352621F8ADE for ; Fri, 11 Nov 2011 09:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.335 X-Spam-Level: X-Spam-Status: No, score=-103.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BT-wYbNtU2i for ; Fri, 11 Nov 2011 09:53:16 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1D16121F8A97 for ; Fri, 11 Nov 2011 09:53:16 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGdgvU6HCzI1/2dsb2JhbABCqh2BBYFyAQEBAQIBEhUTRAsCAQgNCAMeEDIlAQEEAQkJCBqHYJx+m0CJG2MEiBCRdow9 X-IronPort-AV: E=Sophos;i="4.69,496,1315195200"; d="scan'208";a="314137563" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Nov 2011 12:53:15 -0500 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Nov 2011 12:42:09 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 11 Nov 2011 12:53:14 -0500 From: "Worley, Dale R (Dale)" To: "James M. Polk" , "dispatch@ietf.org" Date: Fri, 11 Nov 2011 12:52:52 -0500 Thread-Topic: [dispatch] Expanded dialog/session example Thread-Index: Acyf9cbzWxsg1PbnQgyappoxRcbOpQApPTCL Message-ID: References: , <201111102212.pAAMC1bB004554@mtv-core-1.cisco.com> In-Reply-To: <201111102212.pAAMC1bB004554@mtv-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Expanded dialog/session example X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 17:53:16 -0000 > From: James M. Polk [jmpolk@cisco.com] >=20 > At 11:06 AM 11/10/2011, Worley, Dale R (Dale) wrote: > > ... > > Eight dialogs are created: > > Alice-SBC > > SBC-Bob >=20 > the above two dialogs would use 1 Session-ID >=20 > When Alice call gets diverted or transferred to another UA (Carol, > Dave or MOH1 or MOH2) she retains her half of the same Session-ID, > but since each far end UA is different, the *whole* Session-ID would > be different for each combination of UAs >=20 > > Alice-MOH-1 > > Alice-MOH-2 > > Alice-Carol > > Alice-Dave > > Carol-SBC Now remember that there are two dialogs between Alice and one MOH server, one created to service each on-hold interval. So though Alice-MOH-1 and Alice-MOH-2 are two different dialogs, they are between the same "endpoint" devices. If you want Alice to use the same half-session-Id for both dialogs, but does MOH use the same half-session-Id for both dialogs? If it does, how does it arrange to do so? And when the Alice-Bob call is put on hold, what session-Id does Bob see? In a sense, Bob is still calling Alice, but in reality, the media he is hearing comes from MOH. What is the session-Id that Bob sees at that time? > Once the Alice to Carol Session-ID is constructed, it traverses > B2BUAs and SBCs without changing, which is unlike what happens to > Dialog IDs (and Call-IDs). >=20 > > Carol-MOH >=20 > In other words, once Alice (using Session-ID 'A') creates a session > (through any type of SIP server) with Bob (using Session-ID 'B'), > each retains use of that Session-ID half even if the session is > transferred to another entity (to Carol using Session-ID 'C', or > MOH-1 server using Session-ID '1') (and so on...). >=20 > Thus, you get these Session-IDs: >=20 > Alice to Bob -> whole Session-ID =3D AB > Alice to MOH-1 -> whole Session-ID =3D A1 > Alice to Carol -> whole Session-ID =3D AC > Alice to Dave -> whole Session-ID =3D AD >=20 > And if Bob is transferred by Alice to Carol or Dave, but first has a > session with MOH-2, it would be either >=20 > Bob to MOH-2 -> whole Session-ID =3D B2 then > Bob to Carol -> whole Session-ID =3D BC (Actually, it's Carol who creates the 3rd dialog to MOH, but that doesn't change the essence of the situation.) The point here is that when Bob is transferred to Carol, he does not have a change of dialog. So if the session-Id when Bob is talking to Alice is AB and the session-Id when Bob is talking to Carol is BC (or equivalently, CB), then there must be some mechanism for changing the session-Id of a dialog. More importantly, this violates the assumption that many people have that session-Ids *group* dialogs, so every dialog is part of *exactly* one session. Dale From dworley@avaya.com Fri Nov 11 11:35:12 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3E321F8A71 for ; Fri, 11 Nov 2011 11:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VMAynx6XEBZ for ; Fri, 11 Nov 2011 11:35:11 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9852921F8A70 for ; Fri, 11 Nov 2011 11:35:11 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOh3vU7GmAcF/2dsb2JhbABCqh+BBYFyAQEBAQIBEhUTRAsCAQgNKRAyJQEBBAEJERqHYJ0imzqJG2MEiBCRdow9 X-IronPort-AV: E=Sophos;i="4.69,496,1315195200"; d="scan'208";a="217499323" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 11 Nov 2011 14:35:10 -0500 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Nov 2011 14:34:14 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Fri, 11 Nov 2011 14:35:09 -0500 From: "Worley, Dale R (Dale)" To: "James M. Polk" , "dispatch@ietf.org" Date: Fri, 11 Nov 2011 14:34:49 -0500 Thread-Topic: [dispatch] Expanded dialog/session example Thread-Index: AcygBrfIW6EF3kmtSWiIg5otW9fD4gAokF3o Message-ID: References: <201111102212.pAAMC1bB004554@mtv-core-1.cisco.com> , <201111110012.pAB0Cr0c013093@mtv-core-2.cisco.com> In-Reply-To: <201111110012.pAB0Cr0c013093@mtv-core-2.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Expanded dialog/session example X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 19:35:12 -0000 You're proposing a version of the "call end identifier" model. I think that it can be defined and implemented (unlike many of the other approaches). Interdigitating the call sequence and James' proposal: > Alice's half Session-ID =3D 'A' > Bob's half Session-ID =3D 'B' > Carol's 1st UA half Session-ID =3D 'Cc' > Carol's 2nd UA half Session-ID =3D 'Ccc' Strictly speaking, Scc is the half-session-Id used by Dave's UA. > Dave's half Session-ID =3D 'D' > MOH-1's half Session-ID =3D '1' > MOH-2's half Session-ID =3D '2' | 1. Alice calls Bob. This call goes through an SBC, a B2BUA on the | boundary between two administrative domains which desires to minimize | the passage of signaling events between the domains. Thus, there are | two dialogs, Alice-SBC and SBC-Bob. > 1. =3D AB from Alice to Bob (regardless of SIP servers) So Alice-SBC and SBC-Bob are given session-Id AB. | 2. Alice places the call on hold. Alice's UA creates a dialog | Alice-MOH-1 with the music-on-hold server, and uses 3PCC techniques | (SDP relaying) to cause MOH to send its RTP to the far end of | Alice-SBC (that is, the SBC), which then relays it to Bob. > 2. =3D A1 to Alice, 1B to Bob Here we have to decide whether Alice-MOH-1 is part of the same session as Alice-SBC and SBC-Bob. If they are part of the same session, then all 3 dialogs Alice-MOH-1, Alice-SBC, and SBC-Bob must be given the same session-Id, 1B, since one end of the media chain is MOH and the other is Bob. In that case, there must be a way of changing the session-Id assigned to Alice-SBC and SBC-Bob. If they are not part of the same session, the session-Id of Alice-SBC and SBC-Bob does not change (AB), and Alice-MOH-1 gets the session-Id A1. | 3. Alice takes the call off hold. Alice's UA terminates the dialog | Alice-MOH-1, and updates the SDP of Alice-SBC so media is sent to/from | Alice's UA. > 3. =3D "...so media to/from Alice's UA" and what? You don't say. > Though if Bob, this goes back to AB I meant "... so media is sent between Alice's UA and SBC." | 4. Alice wants to do an attended transfer of the call to Carol. She | puts the dialog with Bob on hold. Alice's UA creates a new dialog | Alice-MOH-2 with the music-on-hold server, and uses 3PCC techniques | (SDP relaying) to cause MOH to send its RTP to the far end of | Alice-SBC (that is, the SBC), which then relays it to Bob. > 4. =3D 2B (if I understand you correctly). IOW, it's 2B if the > RTP is between Bob and MOH-2. What makes this interesting is that it returns to the same configuration that existed at the end of step 2. Alice's UA has established a *new* dialog to the *same* MOH server. Do we expect the MOH server to use the *same* identification for its end as it used in step 2? | 5. Alice's UA initiates a call to sip:carol. This call forks to two | UAs. Carol answers the call on one UA, creating the dialog | Alice-Carol. > 5. =3D ACc This probably depends on whether Alice's UA, at this time, knows that the call to Carol is intended to be part of an attended transfer. If the UA does *not* know, then it probably should select a *new* endpoint identification, A'. The reason for this is that if it does not follow this policy, the UA will be using the same endpoint identification for a long series of calls, causing the endpoint reveal "internal" information and giving service providers an incentive to block transmission of session-Ids. | 6. Dave answers the call on the other UA, creating a dialog Alice-Dave | (which has the same Call-Id as Alice-Carol, but a different to-tag). > 6. =3D ACcc - but here you have two forked UAs answering the > same call from Alice. Isn't the forking proxy supposed > to kill the latter of these sessions (i.e., a second > 200 OK causes a BYE from the forking proxy?) Normally, a forking proxy will cancel one fork when the other fork is answered. But the INVITE can have a Caller-Preferences to prevent that, and in any case, if Carol and Dave answer simultaneously, a race condition allows both 200s to reach Alice. | 7. Alice ends the Alice-Dave dialog, because she does not want to | transfer the call with Bob to Dave. > 7. =3D "Alice ends the Alice-Dave dialog" why isn't that a BYE? It is. How else do you end a dialog? > If so, why are you proposing to send Dave to Bob? I'm not. > Terminating a dialog terminates the Session-ID; but > I'm not sure where you're going here. | 8. Alice executes the transfer between the calls to Bob (Alice-SBC) | and Carol (Alice-Carol), by sending a REFER to Carol specifying SBC's | contact URI with a Replaces header-parameter identifying Alice-SBC. > 8. =3D BCc I think you're describing the INVITE sent in step 9. | 9. Carol's UA sends an INVITE to SBC, creating a dialog Carol-SBC. | The dialog Carol-SBC replaces the dialog Carol-Alice on Carol's UA | interface. > 9. =3D In step 8, Alice REFER'd Bob to Carol, thereby removing > Alice from any dialogs, and therefore any Session-IDs > (if I'm following you correctly. | 10. The SBC "shortstops" the INVITE-with-Replaces, changing its | relaying so that SBC-Bob relays to/from Carol-SBC rather than | Alice-SBC. The dialog SBC-Bob continues. > 10. =3D SBCs have no affect on the Session-ID construction, and > as Bob and Carol are already talking to each other from > step 8, there is no Session-ID to give here; BCc remains > up. I'm not quite sure what you mean by "Bob and Carol are already talking to each other from step 8". Step 8 is where Alice sends the REFER to Carol, step 9 is where Carol then sends the prescribed INVITE to SBC, and step 10 is when SBC receives the INVITE and acts on it. In any case, according to this scheme, Carol-SBC has the session-Id BCc. But that means that Bob-SBC should now have the session-Id BCc as well. We are requiring a mechanism to change the session-Id of an existing dialog, and we are also adding a complexity to the data model: A dialog can be part of multiple sessions over time. | 11. The dialogs Alice-SBC and Alice-Carol are terminated by one or both | of their UAs. Alice's UA terminates Alice-MOH-2. > 11. =3D the ACcc was terminated in step 7. The ACc was > transferred to BCc in step 8, so there is no Alice-SBC > anything at this point. I'm not sure I'm following you here. The dialog Alice-Carol gets terminated as part of cleaning up the consultative transfer, but different phones do the cleaning up in different ways. With some phones, when Alice's UA is gets the NOTIFY from Carol's UA that Carol's UA has received the 200 response for the INVITE to SBC, Alice's UA sends a BYE on Alice-Carol. With other phones, the BYE on Alice-Carol is sent by Carol's UA when it receives the 200. In any case, Alice-Carol is not (should not be) terminated until SBC has sent the 200 to the INVITE (step 10). > I don't see where "Alice's UA > terminates Alice-MOH-2" can happen because A2 was never > up, unless it occurred in step 4. Yes. Most phones put the current call on hold when the user indicates he wants to do a consultative transfer, and that on-hold operation starts a dialog to the MOH server to retrieve MOH. > If you propose that it > was in step 4, then how did Alice discover the Alice-Carol > was forked to both Carol and (specifically) Dave (that > she didn't want Bob to talk to in step 7)? Wouldn't see > have had to talk to Dave to know it was him? Yes. I'm presuming here that both Alice-Carol and Alice-Dave are presented on Alice's UA's interface. Alternatively, we can assume that Alice's UA received the 200 from Carol first, and automatically sent a BYE to the dialog created by the 200 from Dave. The message flow is the same in either case. > At the end of the day, when you put Alice-SBC and > Carol-SBC you seem to think this is a full Session-ID > and it is not. I'm losing you here. What do you mean by "when you put"? Do you mean "when you say"? "Alice-SBC" is the name I'm using for the SIP dialog between Alice's UA and SBC. As I said in step 1, "Thus, there are two dialogs, Alice-SBC and SBC-Bob." | 12. Carol places the call on hold. Carol's UA creates a dialog | Carol-MOH with the same music-on-hold server that Alice used, and uses | 3PCC techniques (SDP relaying) to cause MOH to send its RTP to the far | end of Carol-SBC (that is, the SBC), which then relays it to Bob. > 12. =3D Carol to MOH (which? server-1 or server-2) would be > either Cc1 or Cc2. Bob to MOH (which? server-1 or > server-2) would be either B1 or B2. I can't tell which > at this point you want it to be to. I want it to be to the *same* server as Alice used in steps 2 and 4. That's what I meant by "with the same music-on-hold server that Alice used". The reason for this is that after step 12, the dialog chain is MOH -> Carol -> SBC -> Bob, and more specifically, the two *endpoint devices* are MOH and Bob, just as they were after step 2. Now if we require that there always be the same session-Id when a session runs between the same *endpoint devices*, this session would have session-Id AB. The trouble with this is that no element is in a position to know that this session duplicates the previous one. The alternative is that half-session-Ids are "call ends", and that initiating an INVITE and receiving an INVITE both create *new* call ends with new identifiers, with the exceptions (I think): - when a call goes through a B2BUA, the B2BUA passes the call end identifiers through in both directions - when a UA acts on an in-dialog REFER, the new INVITE uses the same call end identifier that the UA used for the dialog containing the REFER - when a UA acts on an INVITE-with-Replaces, the new dialog uses the same call end identifier as the UA used for the dialog that has been replaced Call ends generally match the "call slots" on a UAs user interface. Dale From paulej@packetizer.com Fri Nov 11 12:03:03 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD62521F8AD9 for ; Fri, 11 Nov 2011 12:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emP139s11OHr for ; Fri, 11 Nov 2011 12:03:03 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D02E721F84A4 for ; Fri, 11 Nov 2011 12:03:02 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pABK2xG7024661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Nov 2011 15:03:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321041780; bh=P/LE2n1oCEBhWuaMOXji+5PKBeJpUYWlAe8qHAnrWkU=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=lMXuGGpR2xf9HcROa1Y3ETZspI/ljEfkgTjNCtpS73nyTTNCRdEbVeECyF2eXwz8L OUrMAh9bzyErQ7rhXyjexhtB6SQuKtscKmn6ks0Xg8UBnbhOfSEdEcF0LVsbmLneGw HAyDSw5kD9ngCHdhwZruNmYLHF5Ho8hSI93Z15Vs= From: "Paul E. Jones" To: "'Worley, Dale R $Dale$'" , "'James M. Polk'" , References: , <201111102212.pAAMC1bB004554@mtv-core-1.cisco.com> In-Reply-To: Date: Fri, 11 Nov 2011 15:02:55 -0500 Message-ID: <020401cca0ac$e7b83550$b7289ff0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLRdW4ic8kmbnLD/olmEvCOi8Iy0AHt0+65AaVj5mCTgc/OEA== Content-Language: en-us Subject: Re: [dispatch] Expanded dialog/session example X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 20:03:03 -0000 Dale, > Now remember that there are two dialogs between Alice and one MOH > server, one created to service each on-hold interval. So though > Alice-MOH-1 and Alice-MOH-2 are two different dialogs, they are between > the same "endpoint" devices. > > If you want Alice to use the same half-session-Id for both dialogs, but > does MOH use the same half-session-Id for both dialogs? If it does, how > does it arrange to do so? If the MoH is a callable entity, it would receive an INVITE and respond with a 200. For the MoH server, this is effectively a new "call" and it would use a different Session-UUID for each "call". If the MoH server is merely serving media for another device that controls it (through some means I don't care), then it's not an issue as the call is still anchored at the called device. I assume you're suggesting alice does send an INVITE to the MoH server, so each "call" would result in the MoH server using a different UUID back to Alice. > And when the Alice-Bob call is put on hold, what session-Id does Bob > see? In a sense, Bob is still calling Alice, but in reality, the media > he is hearing comes from MOH. What is the session-Id that Bob sees at > that time? If the call remains fixed between Bob and Alice, then the Session-ID never changes. If Alice puts Bob on hold by referring him to a MOH server, then the Session-ID would change. If Alice puts Bob on hold by invoking a MoH server herself and just sending Bob and INVITE with the media information, then the call actually never moves: it's still between Alice and Bob. The fact media is sourced somewhere else is a different matter. Having said that, if we want to associate media flows with signaling, then perhaps Alice would convey to Bob a new Session ID. So, we might have this: Alice Bob MOH Server | | | <-- Call in steady state INVITE ----------------------> | | | <----------------------------- 200 (SDP) | | | INVITE ------> | | | <------------- 200 | | | ===== Music ===== | | | There would be a Session-ID between Alice and the MOH server that would be an entirely different Session-ID. This scenario is actually like the B2BUA examples where Alice is now an intermediary. So, what she could do is send Bob's Session-UUID to the MOH server and send the MOH server's UUID to Bob. That way, the MOH server and Bob (and Alice) have a common view. We could then let the MOH server use the resulting Session-ID in protocols like RSVP. I prefer that, now that I think about it. > > Once the Alice to Carol Session-ID is constructed, it traverses B2BUAs > > and SBCs without changing, which is unlike what happens to Dialog IDs > > (and Call-IDs). > > > > > Carol-MOH > > > > In other words, once Alice (using Session-ID 'A') creates a session > > (through any type of SIP server) with Bob (using Session-ID 'B'), each > > retains use of that Session-ID half even if the session is transferred > > to another entity (to Carol using Session-ID 'C', or > > MOH-1 server using Session-ID '1') (and so on...). > > > > Thus, you get these Session-IDs: > > > > Alice to Bob -> whole Session-ID = AB > > Alice to MOH-1 -> whole Session-ID = A1 Alice to Carol -> whole > > Session-ID = AC Alice to Dave -> whole Session-ID = AD > > > > And if Bob is transferred by Alice to Carol or Dave, but first has a > > session with MOH-2, it would be either > > > > Bob to MOH-2 -> whole Session-ID = B2 then > > Bob to Carol -> whole Session-ID = BC > > (Actually, it's Carol who creates the 3rd dialog to MOH, but that > doesn't change the essence of the situation.) > > The point here is that when Bob is transferred to Carol, he does not > have a change of dialog. So if the session-Id when Bob is talking to > Alice is AB and the session-Id when Bob is talking to Carol is BC (or > equivalently, CB), then there must be some mechanism for changing the > session-Id of a dialog. The Session-ID likely will change with any kind of transfer (signaled transfer or behind-the-scenes). > More importantly, this violates the assumption that many people have > that session-Ids *group* dialogs, so every dialog is part of *exactly* > one session. Every dialog, I think, is part of exactly one Session-ID at any given point in time, I think. A dialog between Alice and a PBX might never change as far as Alice is concerned, but the Session-ID might change many times with various service interactions. Paul From jmpolk@cisco.com Fri Nov 11 13:15:25 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C710A21F85B1 for ; Fri, 11 Nov 2011 13:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.51 X-Spam-Level: X-Spam-Status: No, score=-106.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQWvlxqPKBQa for ; Fri, 11 Nov 2011 13:15:25 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 00E1B21F8573 for ; Fri, 11 Nov 2011 13:15:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=4841; q=dns/txt; s=iport; t=1321046125; x=1322255725; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=0ady4vQEoaPXNDfQQ+aZULV9IGsSxpxHz/P0F4gWhRc=; b=hkgor2exbukZ4DeZKPHZ2KrRvJH2vYg2/ahwCAs7g11cug9CXsiXqrE3 BYO439z/Cvcx1l5vZdvpekzQjDtRdwH6XhJbXLA3vJKrf4x54J+gC7YrS LRL9deDcwEqrhg1W4/z1uiN0X31DTrT4Jy1/ZqAowZbG4Li3gtVNGO7ST E=; X-IronPort-AV: E=Sophos;i="4.69,496,1315180800"; d="scan'208";a="13759136" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 11 Nov 2011 21:15:23 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8713.cisco.com [10.99.80.20]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pABLFMv8020156; Fri, 11 Nov 2011 21:15:22 GMT Message-Id: <201111112115.pABLFMv8020156@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 11 Nov 2011 15:15:21 -0600 To: "Worley, Dale R (Dale)" , "James M. Polk" , "dispatch@ietf.org" From: "James M. Polk" In-Reply-To: References: <201111102212.pAAMC1bB004554@mtv-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dispatch] Expanded dialog/session example X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 21:15:25 -0000 At 11:52 AM 11/11/2011, Worley, Dale R (Dale) wrote: > > From: James M. Polk [jmpolk@cisco.com] > > > > At 11:06 AM 11/10/2011, Worley, Dale R (Dale) wrote: > > > ... > > > Eight dialogs are created: > > > Alice-SBC > > > SBC-Bob > > > > the above two dialogs would use 1 Session-ID > > > > When Alice call gets diverted or transferred to another UA (Carol, > > Dave or MOH1 or MOH2) she retains her half of the same Session-ID, > > but since each far end UA is different, the *whole* Session-ID would > > be different for each combination of UAs > > > > > Alice-MOH-1 > > > Alice-MOH-2 > > > Alice-Carol > > > Alice-Dave > > > Carol-SBC > >Now remember that there are two dialogs between Alice and one MOH >server, one created to service each on-hold interval. So though >Alice-MOH-1 and Alice-MOH-2 are two different dialogs, they are >between the same "endpoint" devices. because they are different dialogs, the MOH server would assign different half keys to each, while each may have the same half key from Alice's UA. This does open up an interesting scenario in which the Alice-MOH-1 takes one path through SIP servers (which may or may not include a B2BUA), and Alice-MOH-2 takes another path through SIP servers (which may or may not include B2BUA different from the other dialog). I expect that to be a requirement the Session-ID work (group) would have to resolve. I don't have an answer off the top of my head (though I am a bit distracted this afternoon, so one might be obvious that I'm just not thinking about). >If you want Alice to use the same half-session-Id for both dialogs, >but does MOH use the same half-session-Id for both dialogs? If it >does, how does it arrange to do so? one goal of this effort is to replicate what differing dialog-IDs were supposed to be (i.e., without B2BUAs or SBCs in between UAs in a session). Therefore, the way I see it, wherever there should be or are two dialogs without a B2BUA or SBC in between the UAs, there needs to be distinct Session-IDs per dialog. >And when the Alice-Bob call is put on hold, what session-Id does Bob >see? he see the existing one until it is replaced by the one mentioned immediately below. >In a sense, Bob is still calling Alice, but in reality, the >media he is hearing comes from MOH. What is the session-Id that Bob >sees at that time? Bob would have a new overall Session-ID, consisting of his half key that he used in the dialog to Alice, and the new half key that the MOH server provides. > > Once the Alice to Carol Session-ID is constructed, it traverses > > B2BUAs and SBCs without changing, which is unlike what happens to > > Dialog IDs (and Call-IDs). > > > > > Carol-MOH > > > > In other words, once Alice (using Session-ID 'A') creates a session > > (through any type of SIP server) with Bob (using Session-ID 'B'), > > each retains use of that Session-ID half even if the session is > > transferred to another entity (to Carol using Session-ID 'C', or > > MOH-1 server using Session-ID '1') (and so on...). > > > > Thus, you get these Session-IDs: > > > > Alice to Bob -> whole Session-ID = AB > > Alice to MOH-1 -> whole Session-ID = A1 > > Alice to Carol -> whole Session-ID = AC > > Alice to Dave -> whole Session-ID = AD > > > > And if Bob is transferred by Alice to Carol or Dave, but first has a > > session with MOH-2, it would be either > > > > Bob to MOH-2 -> whole Session-ID = B2 then > > Bob to Carol -> whole Session-ID = BC > >(Actually, it's Carol who creates the 3rd dialog to MOH, but that >doesn't change the essence of the situation.) > >The point here is that when Bob is transferred to Carol, he does not >have a change of dialog. so Bob's half Session-ID remains the same. It's Carol's half key that makes the Session-ID unique to this session (i.e., Alice's half key goes away from the Bob-Carol session). >So if the session-Id when Bob is talking to >Alice is AB and the session-Id when Bob is talking to Carol is BC (or >equivalently, CB), then there must be some mechanism for changing the >session-Id of a dialog. Yep, the INVITE from Bob to Carol (after Alice REFERed Bob to Alice) will only include Bob's existing half key. It's up to Carol to append her new half key to make a full Session-ID for this new dialog. >More importantly, this violates the assumption that many people have >that session-Ids *group* dialogs, so every dialog is part of *exactly* >one session. They group two halves of a session, i.e., the dialog between Bob and the B2BUA, and the other dialog between the B2BUA and Carol. Here you have two dialogs and only one Session-ID. James >Dale From HKaplan@acmepacket.com Sat Nov 12 20:12:50 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550F821F87C2 for ; Sat, 12 Nov 2011 20:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sxdn6vXSzG0m for ; Sat, 12 Nov 2011 20:12:49 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9426321F8922 for ; Sat, 12 Nov 2011 20:12:49 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 12 Nov 2011 23:12:47 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sat, 12 Nov 2011 23:12:47 -0500 From: Hadriel Kaplan To: "Paul E. Jones" Thread-Topic: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints Thread-Index: AQHMobp/cbwWjm3a+UCNQegFcRGYVw== Date: Sun, 13 Nov 2011 04:12:46 +0000 Message-ID: <8B269C87-2B41-4F83-A7C9-3443E05E323B@acmepacket.com> References: <01af01cca093$ce85e5a0$6b91b0e0$@packetizer.com> In-Reply-To: <01af01cca093$ce85e5a0$6b91b0e0$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <579331A0C2CBCB44A2DFD2368CD7BBE6@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 04:12:50 -0000 On Nov 11, 2011, at 12:03 PM, Paul E. Jones wrote: >> 3. The SBC "shortstops" the REFER by obeying it itself, so it creates a >> dialog to Carol, SBC-Carol. Through passing SDP through or altering its >> RTP relaying, the dialog Alice-SBC is used for the communication with >> Carol. Actually, I think the SBC should create a session-id of "Alice-Carol", usin= g the same "Alice" portion as the original "Alice-Bob" dialog - since that'= s what would have happened had the REFER gone all the way back to Alice. B= ut the difference probably doesn't matter much for this discussion. >> In the initial phase, the dialogs Alice-SBC and SBC-Bob are part of one >> session, and share a Session-Id. In the second phase, the dialogs >> Alice-SBC and SBC-Carol are part of a *different* session, despite that >> the dialog Alice-SBC has not changed. >=20 > Correct. However, I would want Alice to be aware that the Session-ID has > changed. So via some signaling message, I would want the SBC to inform > Alice of the new Session-UUID that is associated with Carol. Why does Alice need to be made aware of this? What's Alice going to use th= e session-id for in the future that requires her to know it? I ask because the reasons SBC process REFERS instead of passing them back a= re some of the same reasons PBX's do so: (1) because many UAs can't process= REFER or do so correctly, (2) because the transfer even is a local event a= nd the admin doesn't want Alice's UA to know/care about it occurring, and (= 3) there's additional policy/logic that the SBC/PBX applies to transferred = calls. Expecting the SBC to send re-INVITEs/INFO to Alice to make her awar= e of the transfer goes against (1) and (2), so I doubt it will happen. Once the SBC processes the REFER itself, it's now switched into being an "e= ndpoint" role (to use the terminology you were using before). -hadriel From HKaplan@acmepacket.com Sat Nov 12 20:20:17 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420E81F0C49 for ; Sat, 12 Nov 2011 20:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3lI8IbgrQiS for ; Sat, 12 Nov 2011 20:20:16 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9D07C1F0C42 for ; Sat, 12 Nov 2011 20:20:16 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 12 Nov 2011 23:20:14 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sat, 12 Nov 2011 23:20:14 -0500 From: Hadriel Kaplan To: "Paul E. Jones" Thread-Topic: [dispatch] new charter version for Session-id Thread-Index: AQHMobuKbd0QLim7S06j3BU7N1yXxw== Date: Sun, 13 Nov 2011 04:20:13 +0000 Message-ID: References: <4E8EF582.6050403@ericsson.com>, <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <01b101cca093$f391b130$dab51390$@packetizer.com> In-Reply-To: <01b101cca093$f391b130$dab51390$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 04:20:17 -0000 One thing I'd suggest is that if a solution such as draft-jones-ipmc-sessio= n-id-00 is adopted by the new WG, that it not treat the ID as one value, bu= t in fact make them explicitly two separate value tokens: similar to the cu= rrent from/to tags being unique tag values. I'm not suggesting it be From/= To header parameters - just that it be two separately encoded values, one g= enerated by Alice, one by Bob - and their combination be session identifier= s or whatever we call them. -hadriel On Nov 11, 2011, at 12:04 PM, Paul E. Jones wrote: > Agreed! And I don't care if we pick a different word other than "session= " > if that causes too much confusion. I just have no better word to offer a= t > the moment. >=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Worley, Dale R (Dale) >> Sent: Wednesday, November 09, 2011 1:56 PM >> To: dispatch@ietf.org >> Subject: Re: [dispatch] new charter version for Session-id >>=20 >> If we're gong to make progress, I think we will have to include "Working >> out a good definition of 'session'." as one of the tasks for the WG. >>=20 >> Dale >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From paulej@packetizer.com Sat Nov 12 20:56:19 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769C721F8663 for ; Sat, 12 Nov 2011 20:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFQqrnNuaUlL for ; Sat, 12 Nov 2011 20:56:18 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9E00A21F861E for ; Sat, 12 Nov 2011 20:56:18 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pAD4uE6K031803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 12 Nov 2011 23:56:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321160175; bh=n2tgsOM+zNyB4Uxugoit3Kr76Tui70jhE5d1iMi09y4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=jRb8a9H7z8M2+Mh7HT4l4ckjImL33iuc8XnBXUNsZQUzvSbOcLGTr/XtD6AeP7FtL XMxbUp7ZKzB+rHGvNC10xoe+V49Vn240lCazjz6weW7uCIoh1Pa9pfR1jAtAj75vyJ hpqw4A99ZxS7A16FNVUYZ8omN5VfgLXvyoNSWnmk= From: "Paul E. Jones" To: "'Hadriel Kaplan'" References: <01af01cca093$ce85e5a0$6b91b0e0$@packetizer.com> <8B269C87-2B41-4F83-A7C9-3443E05E323B@acmepacket.com> In-Reply-To: <8B269C87-2B41-4F83-A7C9-3443E05E323B@acmepacket.com> Date: Sat, 12 Nov 2011 23:56:08 -0500 Message-ID: <008e01cca1c0$8f3527c0$ad9f7740$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM4kK2PtwYoA4yO/2keicmD4G9X/gD/RGHTAXK6cSOSvszdEA== Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 04:56:19 -0000 Hadriel, > >> 3. The SBC "shortstops" the REFER by obeying it itself, so it creates > >> a dialog to Carol, SBC-Carol. Through passing SDP through or > >> altering its RTP relaying, the dialog Alice-SBC is used for the > >> communication with Carol. > > Actually, I think the SBC should create a session-id of "Alice-Carol", > using the same "Alice" portion as the original "Alice-Bob" dialog - > since that's what would have happened had the REFER gone all the way > back to Alice. But the difference probably doesn't matter much for this > discussion. Yes, that's what should happen. The SBC would forward to Carol Alice's Session-UUID. Likewise, it would forward to Alice Carol's Session-UUID (via INVITE or whatever). > >> In the initial phase, the dialogs Alice-SBC and SBC-Bob are part of > >> one session, and share a Session-Id. In the second phase, the > >> dialogs Alice-SBC and SBC-Carol are part of a *different* session, > >> despite that the dialog Alice-SBC has not changed. > > > > Correct. However, I would want Alice to be aware that the Session-ID > > has changed. So via some signaling message, I would want the SBC to > > inform Alice of the new Session-UUID that is associated with Carol. > > Why does Alice need to be made aware of this? What's Alice going to use > the session-id for in the future that requires her to know it? There are lots of things: 1) Logging 2) Billing 3) Signaling / media correlation 4) troubleshooting 5) call tracing We wanted a Session-ID that is end-to-end, so Alice needs to know if an identifier changes so she can take appropriate action. Perhaps she does not care, but there are definitely things I'd like to do knowing the current end-to-end identifier for a call. If we did not change this value, then we might actually have multiple devices reporting that they are the same Session-ID when, in fact, they're not. Consider Alice calling Bob and then both devices being redirected elsewhere. If they were not made aware of a change in the opposite endpoint, they would both log the same Session-ID even after the they were no longer communicating with each other and communicating with some other endpoint. > I ask because the reasons SBC process REFERS instead of passing them > back are some of the same reasons PBX's do so: (1) because many UAs > can't process REFER or do so correctly, (2) because the transfer even is > a local event and the admin doesn't want Alice's UA to know/care about > it occurring, and (3) there's additional policy/logic that the SBC/PBX > applies to transferred calls. Expecting the SBC to send re-INVITEs/INFO > to Alice to make her aware of the transfer goes against (1) and (2), so > I doubt it will happen. If we sent an INFO message to update Alice's understanding of the remote entities Session-UUID, she'll either do something with it or ignore it. If she is making active use of the Session-ID, she should take note of the change. If she is not, then there's no harm done. She would just ignore the INFO message. > Once the SBC processes the REFER itself, it's now switched into being an > "endpoint" role (to use the terminology you were using before). But it's not: it's still an intermediary. If it every switched into an endpoint role (e.g., such as becoming a conference focus), it should manufacture its own Session-UUID to send to other endpoints in the conference. In the scenarios you've described, it is still an intermediary, though. Paul From paulej@packetizer.com Sat Nov 12 20:58:29 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7706721F8A35 for ; Sat, 12 Nov 2011 20:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVjFW2xcz5XN for ; Sat, 12 Nov 2011 20:58:29 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D7D3D21F8663 for ; Sat, 12 Nov 2011 20:58:28 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pAD4wQhV031840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 12 Nov 2011 23:58:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321160307; bh=z7dupeQx5r0Rx5VLtgyNCCSzPxp2uPaiJI0SONSWKHI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=JRqy71uHtKJz2ZKl2nFDdzmCLT4RKlvGTnRGkz7A/5Z+zW9wkW21X+DvG2wJ2ZauL Hc/hqYMYvLqdZRNMUC9n+9thqJU3adr5VGRHflAUv2iK9coVuu6Bs94fm0ih9WQNdK 0sS549RY7leyvnIF5n/iZvc+KbTQpW4MGbNL1Wns= From: "Paul E. Jones" To: "'Hadriel Kaplan'" References: <4E8EF582.6050403@ericsson.com>, <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <01b101cca093$f391b130$dab51390$@packetizer.com> In-Reply-To: Date: Sat, 12 Nov 2011 23:58:20 -0500 Message-ID: <009001cca1c0$dde3d330$99ab7990$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCoMG+cK7yKcacnsncXJq0HayNvgHe9BdiAOi1ow8CVhBsAwLVCMOFk/6ppdA= Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 04:58:29 -0000 They definitely are two values. The concatenation of the two under that proposal is the "Session-ID". Paul > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Saturday, November 12, 2011 11:20 PM > To: Paul E. Jones > Cc: Worley, Dale R (Dale); > Subject: Re: [dispatch] new charter version for Session-id > > > One thing I'd suggest is that if a solution such as draft-jones-ipmc- > session-id-00 is adopted by the new WG, that it not treat the ID as one > value, but in fact make them explicitly two separate value tokens: > similar to the current from/to tags being unique tag values. I'm not > suggesting it be From/To header parameters - just that it be two > separately encoded values, one generated by Alice, one by Bob - and > their combination be session identifiers or whatever we call them. > > -hadriel > > > On Nov 11, 2011, at 12:04 PM, Paul E. Jones wrote: > > > Agreed! And I don't care if we pick a different word other than > "session" > > if that causes too much confusion. I just have no better word to > > offer at the moment. > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > >> Behalf Of Worley, Dale R (Dale) > >> Sent: Wednesday, November 09, 2011 1:56 PM > >> To: dispatch@ietf.org > >> Subject: Re: [dispatch] new charter version for Session-id > >> > >> If we're gong to make progress, I think we will have to include > >> "Working out a good definition of 'session'." as one of the tasks for > the WG. > >> > >> Dale > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From paulej@packetizer.com Sat Nov 12 21:20:04 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E10421F8AD3 for ; Sat, 12 Nov 2011 21:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkTgnNguOn8J for ; Sat, 12 Nov 2011 21:20:01 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 68ADB11E8089 for ; Sat, 12 Nov 2011 21:20:01 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pAD5Jvj5032210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 Nov 2011 00:19:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321161598; bh=FHYyzKg5I2WFa9pXsRasJkmGPj93EYqYZNZqeR/CEck=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=e/9bAa6y7I5e07EAw0AdkHBdNGAvyCuP3TAZ2dKtyCxOrj9QplP2iUCIXON8fl8AX 1Sn9y4dNrWa8QK0/3+OxH/bF/3g3q4DnFH8QbQ+li+VbhSFAiR3NufDNaR/qTUE3uE BrXK1nX1GqhBH3Is+J+BINnhqglhh0xG85OsCU7E= From: "Paul E. Jones" To: Date: Sun, 13 Nov 2011 00:19:51 -0500 Message-ID: <009f01cca1c3$df921810$9eb64830$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A0_01CCA199.F6BE5A00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acyhw92x8oqAAnw9RJSo9Vd0WN16JA== Content-Language: en-us Subject: [dispatch] Revised Session-ID Charter (proposal) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 05:20:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A0_01CCA199.F6BE5A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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) ------=_NextPart_000_00A0_01CCA199.F6BE5A00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
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

---------------------------------------
<= p class=3DMsoNormal>
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)

------=_NextPart_000_00A0_01CCA199.F6BE5A00-- From HKaplan@acmepacket.com Sun Nov 13 04:43:13 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9577F21F8B7C for ; Sun, 13 Nov 2011 04:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZQyzwmjj3rh for ; Sun, 13 Nov 2011 04:43:13 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E0B9B21F8B6E for ; Sun, 13 Nov 2011 04:43:12 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 13 Nov 2011 07:43:09 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sun, 13 Nov 2011 07:43:08 -0500 From: Hadriel Kaplan To: "dispatch@ietf.org list" Thread-Topic: [dispatch] IETF 82 - DRAFT Agenda Thread-Index: AQHMogHLf2VLTRkF6kOA1/et2cQt+w== Date: Sun, 13 Nov 2011 12:43:07 +0000 Message-ID: References: <20111013220824.67DD821F8B95@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: multipart/alternative; boundary="_000_D937756DC29B44D7BEE444167B024892acmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: Re: [dispatch] IETF 82 - DRAFT Agenda X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 12:43:13 -0000 --_000_D937756DC29B44D7BEE444167B024892acmepacketcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Howdy, I checked the agenda and I don't see my STRAW Working Group proposal on the= agenda list. I did send an email on Sept. 4th asking for agenda time. Wa= s there not enough email-list traffic generated to warrant time? (could be = - I don't know what's the minimum number of emails needed for WG meeting ti= me) -hadriel On Oct 13, 2011, at 7:45 PM, Mary Barnes wrote: DISPATCH is tentatively scheduled to meet on Tuesday afternoon. ---------- Forwarded message ---------- From: IETF Agenda > Date: Thu, Oct 13, 2011 at 6:08 PM Subject: IETF 82 - DRAFT Agenda To: IETF Announcement list > Cc: 82all@ietf.org, irsg@irtf.org The DRAFT agenda is available for viewing on the IETF 82 Meeting web page a= t: http://www.ietf.org/meeting/82/index.html The final agenda will be published on October 21, 2011. Only 30 days until Taipei, 82nd IETF! Online registration for the IETF meeting is at: http://www.ietf.org/meeting/register.html _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_D937756DC29B44D7BEE444167B024892acmepacketcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Howdy,

I checked the agenda and I don't see my STRAW Working Group proposal o= n the agenda list. I did send an email on Sept. 4th asking for agenda= time. Was there not enough email-list traffic generated to warrant t= ime? (could be - I don't know what's the minimum number of emails needed for WG meeting time)

-hadriel

On Oct 13, 2011, at 7:45 PM, Mary Barnes wrote:

DISPATCH is tentatively scheduled to meet on Tues= day afternoon.

---------- Forwarded message ----------
From: IETF Agenda <<= a href=3D"mailto:agenda@ietf.org">agenda@ietf.org>
Date: Thu, Oct 13, 2011 at 6:08 PM
Subject: IETF 82 - DRAFT Agenda
To: IETF Announcement list <ie= tf-announce@ietf.org>
Cc: 82all@ietf.org, irsg@irtf.org

The DRAFT agenda is available for viewing on the IETF 82 Meeting web page a= t: http://www.ietf.org/meeting/82/index.html

The final agenda will be published on October 21, 2011.

Only 30 days until Taipei, 82nd IETF!
Online registration for the IETF meeting is at:
htt= p://www.ietf.org/meeting/register.html
_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

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

--_000_D937756DC29B44D7BEE444167B024892acmepacketcom_-- From christian.1.schmidt@nsn.com Sun Nov 13 05:42:06 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A5821F8B29 for ; Sun, 13 Nov 2011 05:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGfoeVd8GmlP for ; Sun, 13 Nov 2011 05:42:05 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA9921F8B24 for ; Sun, 13 Nov 2011 05:42:05 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pADDg39C016103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 13 Nov 2011 14:42:04 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pADDg3hg016321; Sun, 13 Nov 2011 14:42:03 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Nov 2011 14:42:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Nov 2011 14:41:58 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Session-Id: Problem 3: A session is limited to twoendpoints Thread-Index: AQHMnxE1qBsBnjbYVkC2azVfIMC/oZWq0ugg References: From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: "ext Worley, Dale R (Dale)" , X-OriginalArrivalTime: 13 Nov 2011 13:42:03.0401 (UTC) FILETIME=[06C77790:01CCA20A] Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to twoendpoints X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 13:42:06 -0000 What would happen in case of "SPLICES". Assume you have a video/audio connection between two endpoints. Is it correct, that both audio and video communication would share the same Session-ID? If one endpoint change the entity for video communication only, would a new Session-ID for this purpose? Christian -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Worley, Dale R (Dale) Sent: Wednesday, November 09, 2011 7:55 PM To: dispatch@ietf.org Subject: [dispatch] Session-Id: Problem 3: A session is limited to twoendpoints part 1: > From: Paul E. Jones [paulej@packetizer.com] >=20 > A Session-ID is intended to be unique between any two communicating > endpoints. So, if Alice makes a call and connects to Bob, there would > be a Session-ID that is end-to-end unique between Alice and Bob. If > an intermediary re-routes the call such that Alice is now in > communication with Sue, then there would be a new unique Session-ID > between Alice and Sue. Likewise, if Alice calls Bob, but there is a > forking proxy that causes the call to be forked to 15 "Bobs", then > there would be 15 Session-IDs, one for each pair of { Alice, Bob(i) }. > The Session-ID is unique between any two communicating endpoints. So to summarize, if a single INVITE forks to two destinations, the resulting dialogs are two sessions, and need separate Session-Ids. The interesting point is that the dialogs have the *same* Call-Id. Logically, the mapping from Call-Id to Session-Id is not many-to-one, although the mapping from dialog identifiers (Call-Id, caller-tag, callee-tag) to Session-Id is still many-to-one. Functionally, a Session-Id cannot be assigned before the INVITE reaches the endpoint; the Session-Id first appears in the 2xx response from the destination endpoint. part 2: Another case which bedevils the definitions: 1. Alice calls Bob through a B2BUA functioning as an SBC. There are two SIP dialogs, Alice-SBC and SBC-Bob. 2. Bob transfers the call to Carol by sending toward Alice a REFER with Refer-To: sip:carol. 3. The SBC "shortstops" the REFER by obeying it itself, so it creates a dialog to Carol, SBC-Carol. Through passing SDP through or altering its RTP relaying, the dialog Alice-SBC is used for the communication with Carol. In the initial phase, the dialogs Alice-SBC and SBC-Bob are part of one session, and share a Session-Id. In the second phase, the dialogs Alice-SBC and SBC-Carol are part of a *different* session, despite that the dialog Alice-SBC has not changed. In this situation, even the mapping from dialog identifiers to Session-Ids is not many-to-one, and the Session-Id of a dialog changes over time. How are we to signal to Alice that the Session-Id of her dialog has changed? part 3: Now to combine these to make a really nasty example! 1. Alice calls Bob. The Alice-Bob dialog is assigned a Session-Id by Bob. 2. Alice wants to do an attended transfer of the call to Carol. She puts the dialog with Bob on hold, and initiates a call to sip:carol. (BTW, is the hold music from the MOH server to Bob yet another session?) 3. The call to sip:carol forks to two UAs. Carol answers the call on one, and her UA assigns a Session-Id to the Alice-Carol dialog. 4. Dave answers the call on the other UA, and his UA assigns a Session-Id to the Alice-Dave dialog. 5. Alice ends the Alice-Dave dialog. 6. Alice executes the transfer, sending an INVITE-with-Replaces to Carol to make her UA establish a dialog with Bob. The new Carol-Bob dialog is assigned a further Session-Id. (This can be made more complicated by inserting SBCs into the flow in various places.) I believe that this example excludes all proposed definitions of "session": For every definition of "session", there is no implementation that can assign Session-Ids correctly in this example. Dale "In cooperation with an intelligent joiner I would undertake to defeat any definition of chair or chairishness that you gave me." -- H. G. Wells, "A Modern Utopia" _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Sun Nov 13 07:42:36 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8B321F8B38 for ; Sun, 13 Nov 2011 07:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHrGiRPmK1KZ for ; Sun, 13 Nov 2011 07:42:36 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id D0D8721F8B3B for ; Sun, 13 Nov 2011 07:42:35 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id wfXx1h0021ap0As55fidKM; Sun, 13 Nov 2011 15:42:37 +0000 Received: from dhcp-471c.meeting.ietf.org ([130.129.71.28]) by omta22.westchester.pa.mail.comcast.net with comcast id wfiT1h01g0ccXAy3ifiWH9; Sun, 13 Nov 2011 15:42:35 +0000 Message-ID: <4EBFE563.4070609@alum.mit.edu> Date: Sun, 13 Nov 2011 10:42:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to twoendpoints X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 15:42:36 -0000 On 11/13/11 8:41 AM, Schmidt, Christian 1. (NSN - DE/Munich) wrote: > What would happen in case of "SPLICES". > Assume you have a video/audio connection between two endpoints. > Is it correct, that both audio and video communication would share the > same Session-ID? > If one endpoint change the entity for video communication only, would a > new Session-ID for this purpose? It will be interesting to get the author's opinion on this. :-) IMO, *if* there is one device anchoring the a/v, and delegating the video to another sip device: (sip) A -------------------- B ==================== | (audio) = (sip) | = C ====================== (video) then I think you want one session id for AB and another for AC, with B never knowing that C is involved. So A is acting as an endpoint, at least for the A-B session. Thanks, Paul > Christian > > > > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of ext Worley, Dale R (Dale) > Sent: Wednesday, November 09, 2011 7:55 PM > To: dispatch@ietf.org > Subject: [dispatch] Session-Id: Problem 3: A session is limited to > twoendpoints > > part 1: > >> From: Paul E. Jones [paulej@packetizer.com] >> >> A Session-ID is intended to be unique between any two communicating >> endpoints. So, if Alice makes a call and connects to Bob, there would >> be a Session-ID that is end-to-end unique between Alice and Bob. If >> an intermediary re-routes the call such that Alice is now in >> communication with Sue, then there would be a new unique Session-ID >> between Alice and Sue. Likewise, if Alice calls Bob, but there is a >> forking proxy that causes the call to be forked to 15 "Bobs", then >> there would be 15 Session-IDs, one for each pair of { Alice, Bob(i) }. >> The Session-ID is unique between any two communicating endpoints. > > So to summarize, if a single INVITE forks to two destinations, the > resulting dialogs are two sessions, and need separate Session-Ids. > The interesting point is that the dialogs have the *same* Call-Id. > > Logically, the mapping from Call-Id to Session-Id is not many-to-one, > although the mapping from dialog identifiers (Call-Id, caller-tag, > callee-tag) to Session-Id is still many-to-one. > > Functionally, a Session-Id cannot be assigned before the INVITE > reaches the endpoint; the Session-Id first appears in the 2xx response > from the destination endpoint. > > part 2: > > Another case which bedevils the definitions: > > 1. Alice calls Bob through a B2BUA functioning as an SBC. > There are two SIP dialogs, Alice-SBC and SBC-Bob. > 2. Bob transfers the call to Carol by sending toward Alice a REFER with > Refer-To: sip:carol. > 3. The SBC "shortstops" the REFER by obeying it itself, so it creates a > dialog to Carol, SBC-Carol. Through passing SDP through or altering > its RTP relaying, the dialog Alice-SBC is used for the communication > with Carol. > > In the initial phase, the dialogs Alice-SBC and SBC-Bob are part of > one session, and share a Session-Id. In the second phase, the dialogs > Alice-SBC and SBC-Carol are part of a *different* session, despite > that the dialog Alice-SBC has not changed. > > In this situation, even the mapping from dialog identifiers to > Session-Ids is not many-to-one, and the Session-Id of a dialog changes > over time. > > How are we to signal to Alice that the Session-Id of her dialog has > changed? > > part 3: > > Now to combine these to make a really nasty example! > > 1. Alice calls Bob. The Alice-Bob dialog is assigned a Session-Id by > Bob. > > 2. Alice wants to do an attended transfer of the call to Carol. She > puts the dialog with Bob on hold, and initiates a call to sip:carol. > (BTW, is the hold music from the MOH server to Bob yet another > session?) > > 3. The call to sip:carol forks to two UAs. Carol answers the call on > one, and her UA assigns a Session-Id to the Alice-Carol dialog. > > 4. Dave answers the call on the other UA, and his UA assigns a > Session-Id to the Alice-Dave dialog. > > 5. Alice ends the Alice-Dave dialog. > > 6. Alice executes the transfer, sending an INVITE-with-Replaces to > Carol to make her UA establish a dialog with Bob. The new Carol-Bob > dialog is assigned a further Session-Id. > > (This can be made more complicated by inserting SBCs into the flow > in various places.) > > I believe that this example excludes all proposed definitions of > "session": For every definition of "session", there is no > implementation that can assign Session-Ids correctly in this example. > > Dale > > "In cooperation with an intelligent joiner I would undertake to defeat > any definition of chair or chairishness that you gave me." > -- H. G. Wells, "A Modern Utopia" > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From paulej@packetizer.com Sun Nov 13 09:14:35 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F9E21F8A70 for ; Sun, 13 Nov 2011 09:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5QkeqEGNAQ9 for ; Sun, 13 Nov 2011 09:14:34 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3804021F87FA for ; Sun, 13 Nov 2011 09:14:34 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pADHEUrq012777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 Nov 2011 12:14:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321204473; bh=9+bg8x9GhTeenvI8akw4jNbZECgpja4+EUj7lNNfTL0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=OphcZi59ZO1Oxq+yLaMYvPPQWpPPDONjL6ZXZ1WL40QOgBIIKQN18kSqtSksKyR5d L2DsgB+xWkHBbVOw73FhsrEYY3+Ln7gqstBMzbvylELQJjyeYtJqQTL9Hk7bbu6MUC CpfWPqsFjcYyMCWBp5vPnSKSKUvqidbYZpOvm4Eo= From: "Paul E. Jones" To: "'Schmidt, Christian 1. $NSN - DE/Munich$'" , "'ext Worley, Dale R $Dale$'" , References: In-Reply-To: Date: Sun, 13 Nov 2011 12:14:23 -0500 Message-ID: <013301cca227$b28bc370$17a34a50$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM4kK2PtwYoA4yO/2keicmD4G9X/gFvye5ykset3fA= Content-Language: en-us Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to twoendpoints X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 17:14:35 -0000 Christian, That should not change the Session ID. For all intents and purposes, the video devices are a logical extension of the user agent that either placed or received the call. So, switching a new video device should make no difference. It's similar to swapping out monitors connected to your PC. That said, if the separate video or audio devices are to utilize the Session-ID (e.g., inserting it into an RSVP PATH message), then those devices need to be told what Session-ID to use. In what we proposed in our draft, each entity provides half of the Session-ID via the "Session-UUID" header. How is it that communication is to be established with these other devices? Will it be via a SIP INVITE or some other mechanism? We might need a means of assigning an ID in this case vs. proposing only 1/2 of the value. Paul > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Schmidt, Christian 1. (NSN - DE/Munich) > Sent: Sunday, November 13, 2011 8:42 AM > To: ext Worley, Dale R (Dale); dispatch@ietf.org > Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to > twoendpoints > > What would happen in case of "SPLICES". > Assume you have a video/audio connection between two endpoints. > Is it correct, that both audio and video communication would share the > same Session-ID? > If one endpoint change the entity for video communication only, would a > new Session-ID for this purpose? > > Christian > > > > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of ext Worley, Dale R (Dale) > Sent: Wednesday, November 09, 2011 7:55 PM > To: dispatch@ietf.org > Subject: [dispatch] Session-Id: Problem 3: A session is limited to > twoendpoints > > part 1: > > > From: Paul E. Jones [paulej@packetizer.com] > > > > A Session-ID is intended to be unique between any two communicating > > endpoints. So, if Alice makes a call and connects to Bob, there would > > be a Session-ID that is end-to-end unique between Alice and Bob. If > > an intermediary re-routes the call such that Alice is now in > > communication with Sue, then there would be a new unique Session-ID > > between Alice and Sue. Likewise, if Alice calls Bob, but there is a > > forking proxy that causes the call to be forked to 15 "Bobs", then > > there would be 15 Session-IDs, one for each pair of { Alice, Bob(i) }. > > The Session-ID is unique between any two communicating endpoints. > > So to summarize, if a single INVITE forks to two destinations, the > resulting dialogs are two sessions, and need separate Session-Ids. > The interesting point is that the dialogs have the *same* Call-Id. > > Logically, the mapping from Call-Id to Session-Id is not many-to-one, > although the mapping from dialog identifiers (Call-Id, caller-tag, > callee-tag) to Session-Id is still many-to-one. > > Functionally, a Session-Id cannot be assigned before the INVITE reaches > the endpoint; the Session-Id first appears in the 2xx response from the > destination endpoint. > > part 2: > > Another case which bedevils the definitions: > > 1. Alice calls Bob through a B2BUA functioning as an SBC. > There are two SIP dialogs, Alice-SBC and SBC-Bob. > 2. Bob transfers the call to Carol by sending toward Alice a REFER with > Refer-To: sip:carol. > 3. The SBC "shortstops" the REFER by obeying it itself, so it creates a > dialog to Carol, SBC-Carol. Through passing SDP through or altering its > RTP relaying, the dialog Alice-SBC is used for the communication with > Carol. > > In the initial phase, the dialogs Alice-SBC and SBC-Bob are part of one > session, and share a Session-Id. In the second phase, the dialogs > Alice-SBC and SBC-Carol are part of a *different* session, despite that > the dialog Alice-SBC has not changed. > > In this situation, even the mapping from dialog identifiers to Session- > Ids is not many-to-one, and the Session-Id of a dialog changes over > time. > > How are we to signal to Alice that the Session-Id of her dialog has > changed? > > part 3: > > Now to combine these to make a really nasty example! > > 1. Alice calls Bob. The Alice-Bob dialog is assigned a Session-Id by > Bob. > > 2. Alice wants to do an attended transfer of the call to Carol. She > puts the dialog with Bob on hold, and initiates a call to sip:carol. > (BTW, is the hold music from the MOH server to Bob yet another > session?) > > 3. The call to sip:carol forks to two UAs. Carol answers the call on > one, and her UA assigns a Session-Id to the Alice-Carol dialog. > > 4. Dave answers the call on the other UA, and his UA assigns a Session- > Id to the Alice-Dave dialog. > > 5. Alice ends the Alice-Dave dialog. > > 6. Alice executes the transfer, sending an INVITE-with-Replaces to Carol > to make her UA establish a dialog with Bob. The new Carol-Bob dialog is > assigned a further Session-Id. > > (This can be made more complicated by inserting SBCs into the flow in > various places.) > > I believe that this example excludes all proposed definitions of > "session": For every definition of "session", there is no > implementation that can assign Session-Ids correctly in this example. > > Dale > > "In cooperation with an intelligent joiner I would undertake to defeat > any definition of chair or chairishness that you gave me." > -- H. G. Wells, "A Modern Utopia" > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From keith.drage@alcatel-lucent.com Sun Nov 13 10:03:04 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF65221F85FF for ; Sun, 13 Nov 2011 10:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.169 X-Spam-Level: X-Spam-Status: No, score=-106.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TYNWZ-k0lSm for ; Sun, 13 Nov 2011 10:03:04 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id E8E6621F85DB for ; Sun, 13 Nov 2011 10:03:03 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pADI31vW002024 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 13 Nov 2011 19:03:01 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sun, 13 Nov 2011 19:03:01 +0100 From: "DRAGE, Keith (Keith)" To: "Paul E. Jones" , "'Paul Kyzivat'" , "dispatch@ietf.org" Date: Sun, 13 Nov 2011 19:03:00 +0100 Thread-Topic: [dispatch] new charter version for Session-id Thread-Index: AQKCoMG+cK7yKcacnsncXJq0HayNvgHe9BdiAOi1ow8Czs+QmAL6uGSBk/ddLeCAAx8/kA== Message-ID: References: <4E8EF582.6050403@ericsson.com>, <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <4EBAD023.3010508@alum.mit.edu> <01b301cca095$779ad9b0$66d08d10$@packetizer.com> In-Reply-To: <01b301cca095$779ad9b0$66d08d10$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 18:03:05 -0000 Understood, but if there is no conference and only two parties, the two def= initions converge to one. And we do need to understand that relationship. Keith > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: 11 November 2011 17:15 > To: DRAGE, Keith (Keith); 'Paul Kyzivat'; dispatch@ietf.org > Subject: RE: [dispatch] new charter version for Session-id >=20 > Keith, >=20 > With that definition, I think we would re-define the "conference > identifier". A single identifier associated with a conference focus and > all > entities that are a part of that focus would be a conference identifier. > We're not trying to tackle that problem, though we tough on it in the > Session-ID draft. If a conference focus uses the same UUID for all > participants, we would be able to see an association between those > different > sessions. However, that use is not a proper replacement for a conference > ID > and isn't intended to be. I do want to be careful not to mix these too > much: the focus is on identifying a session end-to-end, and a conference > focus might be one end. >=20 > Paul >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > > Behalf Of DRAGE, Keith (Keith) > > Sent: Wednesday, November 09, 2011 2:20 PM > > To: Paul Kyzivat; dispatch@ietf.org > > Subject: Re: [dispatch] new charter version for Session-id > > > > There was one definition I used to like in ITU-T which was one of the > > their "call" definitions, which was something along the lines of "the > > association between two or more end users". Now if we use that > > definition to be the terminal (or UA) associated with that end user, it > > has the following characteristics: > > > > 1) It enshrines the path into PSTN, or whatever else, that lies > > beyond the SIP gateway > > > > 2) It enshrines all the users attached to a conference focus, and the > > conference focus itself. > > > > 3) All the forks in a reguest would be part of the same "call". > > > > While this may not be what we are trying to achieve with this new > > identifier, it may help identify what it is not. > > > > Regards > > > > Keith > > > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > > > Behalf Of Paul Kyzivat > > > Sent: 09 November 2011 19:10 > > > To: dispatch@ietf.org > > > Subject: Re: [dispatch] new charter version for Session-id > > > > > > On 11/9/11 1:56 PM, Worley, Dale R (Dale) wrote: > > > > If we're gong to make progress, I think we will have to include > > > > "Working out a good definition of 'session'." as one of the tasks > > > > for the WG. > > > > > > Yes. It would be ideal if the definition was complete - able to > > > classify all possible cases, with the classification for the "common" > > > ones being something that we can agree is reasonable. > > > > > > This is fundamental problem I have had with all the attempts to defin= e > > > a session id - its *hard* to come up with a widely agreeable > > > definition of session. > > > > > > Thanks, > > > Paul > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From keith.drage@alcatel-lucent.com Sun Nov 13 10:11:12 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0543621F8B40 for ; Sun, 13 Nov 2011 10:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.171 X-Spam-Level: X-Spam-Status: No, score=-106.171 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YyOOasHv0Iy for ; Sun, 13 Nov 2011 10:11:11 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7E721F8B3E for ; Sun, 13 Nov 2011 10:11:10 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pADIB7T5007080 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 13 Nov 2011 19:11:07 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sun, 13 Nov 2011 19:11:07 +0100 From: "DRAGE, Keith (Keith)" To: "Paul E. Jones" , "'Hadriel Kaplan'" Date: Sun, 13 Nov 2011 19:11:04 +0100 Thread-Topic: [dispatch] new charter version for Session-id Thread-Index: AQKCoMG+cK7yKcacnsncXJq0HayNvgHe9BdiAOi1ow8CVhBsAwLVCMOFk/6ppdCAAN294A== Message-ID: References: <4E8EF582.6050403@ericsson.com>, <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <01b101cca093$f391b130$dab51390$@packetizer.com> <009001cca1c0$dde3d330$99ab7990$@packetizer.com> In-Reply-To: <009001cca1c0$dde3d330$99ab7990$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 18:11:12 -0000 I'd just note that is not a requirement. It is part of a solution to achieving uniqueness. I suspect we need to get the requirements nailed down first. Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul E. Jones > Sent: 13 November 2011 04:58 > To: 'Hadriel Kaplan' > Cc: dispatch@ietf.org > Subject: Re: [dispatch] new charter version for Session-id >=20 > They definitely are two values. The concatenation of the two under that > proposal is the "Session-ID". >=20 > Paul >=20 > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Saturday, November 12, 2011 11:20 PM > > To: Paul E. Jones > > Cc: Worley, Dale R (Dale); > > Subject: Re: [dispatch] new charter version for Session-id > > > > > > One thing I'd suggest is that if a solution such as draft-jones-ipmc- > > session-id-00 is adopted by the new WG, that it not treat the ID as one > > value, but in fact make them explicitly two separate value tokens: > > similar to the current from/to tags being unique tag values. I'm not > > suggesting it be From/To header parameters - just that it be two > > separately encoded values, one generated by Alice, one by Bob - and > > their combination be session identifiers or whatever we call them. > > > > -hadriel > > > > > > On Nov 11, 2011, at 12:04 PM, Paul E. Jones wrote: > > > > > Agreed! And I don't care if we pick a different word other than > > "session" > > > if that causes too much confusion. I just have no better word to > > > offer at the moment. > > > > > >> -----Original Message----- > > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] O= n > > >> Behalf Of Worley, Dale R (Dale) > > >> Sent: Wednesday, November 09, 2011 1:56 PM > > >> To: dispatch@ietf.org > > >> Subject: Re: [dispatch] new charter version for Session-id > > >> > > >> If we're gong to make progress, I think we will have to include > > >> "Working out a good definition of 'session'." as one of the tasks fo= r > > the WG. > > >> > > >> Dale > > >> _______________________________________________ > > >> dispatch mailing list > > >> dispatch@ietf.org > > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From paulej@packetizer.com Sun Nov 13 10:14:44 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561D821F8B52 for ; Sun, 13 Nov 2011 10:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsYyfYWAEd5D for ; Sun, 13 Nov 2011 10:14:43 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF7721F8B25 for ; Sun, 13 Nov 2011 10:14:43 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pADIEcA7013897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 Nov 2011 13:14:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321208079; bh=byG13SjlFTPRfEIWrL8s0Ugyz0ARtRbHcPEydcZh7gE=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=lwI4yOiYy+fb0qTcqrmv4HyNqpb6AMdvxAh0idnj/VjDN0rjDVfmDygQhbgSUfSrk qoPdEOvMZDr6Pw1qVL8heSPeyQmWvG5W3S+GYWguO1vmVtb77WKlWC+dmHzT2d1CA9 3DOgu/mp5lSx1uON9FTVK0zsc1yYSGvE3+zovDb4= From: "Paul E. Jones" To: "'DRAGE, Keith $Keith$'" , "'Paul Kyzivat'" , References: <4E8EF582.6050403@ericsson.com>, <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <4EBAD023.3010508@alum.mit.edu> <01b301cca095$779ad9b0$66d08d10$@packetizer.com> In-Reply-To: Date: Sun, 13 Nov 2011 13:14:31 -0500 Message-ID: <014c01cca230$1778bba0$466a32e0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCoMG+cK7yKcacnsncXJq0HayNvgHe9BdiAOi1ow8Czs+QmAL6uGSBAbe4JTYDOUJC4ZPTDBLg Content-Language: en-us Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 18:14:44 -0000 Keith, Not necessarily. In H.323, for example, there is both a "conference identifier" and a "call identifier", even if there are only two participants. The intent is that if the call does expand into a conference where there are more than two people, all participants would share the same conference identifier, but each call to the MC would have its own call identifier. I'm personally favorable to keeping a conference identifier separate from Session Identifier, as they are quite different in purpose. Paul > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Sunday, November 13, 2011 1:03 PM > To: Paul E. Jones; 'Paul Kyzivat'; dispatch@ietf.org > Subject: RE: [dispatch] new charter version for Session-id > > Understood, but if there is no conference and only two parties, the two > definitions converge to one. > > And we do need to understand that relationship. > > Keith > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: 11 November 2011 17:15 > > To: DRAGE, Keith (Keith); 'Paul Kyzivat'; dispatch@ietf.org > > Subject: RE: [dispatch] new charter version for Session-id > > > > Keith, > > > > With that definition, I think we would re-define the "conference > > identifier". A single identifier associated with a conference focus > > and all entities that are a part of that focus would be a conference > > identifier. > > We're not trying to tackle that problem, though we tough on it in the > > Session-ID draft. If a conference focus uses the same UUID for all > > participants, we would be able to see an association between those > > different sessions. However, that use is not a proper replacement for > > a conference ID and isn't intended to be. I do want to be careful not > > to mix these too > > much: the focus is on identifying a session end-to-end, and a > > conference focus might be one end. > > > > Paul > > > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > > > On Behalf Of DRAGE, Keith (Keith) > > > Sent: Wednesday, November 09, 2011 2:20 PM > > > To: Paul Kyzivat; dispatch@ietf.org > > > Subject: Re: [dispatch] new charter version for Session-id > > > > > > There was one definition I used to like in ITU-T which was one of > > > the their "call" definitions, which was something along the lines of > > > "the association between two or more end users". Now if we use that > > > definition to be the terminal (or UA) associated with that end user, > > > it has the following characteristics: > > > > > > 1) It enshrines the path into PSTN, or whatever else, that lies > > > beyond the SIP gateway > > > > > > 2) It enshrines all the users attached to a conference focus, > and the > > > conference focus itself. > > > > > > 3) All the forks in a reguest would be part of the same "call". > > > > > > While this may not be what we are trying to achieve with this new > > > identifier, it may help identify what it is not. > > > > > > Regards > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > > > > On Behalf Of Paul Kyzivat > > > > Sent: 09 November 2011 19:10 > > > > To: dispatch@ietf.org > > > > Subject: Re: [dispatch] new charter version for Session-id > > > > > > > > On 11/9/11 1:56 PM, Worley, Dale R (Dale) wrote: > > > > > If we're gong to make progress, I think we will have to include > > > > > "Working out a good definition of 'session'." as one of the > > > > > tasks for the WG. > > > > > > > > Yes. It would be ideal if the definition was complete - able to > > > > classify all possible cases, with the classification for the > "common" > > > > ones being something that we can agree is reasonable. > > > > > > > > This is fundamental problem I have had with all the attempts to > > > > define a session id - its *hard* to come up with a widely > > > > agreeable definition of session. > > > > > > > > Thanks, > > > > Paul > > > > _______________________________________________ > > > > dispatch mailing list > > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch From paulej@packetizer.com Sun Nov 13 10:15:48 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0E521F8B52 for ; Sun, 13 Nov 2011 10:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrzZTSen2uHO for ; Sun, 13 Nov 2011 10:15:47 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 55DD721F8B25 for ; Sun, 13 Nov 2011 10:15:47 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pADIFjgl013923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 Nov 2011 13:15:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321208146; bh=fXCy5cy+QPBFKIq4k4UkUCj9r6HCX2vF4/z5ZXLH+0M=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=RKmu4VN718+AzuoNoDFEtGS1ejQ2XYzUtB4/xXrL508OUreJE7/m/Wc2pU+gqfAy1 OoKO4pF56mjtkinpq2AueATRdqvspDxFV9RHJcwhh4GowOmoC+3tMIVkE+6agaKZWU LJUgaBZC1gAFsGpcMz56cnj8QUB5iZDmTV+622Vk= From: "Paul E. Jones" To: "'DRAGE, Keith $Keith$'" , "'Hadriel Kaplan'" References: <4E8EF582.6050403@ericsson.com>, <5CD12C80-110A-40D2-A6F7-7695423CF085@nostrum.com> <01b101cca093$f391b130$dab51390$@packetizer.com> <009001cca1c0$dde3d330$99ab7990$@packetizer.com> In-Reply-To: Date: Sun, 13 Nov 2011 13:15:38 -0500 Message-ID: <014e01cca230$3fa48be0$beeda3a0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKCoMG+cK7yKcacnsncXJq0HayNvgHe9BdiAOi1ow8CVhBsAwLVCMOFAZ3y95gB1dslupPj6kkQ Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 18:15:48 -0000 Agreed. The requirements document we have put forward does not prescribe the method, but Hadriel commented specifically about our proposed solution. Paul > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Sunday, November 13, 2011 1:11 PM > To: Paul E. Jones; 'Hadriel Kaplan' > Cc: dispatch@ietf.org > Subject: RE: [dispatch] new charter version for Session-id > > I'd just note that is not a requirement. > > It is part of a solution to achieving uniqueness. > > I suspect we need to get the requirements nailed down first. > > Keith > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Paul E. Jones > > Sent: 13 November 2011 04:58 > > To: 'Hadriel Kaplan' > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] new charter version for Session-id > > > > They definitely are two values. The concatenation of the two under > > that proposal is the "Session-ID". > > > > Paul > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Saturday, November 12, 2011 11:20 PM > > > To: Paul E. Jones > > > Cc: Worley, Dale R (Dale); > > > Subject: Re: [dispatch] new charter version for Session-id > > > > > > > > > One thing I'd suggest is that if a solution such as > > > draft-jones-ipmc- > > > session-id-00 is adopted by the new WG, that it not treat the ID as > > > one value, but in fact make them explicitly two separate value > tokens: > > > similar to the current from/to tags being unique tag values. I'm > > > not suggesting it be From/To header parameters - just that it be two > > > separately encoded values, one generated by Alice, one by Bob - and > > > their combination be session identifiers or whatever we call them. > > > > > > -hadriel > > > > > > > > > On Nov 11, 2011, at 12:04 PM, Paul E. Jones wrote: > > > > > > > Agreed! And I don't care if we pick a different word other than > > > "session" > > > > if that causes too much confusion. I just have no better word to > > > > offer at the moment. > > > > > > > >> -----Original Message----- > > > >> From: dispatch-bounces@ietf.org > > > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Worley, Dale R > > > >> (Dale) > > > >> Sent: Wednesday, November 09, 2011 1:56 PM > > > >> To: dispatch@ietf.org > > > >> Subject: Re: [dispatch] new charter version for Session-id > > > >> > > > >> If we're gong to make progress, I think we will have to include > > > >> "Working out a good definition of 'session'." as one of the tasks > > > >> for > > > the WG. > > > >> > > > >> Dale > > > >> _______________________________________________ > > > >> dispatch mailing list > > > >> dispatch@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > _______________________________________________ > > > > dispatch mailing list > > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Sun Nov 13 19:21:56 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209FB1F0C6D for ; Sun, 13 Nov 2011 19:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRivZ+38wWVp for ; Sun, 13 Nov 2011 19:21:55 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id F13241F0C8E for ; Sun, 13 Nov 2011 19:21:54 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 13 Nov 2011 22:21:52 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sun, 13 Nov 2011 22:21:51 -0500 From: Hadriel Kaplan To: "Paul E. Jones" Thread-Topic: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints Thread-Index: AQHMonyMhboOtYWaeUW56vdd4Ue2ZA== Date: Mon, 14 Nov 2011 03:21:50 +0000 Message-ID: <98C324EC-A04C-4490-9E5F-A0D44E9C49BA@acmepacket.com> References: <01af01cca093$ce85e5a0$6b91b0e0$@packetizer.com> <8B269C87-2B41-4F83-A7C9-3443E05E323B@acmepacket.com> <008e01cca1c0$8f3527c0$ad9f7740$@packetizer.com> In-Reply-To: <008e01cca1c0$8f3527c0$ad9f7740$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <4E1665940A983C43B068539879E449E1@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 03:21:56 -0000 On Nov 12, 2011, at 11:56 PM, Paul E. Jones wrote: >>> Correct. However, I would want Alice to be aware that the Session-ID >>> has changed. So via some signaling message, I would want the SBC to >>> inform Alice of the new Session-UUID that is associated with Carol. >>=20 >> Why does Alice need to be made aware of this? What's Alice going to use >> the session-id for in the future that requires her to know it? >=20 > There are lots of things: > 1) Logging > 2) Billing > 3) Signaling / media correlation > 4) troubleshooting > 5) call tracing I don't know what "signaling/media correlation" really means or implies fro= m a SIP protocol perspective interacting with Session-ID. I do know what billing means, and I don't think we should touch that topic = for Session-ID - both because it's a rat's nest of requirements that are un= ique for different markets/countries, but also because I'm not sure the IET= F has the appropriate knowledge experts for that topic area. I would categorize "logging", "troubleshooting", and "call-tracing" as all = the same topic, and you *do* get them without having to update Alice's Sess= ion-ID; the UUID she created for the original call to Bob is the same one u= sed in the new dialog to Carol. Each UUID of the two used in a Session-ID = is independently usable for tracking across the networks - that's one of th= e reasons I suggested that if we go with this approach we make them separat= e token fields, to make that more obvious/clear. > We wanted a Session-ID that is end-to-end, so Alice needs to know if an > identifier changes so she can take appropriate action. =20 So what is this "action"? What change to SIP processing rules or applicati= on logic are we trying to enable with a Session-ID? (I don't count "logging= /troubleshooting" as an actionable processing change) > If we did not change this value, then we might actually have multiple > devices reporting that they are the same Session-ID when, in fact, they'r= e > not. Consider Alice calling Bob and then both devices being redirected > elsewhere. If they were not made aware of a change in the opposite > endpoint, they would both log the same Session-ID even after the they wer= e > no longer communicating with each other and communicating with some other > endpoint. Yes, that was raised as an issue in the original session-id concept as well= . Luckily it didn't matter because session-id was only being used for trou= bleshooting/logging. That's why I'm trying to figure out what else this ne= w WG plans to actually do with Session-ID at a SIP layer, that would break = SIP if things didn't go as planned/expected. -hadriel From paulej@packetizer.com Sun Nov 13 20:09:50 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B430521F863E for ; Sun, 13 Nov 2011 20:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0ukQ1FXH3n5 for ; Sun, 13 Nov 2011 20:09:44 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id BDE2E21F84C2 for ; Sun, 13 Nov 2011 20:09:43 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pAE49XTO024498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 Nov 2011 23:09:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321243776; bh=pssyVGxnGeRfsILjEyrwZ3R9x+IwvmfuRCVv57rj/6w=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=UCEkDt+adrWybssDWwILBnAZiQMDs7XSXVdRaKzePykdvZOWHkAt0hhj9cMtAg5lZ k8nGIhEXpe08HjGzj+n2hjGwDZ7L0hG/Dd+4AfyL6OqxzkWkgBN+ClQi8rqRbfbWO8 S5p+OcmNwQ5yJxnBXWeTaQiC1CUwcR+wiiIS39OA= From: "Paul E. Jones" To: "'Hadriel Kaplan'" References: <01af01cca093$ce85e5a0$6b91b0e0$@packetizer.com> <8B269C87-2B41-4F83-A7C9-3443E05E323B@acmepacket.com> <008e01cca1c0$8f3527c0$ad9f7740$@packetizer.com> <98C324EC-A04C-4490-9E5F-A0D44E9C49BA@acmepacket.com> In-Reply-To: <98C324EC-A04C-4490-9E5F-A0D44E9C49BA@acmepacket.com> Date: Sun, 13 Nov 2011 23:09:25 -0500 Message-ID: <01d801cca283$3410bf30$9c323d90$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM4kK2PtwYoA4yO/2keicmD4G9X/gD/RGHTAXK6cSMCLKWx1gJ50BrFkpsdC2A= Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 04:09:51 -0000 Hadriel, > >> Why does Alice need to be made aware of this? What's Alice going to > >> use the session-id for in the future that requires her to know it? > > > > There are lots of things: > > 1) Logging > > 2) Billing > > 3) Signaling / media correlation > > 4) troubleshooting > > 5) call tracing > > > I don't know what "signaling/media correlation" really means or implies > from a SIP protocol perspective interacting with Session-ID. I would like to be able to use this in other protocols like RSVP. The network would then be able to see that a given set of flows are related. > I do know what billing means, and I don't think we should touch that > topic for Session-ID - both because it's a rat's nest of requirements > that are unique for different markets/countries, but also because I'm > not sure the IETF has the appropriate knowledge experts for that topic > area. Yeah, I'm not suggesting we go solve billing issues, but a Session-ID becomes another tool. > I would categorize "logging", "troubleshooting", and "call-tracing" as > all the same topic, and you *do* get them without having to update > Alice's Session-ID; the UUID she created for the original call to Bob is > the same one used in the new dialog to Carol. Each UUID of the two used > in a Session-ID is independently usable for tracking across the networks > - that's one of the reasons I suggested that if we go with this approach > we make them separate token fields, to make that more obvious/clear. These are certainly related, but we have to be careful. You're right that *if* we go with the approach we propose, the value Alice produced would be useful by itself -- and that was intended. However, if I had a management system that was trying to identify a given call at a given point in time, it would be useful that I could query a set of intermediary devices and determine the signaling path, for example. If we do not update Alice, then it is entirely possible that we lose that end-to-end concept. We might have this series of connections Alice -> SBC1 -> SBC2 -> SBC3 -> SBC4 -> Carol After a few service interactions, perhaps SBC3 believes that the Session ID is {X|Y} when Alice thinks it is {A|B} and Carol thinks it is {C|D}. Suppose Alice has a button on her phone used to report video quality issues. Pressing the button might also result in Alice sending the Session ID via RTCP packets. Network monitoring devices looking at those packets would have a hard time identifying the SBC through which the media is flowing if it cannot query them to determine if it knows about {A|B}. Anyway, there are many things we can do if the entire path has a common view of what the Session-ID is. It does not matter that it changes, so long as all devices have a common view at any given point in time during the stable call. > > We wanted a Session-ID that is end-to-end, so Alice needs to know if > > an identifier changes so she can take appropriate action. > > So what is this "action"? What change to SIP processing rules or > application logic are we trying to enable with a Session-ID? (I don't > count "logging/troubleshooting" as an actionable processing change) Start logging the right value, sending the right value in RTCP. Perhaps send a new PATH message with the new value, etc. The actions are outside the scope of SIP, but we want to be able to use this value. > > If we did not change this value, then we might actually have multiple > > devices reporting that they are the same Session-ID when, in fact, > > they're not. Consider Alice calling Bob and then both devices being > > redirected elsewhere. If they were not made aware of a change in the > > opposite endpoint, they would both log the same Session-ID even after > > the they were no longer communicating with each other and > > communicating with some other endpoint. > > Yes, that was raised as an issue in the original session-id concept as > well. Luckily it didn't matter because session-id was only being used > for troubleshooting/logging. That's why I'm trying to figure out what > else this new WG plans to actually do with Session-ID at a SIP layer, > that would break SIP if things didn't go as planned/expected. I do not propose that the WG do anything with the Session-ID. I only want us to define one where all devices have a common understanding of what the value is. Once we do that, then we can actually rely on it for something else meaningful. But, that will be another WG and another charter ;-) Paul From pkyzivat@alum.mit.edu Sun Nov 13 21:39:01 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F151711E8177 for ; Sun, 13 Nov 2011 21:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0O2V4SZKXsn0 for ; Sun, 13 Nov 2011 21:38:59 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF4A11E80F8 for ; Sun, 13 Nov 2011 21:38:59 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta01.westchester.pa.mail.comcast.net with comcast id wtav1h00216LCl051tezRm; Mon, 14 Nov 2011 05:38:59 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta06.westchester.pa.mail.comcast.net with comcast id wtep1h00L5EhBnE3StesvP; Mon, 14 Nov 2011 05:38:57 +0000 Message-ID: <4EC0A967.6030504@alum.mit.edu> Date: Mon, 14 Nov 2011 00:38:47 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <01af01cca093$ce85e5a0$6b91b0e0$@packetizer.com> <8B269C87-2B41-4F83-A7C9-3443E05E323B@acmepacket.com> <008e01cca1c0$8f3527c0$ad9f7740$@packetizer.com> <98C324EC-A04C-4490-9E5F-A0D44E9C49BA@acmepacket.com> <01d801cca283$3410bf30$9c323d90$@packetizer.com> In-Reply-To: <01d801cca283$3410bf30$9c323d90$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 05:39:01 -0000 I see you mention using the session id in RSVP and RTCP. Can you say more about what you have in mind? Thanks, Paul On 11/13/11 11:09 PM, Paul E. Jones wrote: > Hadriel, > >>>> Why does Alice need to be made aware of this? What's Alice going to >>>> use the session-id for in the future that requires her to know it? >>> >>> There are lots of things: >>> 1) Logging >>> 2) Billing >>> 3) Signaling / media correlation >>> 4) troubleshooting >>> 5) call tracing >> >> >> I don't know what "signaling/media correlation" really means or implies >> from a SIP protocol perspective interacting with Session-ID. > > I would like to be able to use this in other protocols like RSVP. The > network would then be able to see that a given set of flows are related. > >> I do know what billing means, and I don't think we should touch that >> topic for Session-ID - both because it's a rat's nest of requirements >> that are unique for different markets/countries, but also because I'm >> not sure the IETF has the appropriate knowledge experts for that topic >> area. > > Yeah, I'm not suggesting we go solve billing issues, but a Session-ID > becomes another tool. > >> I would categorize "logging", "troubleshooting", and "call-tracing" as >> all the same topic, and you *do* get them without having to update >> Alice's Session-ID; the UUID she created for the original call to Bob is >> the same one used in the new dialog to Carol. Each UUID of the two used >> in a Session-ID is independently usable for tracking across the networks >> - that's one of the reasons I suggested that if we go with this approach >> we make them separate token fields, to make that more obvious/clear. > > These are certainly related, but we have to be careful. You're right that > *if* we go with the approach we propose, the value Alice produced would be > useful by itself -- and that was intended. However, if I had a management > system that was trying to identify a given call at a given point in time, it > would be useful that I could query a set of intermediary devices and > determine the signaling path, for example. If we do not update Alice, then > it is entirely possible that we lose that end-to-end concept. We might have > this series of connections > Alice -> SBC1 -> SBC2 -> SBC3 -> SBC4 -> Carol > > After a few service interactions, perhaps SBC3 believes that the Session ID > is {X|Y} when Alice thinks it is {A|B} and Carol thinks it is {C|D}. > > Suppose Alice has a button on her phone used to report video quality issues. > Pressing the button might also result in Alice sending the Session ID via > RTCP packets. Network monitoring devices looking at those packets would > have a hard time identifying the SBC through which the media is flowing if > it cannot query them to determine if it knows about {A|B}. > > Anyway, there are many things we can do if the entire path has a common view > of what the Session-ID is. It does not matter that it changes, so long as > all devices have a common view at any given point in time during the stable > call. > >>> We wanted a Session-ID that is end-to-end, so Alice needs to know if >>> an identifier changes so she can take appropriate action. >> >> So what is this "action"? What change to SIP processing rules or >> application logic are we trying to enable with a Session-ID? (I don't >> count "logging/troubleshooting" as an actionable processing change) > > Start logging the right value, sending the right value in RTCP. Perhaps send > a new PATH message with the new value, etc. The actions are outside the > scope of SIP, but we want to be able to use this value. > >>> If we did not change this value, then we might actually have multiple >>> devices reporting that they are the same Session-ID when, in fact, >>> they're not. Consider Alice calling Bob and then both devices being >>> redirected elsewhere. If they were not made aware of a change in the >>> opposite endpoint, they would both log the same Session-ID even after >>> the they were no longer communicating with each other and >>> communicating with some other endpoint. >> >> Yes, that was raised as an issue in the original session-id concept as >> well. Luckily it didn't matter because session-id was only being used >> for troubleshooting/logging. That's why I'm trying to figure out what >> else this new WG plans to actually do with Session-ID at a SIP layer, >> that would break SIP if things didn't go as planned/expected. > > I do not propose that the WG do anything with the Session-ID. I only want > us to define one where all devices have a common understanding of what the > value is. Once we do that, then we can actually rely on it for something > else meaningful. But, that will be another WG and another charter ;-) > > Paul > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From paulej@packetizer.com Mon Nov 14 06:01:28 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61E821F8DDF for ; Mon, 14 Nov 2011 06:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id th+c23xTw4v4 for ; Mon, 14 Nov 2011 06:01:27 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id BA1F121F8DDE for ; Mon, 14 Nov 2011 06:01:27 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pAEE1PeH004080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Nov 2011 09:01:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321279286; bh=/UK7dF/LXNPtQssfvWjalDYu/RZcsjEWV2S26N4qZCA=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=QliTtkicmIWdS9TYKsdS4/tmGxQ2mtYG0K37hXi7f73KzfCUq2FOj/TRyF97w7w+n X/i9sUeZTK1gtBG9GCML0qRS5DkSnD+lsLAK7XAUmfFa1VH5J0EBkBvBfCc3ENGoSg qOJ71KNn9ibwiY5YDpyP/3dLh0h39MQaBt88YrYE= From: "Paul E. Jones" To: "'Paul Kyzivat'" , References: <01af01cca093$ce85e5a0$6b91b0e0$@packetizer.com> <8B269C87-2B41-4F83-A7C9-3443E05E323B@acmepacket.com> <008e01cca1c0$8f3527c0$ad9f7740$@packetizer.com> <98C324EC-A04C-4490-9E5F-A0D44E9C49BA@acmepacket.com> <01d801cca283$3410bf30$9c323d90$@packetizer.com> <4EC0A967.6030504@alum.mit.edu> In-Reply-To: <4EC0A967.6030504@alum.mit.edu> Date: Mon, 14 Nov 2011 09:01:17 -0500 Message-ID: <02e901cca2d5$e1bee6a0$a53cb3e0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM4kK2PtwYoA4yO/2keicmD4G9X/gD/RGHTAXK6cSMCLKWx1gJ50BrFAaksWKABR3sO7ZKEPrbg Content-Language: en-us Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 14:01:28 -0000 Paul, This is for media flow and signaling correlation. There are a number of reasons why this might be useful, but I don't have a proposal for this, yet. Assuming the work progresses, I will submit proposals for using it in RTCP, RTP, or other places that might make sense. Paul > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Monday, November 14, 2011 12:39 AM > To: dispatch@ietf.org > Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to > two endpoints > > I see you mention using the session id in RSVP and RTCP. > Can you say more about what you have in mind? > > Thanks, > Paul > > On 11/13/11 11:09 PM, Paul E. Jones wrote: > > Hadriel, > > > >>>> Why does Alice need to be made aware of this? What's Alice going > >>>> to use the session-id for in the future that requires her to know > it? > >>> > >>> There are lots of things: > >>> 1) Logging > >>> 2) Billing > >>> 3) Signaling / media correlation > >>> 4) troubleshooting > >>> 5) call tracing > >> > >> > >> I don't know what "signaling/media correlation" really means or > >> implies from a SIP protocol perspective interacting with Session-ID. > > > > I would like to be able to use this in other protocols like RSVP. The > > network would then be able to see that a given set of flows are > related. > > > >> I do know what billing means, and I don't think we should touch that > >> topic for Session-ID - both because it's a rat's nest of requirements > >> that are unique for different markets/countries, but also because I'm > >> not sure the IETF has the appropriate knowledge experts for that > >> topic area. > > > > Yeah, I'm not suggesting we go solve billing issues, but a Session-ID > > becomes another tool. > > > >> I would categorize "logging", "troubleshooting", and "call-tracing" > >> as all the same topic, and you *do* get them without having to update > >> Alice's Session-ID; the UUID she created for the original call to Bob > >> is the same one used in the new dialog to Carol. Each UUID of the > >> two used in a Session-ID is independently usable for tracking across > >> the networks > >> - that's one of the reasons I suggested that if we go with this > >> approach we make them separate token fields, to make that more > obvious/clear. > > > > These are certainly related, but we have to be careful. You're right > > that > > *if* we go with the approach we propose, the value Alice produced > > would be useful by itself -- and that was intended. However, if I had > > a management system that was trying to identify a given call at a > > given point in time, it would be useful that I could query a set of > > intermediary devices and determine the signaling path, for example. > > If we do not update Alice, then it is entirely possible that we lose > > that end-to-end concept. We might have this series of connections > > Alice -> SBC1 -> SBC2 -> SBC3 -> SBC4 -> Carol > > > > After a few service interactions, perhaps SBC3 believes that the > > Session ID is {X|Y} when Alice thinks it is {A|B} and Carol thinks it > is {C|D}. > > > > Suppose Alice has a button on her phone used to report video quality > issues. > > Pressing the button might also result in Alice sending the Session ID > > via RTCP packets. Network monitoring devices looking at those packets > > would have a hard time identifying the SBC through which the media is > > flowing if it cannot query them to determine if it knows about {A|B}. > > > > Anyway, there are many things we can do if the entire path has a > > common view of what the Session-ID is. It does not matter that it > > changes, so long as all devices have a common view at any given point > > in time during the stable call. > > > >>> We wanted a Session-ID that is end-to-end, so Alice needs to know if > >>> an identifier changes so she can take appropriate action. > >> > >> So what is this "action"? What change to SIP processing rules or > >> application logic are we trying to enable with a Session-ID? (I don't > >> count "logging/troubleshooting" as an actionable processing change) > > > > Start logging the right value, sending the right value in RTCP. > > Perhaps send a new PATH message with the new value, etc. The actions > > are outside the scope of SIP, but we want to be able to use this > value. > > > >>> If we did not change this value, then we might actually have > >>> multiple devices reporting that they are the same Session-ID when, > >>> in fact, they're not. Consider Alice calling Bob and then both > >>> devices being redirected elsewhere. If they were not made aware of > >>> a change in the opposite endpoint, they would both log the same > >>> Session-ID even after the they were no longer communicating with > >>> each other and communicating with some other endpoint. > >> > >> Yes, that was raised as an issue in the original session-id concept > >> as well. Luckily it didn't matter because session-id was only being > >> used for troubleshooting/logging. That's why I'm trying to figure > >> out what else this new WG plans to actually do with Session-ID at a > >> SIP layer, that would break SIP if things didn't go as > planned/expected. > > > > I do not propose that the WG do anything with the Session-ID. I only > > want us to define one where all devices have a common understanding of > > what the value is. Once we do that, then we can actually rely on it > > for something else meaningful. But, that will be another WG and > > another charter ;-) > > > > Paul > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mphmmr@gmail.com Mon Nov 14 07:25:39 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5661711E8149 for ; Mon, 14 Nov 2011 07:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FikJOnVs2uj for ; Mon, 14 Nov 2011 07:25:38 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0787311E80FF for ; Mon, 14 Nov 2011 07:25:37 -0800 (PST) Received: by wyf28 with SMTP id 28so4719837wyf.31 for ; Mon, 14 Nov 2011 07:25:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CoM/xjJSVkdFp2QWUGwCu8MantNj6NBA2RC9zIDgYow=; b=Lv9PzyEUoylLfE1aBja3YfM9aqmNJKX0xLqBnmoWE0XV72XyfNXcQ/tl3dBJjHq53x XP3VZSEBXyIVce9VwpHoJ0kmX6hboq1ubXtGMF01wZ1c7SIVr6zDzgM6CN8cvjh/UJRq lMcFiXgLED1J3MNvwWHS6e0AeDPvH02LWhBw8= MIME-Version: 1.0 Received: by 10.216.187.143 with SMTP id y15mr1763346wem.49.1321284266036; Mon, 14 Nov 2011 07:24:26 -0800 (PST) Received: by 10.216.68.66 with HTTP; Mon, 14 Nov 2011 07:24:25 -0800 (PST) In-Reply-To: <009f01cca1c3$df921810$9eb64830$@packetizer.com> References: <009f01cca1c3$df921810$9eb64830$@packetizer.com> Date: Mon, 14 Nov 2011 10:24:25 -0500 Message-ID: From: Michael Hammer To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001636418291530dfe04b1b37776 Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised Session-ID Charter (proposal) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 15:25:39 -0000 --001636418291530dfe04b1b37776 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 wrot= e: > Folks,**** > > ** ** > > We=92ve tossed around a charter a few times. The one at the last meeting > appeared to receive good consensus. Sal and I made significant changes a= nd > sent that to the list earlier, but that was met with criticism since it w= as > 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 =93session.= =94 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=92m 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 a= nd > dialogs of the same higher-level end-to-end "communication session" acros= s > 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 wort= h > 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 chan= ge > 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)**** > > ** ** > > ** ** > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --001636418291530dfe04b1b37776 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Paul,

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

Something like: =A0Bidirectional path completion ID

Although that is clearly too long, I hope the idea is= clear. =A0One 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 ter= mination point of the multitude of sessions, but only one actually complete= s.
Just a thought. =A0Accept or reject as you see fit. =A0I won&#= 39;t be there to discuss.

Good luck,
Mike

On Sun, Nov 13, 2011 at 12:19 AM, Paul E. Jones <paulej@packetizer.com= > wrote:

Folks,
=A0

We=92ve tossed around a charter a few times.=A0 The = one at the last meeting appeared to receive good consensus.=A0 Sal and I ma= de 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 chart= er.

=A0
Sal and = I then went back to the original charter text presented at the last meeting= and made only very minor edits.=A0 Tonight, I took the liberty of introduc= ing a few minor changes.=A0 One change was to add to the requirements and u= se cases document a definition of the word =93session.=94=A0 I think that i= s what Dale was suggesting we do.

=A0
In any c= ase, 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.=A0 I= =92m happy to revise it in whatever way the group wishes and would definite= ly welcome any text from those who feel passionate about it.<= /p>
=A0
Paul<= /u>
=A0
---------------------------------------
=A0
End-to-end Session Identifier i= n SIP (charter proposal)
=A0=
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 an= d correlate SIP messages and dialogs of the same higher-level end-to-end &q= uot;communication session" across multiple SIP devices, hops, and admi= nistrative domains.

=A0
Unfortun= ately, there are a number of factors that contribute to the fact that the c= urrent dialog identifiers defined in SIP is not suitable for end-to-end ses= sion identification. Perhaps the most important factor worth describing is = that in real-world deployments Back-to-Back User Agents (B2BUAs) devices li= ke 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 hea= der to make the dialog-id) as the session signaling passes through.<= u>

=A0
An end-t= o-end Session Identifier should allow the possibility to identify the commu= nication session from the point of origin, passing through any number of in= termediaries, 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 man= gled by intermediaries.=A0 Consideration must be given to the fact that the= entities involved in a communication session might change as a result of s= ervice interaction in the network, such as call transfers, joins, etc. <= /u>

=A0
A SIP en= d-to-end Session Identifier has been considered as possible solution of dif= ferent use cases like troubleshooting, billing, session tracking, session r= ecording, media and signaling correlation, and so forth.=A0 Some of these r= equirements have also been identified and come directly from other Existing= working group within the RAI area (e.g. SIPRec, Splices).
=A0
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 id= entify a call end-to end even when performing interworking between protocol= s.

=A0
The work= ing group will produce the following deliverables:
=A0
1. A requiremen= t and use case document with key consideration for SIP Session End-to-End I= dentification, including the definition of a "session"<= /u>

=A0
2. Speci= fication of new end-to-end Session Identifier mechanism
=A0
Goal and M= ilestone:

=A0
August 2= 012 - Requirement and use case document sent to the IESG (Informational)=
=A0
March 2013 - Specification of the new mechanism sent to the IESG (PS= )

=A0
= =A0

_____________________________________________= __
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--001636418291530dfe04b1b37776-- From paulej@packetizer.com Mon Nov 14 07:57:46 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6615B11E82D7 for ; Mon, 14 Nov 2011 07:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsupE9ygUi5l for ; Mon, 14 Nov 2011 07:57:43 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E825F11E828F for ; Mon, 14 Nov 2011 07:57:42 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pAEFveTA006229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Nov 2011 10:57:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321286261; bh=ruCtllWvvMaC1586usG+vw+T9cGEzT7VfXrK/eWP/9w=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=rLtty9g+ODxpKIh0NgvLvSAIQ6PTEa/2MuT9rxKVnIIYA3DCe2jamdx+Sq2gyB/dw dFs1C7jjz3yB9bDqgGMz4sh62dPh+XTIen8XuTcM1zf8BE80rur9kXONCjleN/W9nj 3Ghk/rxg8fzM+VG1AUczYWsN33ANwlahiAKBswDY= From: "Paul E. Jones" To: "'Michael Hammer'" References: <009f01cca1c3$df921810$9eb64830$@packetizer.com> In-Reply-To: Date: Mon, 14 Nov 2011 10:57:32 -0500 Message-ID: <035201cca2e6$1eddc550$5c994ff0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0353_01CCA2BC.3609B920" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMYOszw++k+njUFzeMbUGzHMgkChwI5AWT+kwONr8A= Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised Session-ID Charter (proposal) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 15:57:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0353_01CCA2BC.3609B920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:mphmmr@gmail.com] Sent: Monday, November 14, 2011 10:24 AM To: Paul E. Jones Cc: dispatch@ietf.org 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. 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 wrote: 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) _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_0353_01CCA2BC.3609B920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
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:mphmmr@gmail.com]
Sent: Monday, = November 14, 2011 10:24 AM
To: Paul E. Jones
Cc: = dispatch@ietf.org
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.

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 <paulej@packetizer.com> = wrote:
Folks,<= /o:p>
<= /o:p>
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.
<= /o:p>
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.
<= /o:p>
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.
<= /o:p>
Paul
<= /o:p>
------------= ---------------------------
<= /o:p>
End-to-end = Session Identifier in SIP (charter proposal)
<= /o:p>
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.
<= /o:p>
Unfortunatel= y, 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.
<= /o:p>
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.
<= /o:p>
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).
<= /o:p>
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.
<= /o:p>
The working = group will produce the following deliverables:
<= /o:p>
1. A = requirement and use case document with key consideration for SIP Session = End-to-End Identification, including the definition of a = "session"
<= /o:p>
2. = Specification of new end-to-end Session Identifier = mechanism
<= /o:p>
Goal and = Milestone:
<= /o:p>
August 2012 = - Requirement and use case document sent to the IESG = (Informational)
<= /o:p>
March 2013 = - Specification of the new mechanism sent to the IESG = (PS)
<= /o:p>
<= /o:p>

______________________________________= _________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch=

------=_NextPart_000_0353_01CCA2BC.3609B920-- From ietf@meetecho.com Mon Nov 14 10:37:22 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CC611E81EE for ; Mon, 14 Nov 2011 10:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBfONvj7Lxaq for ; Mon, 14 Nov 2011 10:37:21 -0800 (PST) Received: from smtpw2.aruba.it (smtpipvs3.aruba.it [62.149.128.188]) by ietfa.amsl.com (Postfix) with SMTP id 45C0E11E8227 for ; Mon, 14 Nov 2011 10:37:21 -0800 (PST) Received: (qmail 3534 invoked by uid 89); 14 Nov 2011 18:37:19 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw2.ad.aruba.it with SMTP; 14 Nov 2011 18:37:19 -0000 Date: Mon, 14 Nov 2011 19:37:19 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: dispatch@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 114.24.2.151 X-Spam-Rating: smtpw2.ad.aruba.it 1.6.2 0/1000/N Subject: [dispatch] Meetecho support for DISPATCH WG meeting session X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 18:37:22 -0000 Hi all,=0A=0Aa virtual room has been reserved on the Meetecho system for = tomorrow DISPATCH WG meeting session.=0A=0AAccess to the on-line session = (including audio and video streams) will be available from 9:00am at:=0Ah= ttp://www.meetecho.com/ietf82/dispatch=0A=0AThe Meetecho session automati= cally logs you into the standard IETF jabber room. So, from there, you ca= n have an integrated experience involving all media and allowing you to i= nteract with the room.=0A=0AA tutorial of interactivity features of the t= ool can be found at:=0Ahttp://www.meetecho.com/ietf82/tutorials=0A=0AFor = further information you can contact us at ietf-support@meetecho.com.=0A=0A= Cheers,=0Athe Meetecho team=0A=C2=A0=0A--=0AMeetecho s.r.l.=0AWeb Confere= ncing and Collaboration Tools=0Awww.meetecho.com=0A=C2=A0 From ietf@meetecho.com Mon Nov 14 10:43:29 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6186C11E82B0 for ; Mon, 14 Nov 2011 10:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHthV2JL1gz7 for ; Mon, 14 Nov 2011 10:43:28 -0800 (PST) Received: from smtpw2.aruba.it (smtpipvs3.aruba.it [62.149.128.188]) by ietfa.amsl.com (Postfix) with SMTP id 3DE3B11E81B0 for ; Mon, 14 Nov 2011 10:43:27 -0800 (PST) Received: (qmail 10913 invoked by uid 89); 14 Nov 2011 18:43:25 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw2.ad.aruba.it with SMTP; 14 Nov 2011 18:43:25 -0000 Date: Mon, 14 Nov 2011 19:43:25 +0100 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: dispatch@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 114.24.2.151 X-Spam-Rating: smtpw2.ad.aruba.it 1.6.2 0/1000/N Subject: Re: [dispatch] Meetecho support for DISPATCH WG meeting session - CORRECTION X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 18:43:29 -0000 Access to the on-line session will be available *from 1:00pm*, not 9:00am= ...=0A=0A=C2=A0=0ADa: dispatch-bounces@ietf.org=0AA: dispatch@ietf.org=0A= Cc: =0AData: Mon, 14 Nov 2011 19:37:19 +0100=0AOggetto: [dispatch] Meetec= ho support for DISPATCH WG meeting session=0A=0A> Hi all,=0A> =0A> a virt= ual room has been reserved on the Meetecho system for tomorrow DISPATCH W= G meeting session.=0A> =0A> Access to the on-line session (including audi= o and video streams) will be available from 9:00am at:=0A> http://www.mee= techo.com/ietf82/dispatch=0A> =0A> The Meetecho session automatically log= s you into the standard IETF jabber room. So, from there, you can have an= integrated experience involving all media and allowing you to interact w= ith the room.=0A> =0A> A tutorial of interactivity features of the tool c= an be found at:=0A> http://www.meetecho.com/ietf82/tutorials=0A> =0A> For= further information you can contact us at ietf-support@meetecho.com.=0A>= =0A> Cheers,=0A> the Meetecho team=0A> =C2=A0=0A> --=0A> Meetecho s.r.l.= =0A> Web Conferencing and Collaboration Tools=0A> www.meetecho.com=0A> =C2= =A0=0A> =0A> _______________________________________________=0A> dispatch= mailing list=0A> dispatch@ietf.org=0A> https://www.ietf.org/mailman/list= info/dispatch From dworley@avaya.com Mon Nov 14 10:58:54 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A6211E833F for ; Mon, 14 Nov 2011 10:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.327 X-Spam-Level: X-Spam-Status: No, score=-103.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4iqoMg3tgX9 for ; Mon, 14 Nov 2011 10:58:53 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8342111E8254 for ; Mon, 14 Nov 2011 10:58:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAGVjwU7GmAcF/2dsb2JhbABCnXKLdYEFgXIBAQEBAgESKD8FCwIBCA0BByEQIRElAQEEAQ0FCBqHYJw2m2yJHGMEiBCReIRxh0w X-IronPort-AV: E=Sophos;i="4.69,510,1315195200"; d="scan'208";a="277456703" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Nov 2011 13:58:38 -0500 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Nov 2011 13:57:32 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Mon, 14 Nov 2011 13:58:37 -0500 From: "Worley, Dale R (Dale)" To: Michael Hammer , "Paul E. Jones" Date: Mon, 14 Nov 2011 13:54:19 -0500 Thread-Topic: [dispatch] Revised Session-ID Charter (proposal) Thread-Index: Acyi4a0j2ia3qVzIRpagd+K08SgOsAAHSNw/ Message-ID: References: <009f01cca1c3$df921810$9eb64830$@packetizer.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Revised Session-ID Charter (proposal) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 18:58:54 -0000 > From: Michael Hammer [mphmmr@gmail.com] >=20 > 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 From mary.ietf.barnes@gmail.com Mon Nov 14 18:11:57 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1666311E8087 for ; Mon, 14 Nov 2011 18:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6NENOLy9G7v for ; Mon, 14 Nov 2011 18:11:56 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82F7121F8D32 for ; Mon, 14 Nov 2011 18:11:56 -0800 (PST) Received: by vws5 with SMTP id 5so6862203vws.31 for ; Mon, 14 Nov 2011 18:11:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=xASvIGLg0FZWvB2/iFLpI/rYGrodRwl7zVYtV7sDqo0=; b=oUhPVCgPLkisj+Iponj7Vfq7V5sUNC4rP5I6ObYpQ+g/LH6if3ROd6mhLUiqGzwkDB mZgvFaKe99FLPp2fFBO85eDMFel2tszP9jfrce0Da1/5xZYRswsHJJe+A7PssAlQ6bR9 cUlCwU3oGrzI6QzcYL0pWrw0kaGTANOvryRU4= MIME-Version: 1.0 Received: by 10.52.65.176 with SMTP id y16mr39678258vds.53.1321323116028; Mon, 14 Nov 2011 18:11:56 -0800 (PST) Received: by 10.52.175.131 with HTTP; Mon, 14 Nov 2011 18:11:56 -0800 (PST) Date: Mon, 14 Nov 2011 20:11:56 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Subject: [dispatch] Change to DISPATCH agenda for this afternoon's session X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:11:57 -0000 Hi all, We have updated the agenda for the DISPATCH WG session this afternoon as we did not receive charts for the SIP Continuation discussion. Rather than let folks have any free time, we have added the STRAW charter proposal to the agenda, so folks can revisit that during lunch in preparation for the session at 13:00: http://www.ietf.org/proceedings/82/agenda/dispatch.html (You may need to refresh your browser to see the updated version) Note that the chairs agenda/status charts in the meeting materials is not yet uploaded as the server is overloaded. I'll upload as soon as possible. Also, please let the chairs know if you are willing to be a notetaker or a jabber scribe. Regards, Mary. From ietf@meetecho.com Tue Nov 15 06:03:20 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F6621F8B0B for ; Tue, 15 Nov 2011 06:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuIWulDEPLj3 for ; Tue, 15 Nov 2011 06:03:19 -0800 (PST) Received: from smtpw2.aruba.it (smtpipvs3.aruba.it [62.149.128.188]) by ietfa.amsl.com (Postfix) with SMTP id 4032921F8AF8 for ; Tue, 15 Nov 2011 06:03:19 -0800 (PST) Received: (qmail 31776 invoked by uid 89); 15 Nov 2011 14:03:16 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw2.ad.aruba.it with SMTP; 15 Nov 2011 14:03:16 -0000 Date: Tue, 15 Nov 2011 15:03:17 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: dispatch@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 130.129.21.177 X-Spam-Rating: smtpw2.ad.aruba.it 1.6.2 0/1000/N Subject: [dispatch] DISPATCH session recording available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 14:03:20 -0000 Dear all,=0A=0Athe full recording (synchronized video, audio, slides and = jabber room)=0Aof today's DISPATCH session is available.=0A=0AYou can wat= ch it by either clicking the proper link on the remote participation page= (http://www.ietf.org/meeting/82/remote-participation.html#Meetecho), or = by directly accessing the following URL:=0Ahttp://www.meetecho.com/ietf82= /recordings=0A=0AFor the chair(s): please feel free to put the link to th= e recording in the minutes, if you think this might be useful.=0A=0AIn ca= se of problems with the playout, just drop an e-mail to=0Aietf-support@me= etecho.com.=0A=0ACheers,=0Athe Meetecho Team=0A =0A--=0AMeetecho s.r.l.=0A= Web Conferencing and Collaboration Tools=0Awww.meetecho.com=0A From HKaplan@acmepacket.com Wed Nov 16 08:29:48 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812A721F93A1 for ; Wed, 16 Nov 2011 08:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1QB46iVZkdN for ; Wed, 16 Nov 2011 08:29:48 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id D0B7021F938C for ; Wed, 16 Nov 2011 08:29:47 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 16 Nov 2011 11:29:45 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 16 Nov 2011 11:29:45 -0500 From: Hadriel Kaplan To: "Paul E. Jones" Thread-Topic: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints Thread-Index: AQHMpHzymAn8407UdEuMNPz2gV5MpA== Date: Wed, 16 Nov 2011 16:29:44 +0000 Message-ID: <6E4B7758-123D-4677-929C-56776CA7155B@acmepacket.com> References: <01af01cca093$ce85e5a0$6b91b0e0$@packetizer.com> <8B269C87-2B41-4F83-A7C9-3443E05E323B@acmepacket.com> <008e01cca1c0$8f3527c0$ad9f7740$@packetizer.com> <98C324EC-A04C-4490-9E5F-A0D44E9C49BA@acmepacket.com> <01d801cca283$3410bf30$9c323d90$@packetizer.com> In-Reply-To: <01d801cca283$3410bf30$9c323d90$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <701337C019ACDF4E9CBD0621A1798116@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 16:29:48 -0000 Hi Paul, this email's getting long so I'm splitting into two separate responses for = different topics. Comments inline... On Nov 13, 2011, at 11:09 PM, Paul E. Jones wrote: >> I don't know what "signaling/media correlation" really means or implies >> from a SIP protocol perspective interacting with Session-ID. >=20 > I would like to be able to use this in other protocols like RSVP. The > network would then be able to see that a given set of flows are related. You mean you're going to put the Session-ID value into RSVP path/resv messa= ges?? Is this so that two separate reservations can share fate or policy limit? >> I would categorize "logging", "troubleshooting", and "call-tracing" as >> all the same topic, and you *do* get them without having to update >> Alice's Session-ID; the UUID she created for the original call to Bob is >> the same one used in the new dialog to Carol. Each UUID of the two used >> in a Session-ID is independently usable for tracking across the networks >> - that's one of the reasons I suggested that if we go with this approach >> we make them separate token fields, to make that more obvious/clear. >=20 > These are certainly related, but we have to be careful. You're right tha= t > *if* we go with the approach we propose, the value Alice produced would b= e > useful by itself -- and that was intended. However, if I had a managemen= t > system that was trying to identify a given call at a given point in time,= it > would be useful that I could query a set of intermediary devices and > determine the signaling path, for example. If we do not update Alice, th= en > it is entirely possible that we lose that end-to-end concept. We might h= ave > this series of connections > Alice -> SBC1 -> SBC2 -> SBC3 -> SBC4 -> Carol >=20 > After a few service interactions, perhaps SBC3 believes that the Session = ID > is {X|Y} when Alice thinks it is {A|B} and Carol thinks it is {C|D}. True and good point. I would note, though, that even if the info was "upda= ted" and Alice starts using a new Session-ID, it doesn't cover everything b= ecause a REFER does not terminate a dialog. The dialog to Bob still exists= . I think that's ok from your perspective because I think you're trying to= make the Session-ID follow the dialog path with active media, right?=20 -hadriel From HKaplan@acmepacket.com Wed Nov 16 08:44:55 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D389821F948A for ; Wed, 16 Nov 2011 08:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkRTpS6l5HcO for ; Wed, 16 Nov 2011 08:44:55 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA3A21F9489 for ; Wed, 16 Nov 2011 08:44:54 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 16 Nov 2011 11:44:52 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 16 Nov 2011 11:44:52 -0500 From: Hadriel Kaplan To: "Paul E. Jones" Thread-Topic: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints Thread-Index: AQHMpH8Pu6o6kmgMKUG9q7wdZQkueA== Date: Wed, 16 Nov 2011 16:44:50 +0000 Message-ID: <0E63C2EE-81B6-45CD-8B67-7216DB69DAD7@acmepacket.com> References: <01af01cca093$ce85e5a0$6b91b0e0$@packetizer.com> <8B269C87-2B41-4F83-A7C9-3443E05E323B@acmepacket.com> <008e01cca1c0$8f3527c0$ad9f7740$@packetizer.com> <98C324EC-A04C-4490-9E5F-A0D44E9C49BA@acmepacket.com> <01d801cca283$3410bf30$9c323d90$@packetizer.com> In-Reply-To: <01d801cca283$3410bf30$9c323d90$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <41A43EAB64E3C643976A0B35C2A79AA0@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 16:44:55 -0000 Part-2 inline below... On Nov 13, 2011, at 11:09 PM, Paul E. Jones wrote: >>> We wanted a Session-ID that is end-to-end, so Alice needs to know if >>> an identifier changes so she can take appropriate action. >>=20 >> So what is this "action"? What change to SIP processing rules or >> application logic are we trying to enable with a Session-ID? (I don't >> count "logging/troubleshooting" as an actionable processing change) >=20 > Start logging the right value, sending the right value in RTCP. Perhaps s= end > a new PATH message with the new value, etc. The actions are outside the > scope of SIP, but we want to be able to use this value. >=20 >>> If we did not change this value, then we might actually have multiple >>> devices reporting that they are the same Session-ID when, in fact, >>> they're not. Consider Alice calling Bob and then both devices being >>> redirected elsewhere. If they were not made aware of a change in the >>> opposite endpoint, they would both log the same Session-ID even after >>> the they were no longer communicating with each other and >>> communicating with some other endpoint. >>=20 >> Yes, that was raised as an issue in the original session-id concept as >> well. Luckily it didn't matter because session-id was only being used >> for troubleshooting/logging. That's why I'm trying to figure out what >> else this new WG plans to actually do with Session-ID at a SIP layer, >> that would break SIP if things didn't go as planned/expected. >=20 > I do not propose that the WG do anything with the Session-ID. I only wan= t > us to define one where all devices have a common understanding of what th= e > value is. Once we do that, then we can actually rely on it for something > else meaningful. But, that will be another WG and another charter ;-) The big concern I have with anyone using the Session-ID for anything other = than troubleshooting/logging, is that SBCs will invariably end up having to= go change the Session-ID in certain call scenarios to purposefully be some= thing that does not match both sides, simply to counter-act whatever clever= mechanism someone's decided to use Session-ID for. There are lots of reas= ons that could happen, from fixing bugs to fixing scenarios their clever sc= heme didn't take into account and breaks stuff for, to just plain not wanti= ng the clever mechanism to happen due to some policy reasons. If that happ= ens, we lose the ability to use Session-ID for troubleshooting. We've gone over examples of cases where that could happen in email threads = of my earlier Session-ID drafts, which is why I ended up changing the draft= s to *only* make it used for logging/troubleshooting. =20 I know some people in the IETF don't care much about having a header value = purely for troubleshooting correlation, but we hear this desire time and ti= me again from the people who run/manage SIP networks. (I'm not saying you d= on't want that too - I'm just saying a header for troubleshooting alone is = worth having) -hadriel From paulej@packetizer.com Wed Nov 16 09:25:43 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4111E21F9451 for ; Wed, 16 Nov 2011 09:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+6pvY0JxWC7 for ; Wed, 16 Nov 2011 09:25:42 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A5F4021F944A for ; Wed, 16 Nov 2011 09:25:42 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pAGHPcYq018791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Nov 2011 12:25:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321464339; bh=UGdSUv0QoTMHLNz/bZepemf3DzhIhgQyWlfDH1SStoU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=p07EaCmg3KfAhDx5lvsKJeDy3Sy37mzHdXZMQ8W0vcUNDxBLfav5Yik/b5nGGvey2 YOj13NqU++isdEhwCQ4ZXp/jvjOw9ZCAO5AAwJGXGoGKgcyaXWoDCu9kohKqf/oCGf cArcZ8RsC5msdWRG/A4utt76X4LUmCpe9VrK738Q= From: "Paul E. Jones" To: "'Hadriel Kaplan'" References: <01af01cca093$ce85e5a0$6b91b0e0$@packetizer.com> <8B269C87-2B41-4F83-A7C9-3443E05E323B@acmepacket.com> <008e01cca1c0$8f3527c0$ad9f7740$@packetizer.com> <98C324EC-A04C-4490-9E5F-A0D44E9C49BA@acmepacket.com> <01d801cca283$3410bf30$9c323d90$@packetizer.com> <6E4B7758-123D-4677-929C-56776CA7155B@acmepacket.com> In-Reply-To: <6E4B7758-123D-4677-929C-56776CA7155B@acmepacket.com> Date: Wed, 16 Nov 2011 12:25:26 -0500 Message-ID: <010c01cca484$bb74e3e0$325eaba0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM4kK2PtwYoA4yO/2keicmD4G9X/gD/RGHTAXK6cSMCLKWx1gJ50BrFAaksWKACm0w3s5J89rPQ Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 17:25:43 -0000 Hadriel, > > I would like to be able to use this in other protocols like RSVP. The > > network would then be able to see that a given set of flows are > related. > > You mean you're going to put the Session-ID value into RSVP path/resv > messages?? > Is this so that two separate reservations can share fate or policy > limit? Yes, that's one sort of thing we had in mind. We also considered using it to identify a PATH message as belong to a given call, since these two are otherwise disjoint. > > After a few service interactions, perhaps SBC3 believes that the > > Session ID is {X|Y} when Alice thinks it is {A|B} and Carol thinks it > is {C|D}. > > True and good point. I would note, though, that even if the info was > "updated" and Alice starts using a new Session-ID, it doesn't cover > everything because a REFER does not terminate a dialog. The dialog to > Bob still exists. I think that's ok from your perspective because I > think you're trying to make the Session-ID follow the dialog path with > active media, right? If I understand you correctly, I think it would be OK because when a device is REFERRed somewhere, a new and different end-to-end Session ID would be constructed. In our proposal, we suggest the referred-party re-use its Session-UUID for the call, as it helps to establish a trail. However, that's a nice bi-product of the approach we're taking and not a hard requirement. Paul From paulej@packetizer.com Wed Nov 16 09:40:48 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2781511E8093 for ; Wed, 16 Nov 2011 09:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDSU38w-Fe3U for ; Wed, 16 Nov 2011 09:40:47 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id EC10D21F9468 for ; Wed, 16 Nov 2011 09:40:38 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pAGHeZ4t019130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Nov 2011 12:40:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1321465236; bh=Qojs9Qw7Cr/TR5vt6nQpo3vwQg7wmT6PrRYcBxdmjgI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=cYCHjeuLjiAKAJCY/Qb+3W4diBGOgrHYRjqB88pLJ+4u9KCy4Rkv8Qi+vpMDJivQ0 1YCrQhiz5tVIh4YNTlSf/IZgWzZZcRXcixLxd4KMkbyspikuHBhxKmh/XVyBjUFw/Q ttvZ5rsIPoofoA0qRf5UnLgahamm2PO0xj/Dj0XM= From: "Paul E. Jones" To: "'Hadriel Kaplan'" References: <01af01cca093$ce85e5a0$6b91b0e0$@packetizer.com> <8B269C87-2B41-4F83-A7C9-3443E05E323B@acmepacket.com> <008e01cca1c0$8f3527c0$ad9f7740$@packetizer.com> <98C324EC-A04C-4490-9E5F-A0D44E9C49BA@acmepacket.com> <01d801cca283$3410bf30$9c323d90$@packetizer.com> <0E63C2EE-81B6-45CD-8B67-7216DB69DAD7@acmepacket.com> In-Reply-To: <0E63C2EE-81B6-45CD-8B67-7216DB69DAD7@acmepacket.com> Date: Wed, 16 Nov 2011 12:40:23 -0500 Message-ID: <011601cca486$d1f132c0$75d39840$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM4kK2PtwYoA4yO/2keicmD4G9X/gD/RGHTAXK6cSMCLKWx1gJ50BrFAaksWKAB8y/1mJKCQjYg Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 17:40:48 -0000 Hadriel, > > I do not propose that the WG do anything with the Session-ID. I only > > want us to define one where all devices have a common understanding of > > what the value is. Once we do that, then we can actually rely on it > > for something else meaningful. But, that will be another WG and > > another charter ;-) > > The big concern I have with anyone using the Session-ID for anything > other than troubleshooting/logging, is that SBCs will invariably end up > having to go change the Session-ID in certain call scenarios to > purposefully be something that does not match both sides, simply to > counter-act whatever clever mechanism someone's decided to use Session- > ID for. There are lots of reasons that could happen, from fixing bugs > to fixing scenarios their clever scheme didn't take into account and > breaks stuff for, to just plain not wanting the clever mechanism to > happen due to some policy reasons. If that happens, we lose the ability > to use Session-ID for troubleshooting. I would hope people do not introduce "clever" mechanisms. I'd very much like the rules to be well-defined. Once the rules are defined, then we could use Session-ID for other things, but I would not expect there to be changes to SIP as a result. For SIP, there should one and only one way of signaling the Session-ID. With those well-defined rules, then we should be able to rely on it for other things, but I don't want to define those other things yet. If all we get is logging, then it's still worth the effort. I just hope we can use it more broadly. > We've gone over examples of cases where that could happen in email > threads of my earlier Session-ID drafts, which is why I ended up > changing the drafts to *only* make it used for logging/troubleshooting. If we work through use cases and hit a wall, that would be reason for concern. I do think we can make it work, though. It would require functionality on the B2BUA that decides to re-route calls, etc., but that will happen with time. > I know some people in the IETF don't care much about having a header > value purely for troubleshooting correlation, but we hear this desire > time and time again from the people who run/manage SIP networks. (I'm > not saying you don't want that too - I'm just saying a header for > troubleshooting alone is worth having) So, aim high... :) Paul From richard@shockey.us Sat Nov 19 12:21:22 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269B021F84CE for ; Sat, 19 Nov 2011 12:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.773 X-Spam-Level: X-Spam-Status: No, score=-99.773 tagged_above=-999 required=5 tests=[AWL=0.722, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjYucudYZcI5 for ; Sat, 19 Nov 2011 12:21:21 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 6AC3421F84B8 for ; Sat, 19 Nov 2011 12:21:21 -0800 (PST) Received: (qmail 17429 invoked by uid 0); 19 Nov 2011 20:21:19 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com with SMTP; 19 Nov 2011 20:21:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=iypjhVuu/1lV+/38XHBBKxevedxpVFIZCpgaQLp6KmY=; b=mf2O2Lt4TbCCYole0w605WVqVrfYbeOpkrkGhX1Pfo7ew0/OSO/+TXbrRmNzCRYycrPjL00b5EOg5STVifxH5fSbRJX9ebE6rQnzSDoEK4xj6XY1ILQEqOjR2g42oe5v; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RRrPb-0005s6-H7 for dispatch@ietf.org; Sat, 19 Nov 2011 13:21:19 -0700 From: "Richard Shockey" To: Date: Sat, 19 Nov 2011 15:21:18 -0500 Message-ID: <001101cca6f8$cc241a00$646c4e00$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyaiM88cFeg7LLRTZ6X4PaMqC0uRQADVlCAAAEjMrAAvQsaYAJZXDaQAAEX7mA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Subject: [dispatch] FW: The US Federal Communications Commission just sent the RAI/SIP community its Thanksgiving Turkey ... X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 20:21:22 -0000 I sent this to the full IETF Discussion list but for those of you that don't subscribe. -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Saturday, November 19, 2011 2:55 PM To: 'IETF-Discussion list' Subject: RE: The US Federal Communications Commission just sent the RAI/SIP community its Thanksgiving Turkey ... Just in case you don't have anything interesting to read on the plane back from Tiawan. http://transition.fcc.gov/Daily_Releases/Daily_Business/2011/db1118/FCC-11-1 61A1.pdf Selected passages of possible interest to the IETF RAI/SIP community are Pages 29-32 210-240 268-292 380-383 459-458 Does this mean that a "carrier" that recently jumped in the voice market (it could be either an ISP now providing VOIP to their customers along with a data bundle that -or- a VOIP-specialized carrier that leverages the IP bandwidth provided to the customer by another ISP) now has some leverage to go to the FCC to "require" (note the quotes) another "carrier" that historically has been in the traditional business of copper/TDM to connect primarily using IP/SIP? [RS> ] Yep that's the idea! Negotiations are to be in "good faith" of course. No I have no idea what that means. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf