From jmpolk@cisco.com Tue Mar 6 14:09:41 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E49B21E8013 for ; Tue, 6 Mar 2012 14:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.599 X-Spam-Level: X-Spam-Status: No, score=-109.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 LyQBvBkXEghS for ; Tue, 6 Mar 2012 14:09:41 -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 26EC321E8032 for ; Tue, 6 Mar 2012 14:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2; q=dns/txt; s=iport; t=1331071781; x=1332281381; h=message-id:date:to:from:subject:mime-version; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=iJjUdVGgTPHvWBF4sx4GaYKCZmZwQ22BcLdiN5qlmQBPB/uGPCoCUXEN w2QOqKtzQz1WGAdxOcs4+FUn1z4tCzLJE79gXnkf7Uh6ztjS+AYh0obzj PyVgpwWmAFdI4sQz8Lar9qhn7BCoZ6g6Ww8SPj/bRRGayUSqCpZUPOsFs w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUHAKKKVk+rRDoJ/2dsb2JhbABDh3KtDoEHghYBBh8CVjopeYdkmRiBJwGfF41OgyIEiFKdA4MC X-IronPort-AV: E=Sophos;i="4.73,542,1325462400"; d="scan'208";a="34859345" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 06 Mar 2012 22:09:41 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q26M9Z1Y021372 for ; Tue, 6 Mar 2012 22:09:39 GMT Message-Id: <201203062209.q26M9Z1Y021372@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 06 Mar 2012 16:09:30 -0600 To: insipid@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] test, please ignore X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:09:41 -0000 From jmpolk@cisco.com Tue Mar 6 15:22:04 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CABB21E8026; Tue, 6 Mar 2012 15:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.668 X-Spam-Level: X-Spam-Status: No, score=-109.668 tagged_above=-999 required=5 tests=[AWL=0.931, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 A8o970q5wS8O; Tue, 6 Mar 2012 15:22:03 -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 5EC6521E800F; Tue, 6 Mar 2012 15:22:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2731; q=dns/txt; s=iport; t=1331076123; x=1332285723; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=Tdi4ZRJHcsao0wQEkcaJU3kjxcrFAGtQgzNv7EJrIsI=; b=nG1O3m7s8e4BoJ1ur5Awk5MCtzSwtiLlxEzctI0TihfVwPQTIEzkBVWM rTp8L6n0fAOfb6ATO3D5c+LWPSY/c0oXJqTtxbJoqB7cFVsLvtOjjlK3H r+RpJLY7AZR1CsFR+DWGqBDGA64F+++XFwmHeMB7heFvriTb4jHn0ALeH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOibVk+rRDoJ/2dsb2JhbABDDrUBgQeBfQEBAQQBAQEPASUCNBcEBwQOAwQBAQEeCQcZDh8JCAYBCQkJGYdkDKBaAZcxkHAEiFKdA4IsVg X-IronPort-AV: E=Sophos;i="4.73,542,1325462400"; d="scan'208";a="32275633" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 06 Mar 2012 23:22:03 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q26NM2BT020676; Tue, 6 Mar 2012 23:22:02 GMT Message-Id: <201203062322.q26NM2BT020676@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 06 Mar 2012 17:22:01 -0600 To: Paul Kyzivat , dispatch@ietf.org, insipid@ietf.org From: "James M. Polk" In-Reply-To: <4F567918.5080009@alum.mit.edu> References: <4F4F5C19.9070607@ericsson.com> <030e01ccfbcf$c07b7460$41725d20$@packetizer.com> <4F567918.5080009@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Insipid] [dispatch] Charter process for the INSIPID WG X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 23:22:04 -0000 At 02:52 PM 3/6/2012, Paul Kyzivat wrote: >On 3/6/12 2:31 PM, Paul E. Jones wrote: >>Gonzalo, >> >>I would suggest adding the following text to the end of the second paragraph >>of the charter: >>"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." >> >>This is text we introduced in a later version of the charter. > >These words don't mention any constraints that should be imposed >wile considering this. So the outcome might or might not specify >that such changes do or don't preserve the session id. > >Is that what you are looking for? > > Thanks, > Paul May I suggest that folks interested in this subject take their discussions over to the NEW INSIPID list at insipid@ietf.org after they register into that list. This will clear up DISPATCH from hearing about this, while focusing Session-ID talk to the IPSIPID list, which is more appropriate IMO. James >>Paul >> >>>-----Original Message----- >>>From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>>Behalf Of Gonzalo Camarillo >>>Sent: Thursday, March 01, 2012 6:23 AM >>>To: DISPATCH >>>Subject: [dispatch] Charter process for the INSIPID WG >>> >>>Folks, >>> >>>Robert and I have been working on a charter proposal for the INSIPID WG. >>>This is the proposal that we have sent for review to the IESG and IAB: >>> >>>http://www.ietf.org/iesg/evaluation/sessionid-charter.txt >>> >>>We believe this proposal represents the consensus of the group. Note that >>>we have left out some comments that failed to get rough consensus on this >>>list. >>> >>> From now on, I will be taking care of the chartering process for this WG. >>>Today, I will discuss the charter proposal with the IESG and, if >>>everything goes OK, we will be sending it for external review shortly. >>>If you have further comments on the charter proposal, please send them as >>>part of its external review, which will be announced on the IETF >>>announcement list as usual. >>> >>>Also, I am going to be requesting the creation of the insipid mailing >>>list. >>> >>>Cheers, >>> >>>Gonzalo >>> >>>_______________________________________________ >>>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 mary.ietf.barnes@gmail.com Tue Mar 6 16:31:33 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E46621F8691; Tue, 6 Mar 2012 16:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.747 X-Spam-Level: X-Spam-Status: No, score=-102.747 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 pimwtVGkap4Q; Tue, 6 Mar 2012 16:31:32 -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 38B8821F8684; Tue, 6 Mar 2012 16:31:29 -0800 (PST) Received: by vbbez10 with SMTP id ez10so5726609vbb.31 for ; Tue, 06 Mar 2012 16:31:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ej1pS68htU5MpIOX6b1GcBn+wLMQ1dbSnNAGonANmbs=; b=Bc1vyFH8hEaULGFl+41MVMUw/F8olGAX42j+jJRnO6DiIArtSjws1TOmE/fxpK/RK/ y8aG/oJd/uDcX6JDcNMB5D5gR8crf2QQTDsoYVJaWjKCek40k8PMcpHp6gjZjivWMkks HCb9gQ1aKjSnfyY6eVoCouRm1azocki9Zdp5em7ofWEKdBwXYEuMV1MRIZYQsh8lBSeU sedyrxTT52wGFFiKKO63p2rONNv7W/A8GDF1BV6UsniOCkhSEHH0tIaQcnXuSHzZi7eC 5S1d/l2QKezj13KueHFknj/maBtMvLHCe0EL6+QAfaRAE81de/VjW+2zw1FI/XHCo6gD eaVg== MIME-Version: 1.0 Received: by 10.52.28.200 with SMTP id d8mr75653vdh.38.1331080288780; Tue, 06 Mar 2012 16:31:28 -0800 (PST) Received: by 10.52.111.136 with HTTP; Tue, 6 Mar 2012 16:31:28 -0800 (PST) In-Reply-To: <201203062322.q26NM2BT020676@mtv-core-4.cisco.com> References: <4F4F5C19.9070607@ericsson.com> <030e01ccfbcf$c07b7460$41725d20$@packetizer.com> <4F567918.5080009@alum.mit.edu> <201203062322.q26NM2BT020676@mtv-core-4.cisco.com> Date: Tue, 6 Mar 2012 18:31:28 -0600 Message-ID: From: Mary Barnes To: "James M. Polk" Content-Type: multipart/alternative; boundary=20cf3079bc9ec7c3a604ba9c47a8 X-Mailman-Approved-At: Tue, 06 Mar 2012 20:35:56 -0800 Cc: dispatch@ietf.org, insipid@ietf.org, Paul Kyzivat Subject: Re: [Insipid] [dispatch] Charter process for the INSIPID WG X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 00:31:33 -0000 --20cf3079bc9ec7c3a604ba9c47a8 Content-Type: text/plain; charset=ISO-8859-1 Personally, I think we should keep charter discussions on DISPATCH for now. I agree that discussing solution details should happen on the INSIPID list. Thanks, Mary On Tue, Mar 6, 2012 at 5:22 PM, James M. Polk wrote: > At 02:52 PM 3/6/2012, Paul Kyzivat wrote: > >> On 3/6/12 2:31 PM, Paul E. Jones wrote: >> >>> Gonzalo, >>> >>> I would suggest adding the following text to the end of the second >>> paragraph >>> of the charter: >>> "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." >>> >>> This is text we introduced in a later version of the charter. >>> >> >> These words don't mention any constraints that should be imposed wile >> considering this. So the outcome might or might not specify that such >> changes do or don't preserve the session id. >> >> Is that what you are looking for? >> >> Thanks, >> Paul >> > > May I suggest that folks interested in this subject take their discussions > over to the NEW INSIPID list at insipid@ietf.org after they register into > that list. > > This will clear up DISPATCH from hearing about this, while focusing > Session-ID talk to the IPSIPID list, which is more appropriate IMO. > > James > > > > Paul >>> >>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.**org] >>>> On >>>> Behalf Of Gonzalo Camarillo >>>> Sent: Thursday, March 01, 2012 6:23 AM >>>> To: DISPATCH >>>> Subject: [dispatch] Charter process for the INSIPID WG >>>> >>>> Folks, >>>> >>>> Robert and I have been working on a charter proposal for the INSIPID WG. >>>> This is the proposal that we have sent for review to the IESG and IAB: >>>> >>>> http://www.ietf.org/iesg/**evaluation/sessionid-charter.**txt >>>> >>>> We believe this proposal represents the consensus of the group. Note >>>> that >>>> we have left out some comments that failed to get rough consensus on >>>> this >>>> list. >>>> >>>> From now on, I will be taking care of the chartering process for this >>>> WG. >>>> Today, I will discuss the charter proposal with the IESG and, if >>>> everything goes OK, we will be sending it for external review shortly. >>>> If you have further comments on the charter proposal, please send them >>>> as >>>> part of its external review, which will be announced on the IETF >>>> announcement list as usual. >>>> >>>> Also, I am going to be requesting the creation of the insipid mailing >>>> list. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> ______________________________**_________________ >>>> 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 >> > > ______________________________**_________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/**listinfo/dispatch > --20cf3079bc9ec7c3a604ba9c47a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Personally, I think we should keep charter discussions on DISPATCH for now.= =A0I agree that discussing solution details should happen on the INSIPID l= ist.

Thanks,
Mary=A0

On Tue, Mar 6, 2012 at 5:22 PM, James M. Polk <jmpolk@cisco.com> wrote:
At 02:52 PM 3/6/2012, Paul Kyzivat wrote:
On 3/6/12 2:31 PM, Paul E. Jones wrote:
Gonzalo,

I would suggest adding the following text to the end of the second paragrap= h
of the charter:
"Consideration must be given to the fact that the entities involved in= a
communication session might change as a result of service interaction in th= e
network, such as call transfers, joins, etc."

This is text we introduced in a later version of the charter.

These words don't mention any constraints that should be imposed wile c= onsidering this. So the outcome might or might not specify that such change= s do or don't preserve the session id.

Is that what you are looking for?

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

May I suggest that folks interested in this subject take their discussions = over to the NEW INSIPID list at insipid@ietf.org after they register into that list.

This will clear up DISPATCH from hearing about this, while focusing Session= -ID talk to the IPSIPID list, which is more appropriate IMO.

James



Paul

-----Original Message-----
From: dispat= ch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Gonzalo Camarillo
Sent: Thursday, March 01, 2012 6:23 AM
To: DISPATCH
Subject: [dispatch] Charter process for the INSIPID WG

Folks,

Robert and I have been working on a charter proposal for the INSIPID WG. This is the proposal that we have sent for review to the IESG and IAB:

http://www.ietf.org/iesg/evaluation/sessionid-charter.<= u>txt

We believe this proposal represents the consensus of the group. Note that we have left out some comments that failed to get rough consensus on this list.

=A0From now on, I will be taking care of the chartering process for this WG= .
Today, I will discuss the charter proposal with the IESG and, if
everything goes OK, we will be sending it for external review shortly.
If you have further comments on the charter proposal, please send them as part of its external review, which will be announced on the IETF
announcement list as usual.

Also, I am going to be requesting the creation of the insipid mailing
list.

Cheers,

Gonzalo

_______________________________________________
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

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

--20cf3079bc9ec7c3a604ba9c47a8-- From mary.ietf.barnes@gmail.com Tue Mar 6 16:34:38 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D3221F8698; Tue, 6 Mar 2012 16:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.734 X-Spam-Level: X-Spam-Status: No, score=-102.734 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 Q0wTp2wOSE0K; Tue, 6 Mar 2012 16:34:37 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 36C4F21F8692; Tue, 6 Mar 2012 16:34:37 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so5758117vcb.31 for ; Tue, 06 Mar 2012 16:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hfEUu8OOI2x3+PHwnAlJevMZz1/QVKw/J1DsrlcjXTs=; b=hlktm1LWwI92eG1fUpNbXJw7AwBg9yhVLxdzE5pRv8gKQYQzTlqAcVyOOgzNuqAtsn F6nR+w0Nu1K4L6bsCb/JcOhfFLCJ35pLtzeilK5X0bYGfZZqhAqUUSwjbw3gAYEyJ6rE iDz88yF9Gci7Bf/59CJJo29QXwZDXIkigx+/XsOLapkiWn84Gys7Im6vXTlBOarGNAw6 nl+x4GgX8XeakmHpMAWX8DpUHEteIqqZIHXBxCo7YJAKkvK50OLbH0jxmS+Ncyy3LiSU 9kcIZ81oc3miVLLY1fU/pclxHmvzWUNSaVsQ/NgyTc9ko2MP+cArLOwM0YFkkW4RB2Ff V1BQ== MIME-Version: 1.0 Received: by 10.52.88.103 with SMTP id bf7mr30675vdb.72.1331080476549; Tue, 06 Mar 2012 16:34:36 -0800 (PST) Received: by 10.52.111.136 with HTTP; Tue, 6 Mar 2012 16:34:36 -0800 (PST) In-Reply-To: <201203062322.q26NM2BT020676@mtv-core-4.cisco.com> References: <4F4F5C19.9070607@ericsson.com> <030e01ccfbcf$c07b7460$41725d20$@packetizer.com> <4F567918.5080009@alum.mit.edu> <201203062322.q26NM2BT020676@mtv-core-4.cisco.com> Date: Tue, 6 Mar 2012 18:34:36 -0600 Message-ID: From: Mary Barnes To: "James M. Polk" Content-Type: multipart/alternative; boundary=20cf307f3c04f8e35b04ba9c5248 X-Mailman-Approved-At: Tue, 06 Mar 2012 20:35:56 -0800 Cc: rai-ads@tools.ietf.org, dispatch@ietf.org, insipid@ietf.org, Paul Kyzivat Subject: Re: [Insipid] [dispatch] Charter process for the INSIPID WG X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 00:34:38 -0000 --20cf307f3c04f8e35b04ba9c5248 Content-Type: text/plain; charset=ISO-8859-1 Also, did anyone ever send an email to DISPATCH announcing the new mailing list? I can't find anything in the archives nor was anything posted on the RAI area mailing list. Mary. On Tue, Mar 6, 2012 at 5:22 PM, James M. Polk wrote: > At 02:52 PM 3/6/2012, Paul Kyzivat wrote: > >> On 3/6/12 2:31 PM, Paul E. Jones wrote: >> >>> Gonzalo, >>> >>> I would suggest adding the following text to the end of the second >>> paragraph >>> of the charter: >>> "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." >>> >>> This is text we introduced in a later version of the charter. >>> >> >> These words don't mention any constraints that should be imposed wile >> considering this. So the outcome might or might not specify that such >> changes do or don't preserve the session id. >> >> Is that what you are looking for? >> >> Thanks, >> Paul >> > > May I suggest that folks interested in this subject take their discussions > over to the NEW INSIPID list at insipid@ietf.org after they register into > that list. > > This will clear up DISPATCH from hearing about this, while focusing > Session-ID talk to the IPSIPID list, which is more appropriate IMO. > > James > > > > Paul >>> >>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.**org] >>>> On >>>> Behalf Of Gonzalo Camarillo >>>> Sent: Thursday, March 01, 2012 6:23 AM >>>> To: DISPATCH >>>> Subject: [dispatch] Charter process for the INSIPID WG >>>> >>>> Folks, >>>> >>>> Robert and I have been working on a charter proposal for the INSIPID WG. >>>> This is the proposal that we have sent for review to the IESG and IAB: >>>> >>>> http://www.ietf.org/iesg/**evaluation/sessionid-charter.**txt >>>> >>>> We believe this proposal represents the consensus of the group. Note >>>> that >>>> we have left out some comments that failed to get rough consensus on >>>> this >>>> list. >>>> >>>> From now on, I will be taking care of the chartering process for this >>>> WG. >>>> Today, I will discuss the charter proposal with the IESG and, if >>>> everything goes OK, we will be sending it for external review shortly. >>>> If you have further comments on the charter proposal, please send them >>>> as >>>> part of its external review, which will be announced on the IETF >>>> announcement list as usual. >>>> >>>> Also, I am going to be requesting the creation of the insipid mailing >>>> list. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> ______________________________**_________________ >>>> 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 >> > > ______________________________**_________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/**listinfo/dispatch > --20cf307f3c04f8e35b04ba9c5248 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Also, did anyone ever send an email to DISPATCH announcing the new mailing = list? =A0I can't find anything in the archives nor was anything posted = on the RAI area mailing list.=A0

Mary.

On Tue, Mar 6, 2012 at 5:22 PM, James M. Polk <jmpolk@cisco.com> wrote:
At 02:52 PM 3/6/2012, Paul Kyzivat wrote:
On 3/6/12 2:31 PM, Paul E. Jones wrote:
Gonzalo,

I would suggest adding the following text to the end of the second paragrap= h
of the charter:
"Consideration must be given to the fact that the entities involved in= a
communication session might change as a result of service interaction in th= e
network, such as call transfers, joins, etc."

This is text we introduced in a later version of the charter.

These words don't mention any constraints that should be imposed wile c= onsidering this. So the outcome might or might not specify that such change= s do or don't preserve the session id.

Is that what you are looking for?

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

May I suggest that folks interested in this subject take their discussions = over to the NEW INSIPID list at insipid@ietf.org after they register into that list.

This will clear up DISPATCH from hearing about this, while focusing Session= -ID talk to the IPSIPID list, which is more appropriate IMO.

James



Paul

-----Original Message-----
From: dispat= ch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Gonzalo Camarillo
Sent: Thursday, March 01, 2012 6:23 AM
To: DISPATCH
Subject: [dispatch] Charter process for the INSIPID WG

Folks,

Robert and I have been working on a charter proposal for the INSIPID WG. This is the proposal that we have sent for review to the IESG and IAB:

http://www.ietf.org/iesg/evaluation/sessionid-charter.<= u>txt

We believe this proposal represents the consensus of the group. Note that we have left out some comments that failed to get rough consensus on this list.

=A0From now on, I will be taking care of the chartering process for this WG= .
Today, I will discuss the charter proposal with the IESG and, if
everything goes OK, we will be sending it for external review shortly.
If you have further comments on the charter proposal, please send them as part of its external review, which will be announced on the IETF
announcement list as usual.

Also, I am going to be requesting the creation of the insipid mailing
list.

Cheers,

Gonzalo

_______________________________________________
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

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

--20cf307f3c04f8e35b04ba9c5248-- From keith.drage@alcatel-lucent.com Tue Mar 13 15:59:11 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E82621E803F; Tue, 13 Mar 2012 15:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.534 X-Spam-Level: X-Spam-Status: No, score=-109.534 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 fvAkQsTyqnAq; Tue, 13 Mar 2012 15:59:10 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7302021E8033; Tue, 13 Mar 2012 15:59:07 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2DMx5g3022561 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 Mar 2012 23:59:05 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 13 Mar 2012 23:59:05 +0100 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Tue, 13 Mar 2012 23:56:54 +0100 Thread-Topic: Compiling an agenda for INSIPID Thread-Index: Ac0BbJYB8xCK4eXZQXiA+pdlquFoYQ== 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 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "dispatch@ietf.org" Subject: [Insipid] Compiling an agenda for INSIPID X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 22:59:11 -0000 I am in the process of compiling an agenda for the INSIPID meeting. The gro= up has yet to complete the chartering process, but there is some expectatio= n it will do that on Thursday. Assuming the group is chartered, we will not= be discussing the charter, only using the charter to scope the future work= . Obviously I am well aware of some of the drafts but just in case I miss som= e.... If you believe you have drafts, current or expired, that fall within the sc= ope of the INSIPID group, then please send me a private mail, identifying s= aid draft. If you believe it has been superseded or overtaken by another draft then pl= ease identify that. If you believe the draft is still current (i.e. it has valid input for the = group that we will not find elsewhere), then please identify a potential pr= esenter for the Paris meeting. Please note that we will only have an hour, so it may well be a matter of o= ne or two slides identifying key issues or use cases, and there is no guara= ntee of a slot. Finally if you do have views on the direction forward the group should take= , assuming that it is chartered, then do feel free to open that discussion = on the INSIPID list. Some lively discussion on list will help make progress= in Paris. Regards Keith From keith.drage@alcatel-lucent.com Wed Mar 14 16:42:52 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0230411E8075 for ; Wed, 14 Mar 2012 16:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.566 X-Spam-Level: X-Spam-Status: No, score=-107.566 tagged_above=-999 required=5 tests=[AWL=-1.317, 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 rxxKpP1Y0Ksv for ; Wed, 14 Mar 2012 16:42:51 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 332BF21F8778 for ; Wed, 14 Mar 2012 16:42:50 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2ENgmxx015685 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 15 Mar 2012 00:42:48 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 15 Mar 2012 00:42:48 +0100 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Thu, 15 Mar 2012 00:42:45 +0100 Thread-Topic: Draft agenda for INSIPID session Thread-Index: Ac0CPCfRe9Gaz+lhT/+G86WacYtcrw== 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 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [Insipid] Draft agenda for INSIPID session X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 23:42:52 -0000 The decision on the chartering of INSIPID is meant to be taken on Thursday. I've drafted the following agenda to at least give something to start bashi= ng, and to present at least some form of reading list. Let bashing commence. INSIPID WG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Monday: 15:10 - 16:10 Afternoon Session II Room 241 Temporary Chairs: Keith Drage, ??? Note this is very much a preliminary agenda and should be regarded more as = a provisional reading list rather than a polished agenda. 10 Agenda Bash and Status Report ------------------------------------- Chairs 20 Requirements -------------------- Requirements for an End-to-End Session Identification in IP-Based Multimedi= a Communication Networks draft-jones-ipmc-session-id-reqts-01 Paul Jones / James Polk / Parthasarathi Ravindran / Laura Liess / Roland Je= sske / Salvatore Loreto / Hadriel Kaplan https://datatracker.ietf.org/doc/draft-jones-ipmc-session-id-reqts=20 15 Additional requirements and use cases --------------------------------------------- Session Initiation Protocol (SIP) Header Parameter for Debugging draft-dawes-dispatch-debug-00 Peter Dawes https://datatracker.ietf.org/doc/draft-dawes-dispatch-debug=20 Session Initiation Protocol (SIP) Extension for logging and debugging draft-kaithal-dispatch-sip-log-information-00 Adarsh Kaithal / Sandeep K S https://datatracker.ietf.org/doc/draft-kaithal-dispatch-sip-log-information= =20 [Listed because it is identified by draft-dawes-dispatch-debug] A Session Identifier for the Session Initiation Protocol (SIP) (ANNEX A ONL= Y) draft-kaplan-dispatch-session-id-03 Hadriel Kaplan http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-03=20 12 Solutions documents --------------------------- End-to-End Session Identification in IP-Based Multimedia Communication Netw= orks draft-jones-ipmc-session-id-03.txt Paul Jones / Chris Pearce / James Polk / Gonzalo Salgueiro https://datatracker.ietf.org/doc/draft-jones-ipmc-session-id=20 A Session Identifier for the Session Initiation Protocol (SIP) draft-kaplan-dispatch-session-id-03 Hadriel Kaplan http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-03=20 3 Next steps ------------------ Chairs From Peter.Dawes@vodafone.com Fri Mar 16 04:32:57 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567E221F85EC for ; Fri, 16 Mar 2012 04:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 LZD-vbcN4-4j for ; Fri, 16 Mar 2012 04:32:56 -0700 (PDT) Received: from mailout05.vodafone.com (mailout05.vodafone.com [195.232.224.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6A01721F85DA for ; Fri, 16 Mar 2012 04:32:56 -0700 (PDT) Received: from mailint05 (localhost [127.0.0.1]) by mailout05 (Postfix) with ESMTP id 2D607146BBE for ; Fri, 16 Mar 2012 12:32:54 +0100 (CET) Received: from avoexs02.internal.vodafone.com (unknown [145.230.4.135]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint05 (Postfix) with ESMTPS id 1E787146BAC; Fri, 16 Mar 2012 12:32:54 +0100 (CET) Received: from avoexf10.internal.vodafone.com ([145.230.6.94]) by avoexs02.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 12:31:29 +0100 Received: from AVOEXC03W.internal.vodafone.com (145.230.15.132) by avoexf10.internal.vodafone.com (145.230.6.94) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 16 Mar 2012 12:31:55 +0100 Received: from VOEXM25W.internal.vodafone.com ([169.254.1.44]) by AVOEXC03W.internal.vodafone.com ([145.230.15.132]) with mapi id 14.01.0355.002; Fri, 16 Mar 2012 12:31:28 +0100 From: "Dawes, Peter, VF-Group" To: "DRAGE, Keith (Keith)" , "insipid@ietf.org" Thread-Topic: Draft agenda for INSIPID session Thread-Index: Ac0CPCfRe9Gaz+lhT/+G86WacYtcrwBJuOUg Date: Fri, 16 Mar 2012 11:31:28 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D990127EB@VOEXM25W.internal.vodafone.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [145.230.12.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Mar 2012 11:31:29.0479 (UTC) FILETIME=[549ED570:01CD0368] Subject: Re: [Insipid] Draft agenda for INSIPID session X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 11:32:57 -0000 Hello Keith, I cannot speak for the author, but have you considered whether draft-worley= -references should be in the "additional requirements and use cases" agenda= item? I think the agenda (or pre-meeting e-mail discussion) should include decidi= ng whether INSIPID will define "session", and if so how it will be document= ed. Also, stating the desired outcome of the one hour we have would be hel= pful; one possibility is to come out with an INSIPID view of the steps to a= n RFC(s) with potential sticking points and related existing or on-going IE= TF work (if any) made clear. Regards, Peter -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of DRAGE, Keith (Keith) Sent: 14 March 2012 23:43 To: insipid@ietf.org Subject: [Insipid] Draft agenda for INSIPID session The decision on the chartering of INSIPID is meant to be taken on Thursday. I've drafted the following agenda to at least give something to start bashi= ng, and to present at least some form of reading list. Let bashing commence. INSIPID WG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Monday: 15:10 - 16:10 Afternoon Session II Room 241 Temporary Chairs: Keith Drage, ??? Note this is very much a preliminary agenda and should be regarded more as = a provisional reading list rather than a polished agenda. 10 Agenda Bash and Status Report ------------------------------------- Chairs 20 Requirements -------------------- Requirements for an End-to-End Session Identification in IP-Based Multimedi= a Communication Networks draft-jones-ipmc-session-id-reqts-01 Paul Jones / James Polk / Parthasarathi Ravindran / Laura Liess / Roland Je= sske / Salvatore Loreto / Hadriel Kaplan https://datatracker.ietf.org/doc/d= raft-jones-ipmc-session-id-reqts=20 15 Additional requirements and use cases --------------------------------------------- Session Initiation Protocol (SIP) Header Parameter for Debugging draft-dawes-dispatch-debug-00 Peter Dawes https://datatracker.ietf.org/doc/draft-dawes-dispatch-debug=20 Session Initiation Protocol (SIP) Extension for logging and debugging draft-kaithal-dispatch-sip-log-information-00 Adarsh Kaithal / Sandeep K S https://datatracker.ietf.org/doc/draft-kaithal-dispatch-sip-log-information [Listed because it is identified by draft-dawes-dispatch-debug] A Session Identifier for the Session Initiation Protocol (SIP) (ANNEX A ONL= Y) draft-kaplan-dispatch-session-id-03 Hadriel Kaplan http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-03=20 12 Solutions documents --------------------------- End-to-End Session Identification in IP-Based Multimedia Communication Netw= orks draft-jones-ipmc-session-id-03.txt Paul Jones / Chris Pearce / James Polk / Gonzalo Salgueiro https://datatrac= ker.ietf.org/doc/draft-jones-ipmc-session-id=20 A Session Identifier for the Session Initiation Protocol (SIP) draft-kaplan-dispatch-session-id-03 Hadriel Kaplan http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-03=20 3 Next steps ------------------ Chairs _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From gonzalo.camarillo@ericsson.com Sat Mar 17 03:19:50 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E39B21F862A for ; Sat, 17 Mar 2012 03:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.338 X-Spam-Level: X-Spam-Status: No, score=-110.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 isnVbCCVRwDu for ; Sat, 17 Mar 2012 03:19:50 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 97DA021F8620 for ; Sat, 17 Mar 2012 03:19:31 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-8c-4f64653293ab Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 07.F1.17856.235646F4; Sat, 17 Mar 2012 11:19:30 +0100 (CET) Received: from [131.160.126.134] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Sat, 17 Mar 2012 11:19:30 +0100 Message-ID: <4F646531.4010300@ericsson.com> Date: Sat, 17 Mar 2012 12:19:29 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: insipid@ietf.org References: <4F646490.9030800@ericsson.com> In-Reply-To: <4F646490.9030800@ericsson.com> X-Enigmail-Version: 1.3.4 X-Forwarded-Message-Id: <4F646490.9030800@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [Insipid] Fwd: INSIPID session X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 10:19:50 -0000 FYI. -------- Original Message -------- Subject: INSIPID session Date: Sat, 17 Mar 2012 12:16:48 +0200 From: Gonzalo Camarillo To: Keith Drage , Hadriel Kaplan Keith, Hadriel, thanks for agreeing to chair the INSIPID session in Paris. The IESG approved the charter on Thursday. The Secretary will be sending out the announcement soon. Please, coordinate the preparation of the session between you two. Thanks, Gonzalo From iesg-secretary@ietf.org Mon Mar 19 09:01:13 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25ACF21F8887; Mon, 19 Mar 2012 09:01:13 -0700 (PDT) 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, 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 QgY5nR2JAZRL; Mon, 19 Mar 2012 09:01:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C90621F8881; Mon, 19 Mar 2012 09:01:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120319160112.16453.75719.idtracker@ietfa.amsl.com> Date: Mon, 19 Mar 2012 09:01:12 -0700 Cc: insipid@ietf.org, drage@alcatel-lucent.com, hkaplan@acmepacket.com Subject: [Insipid] WG Action: INtermediary-safe SIP session ID (insipid) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 16:01:13 -0000 A new IETF working group has been formed in the Real-Time Applications = and Infrastructure Area. For additional information, please contact the = Area Directors or the WG Chairs. INtermediary-safe SIP session ID (insipid) ------------------------------------------ Status: Active Working Group Chairs: Keith Drage Hadriel Kaplan Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: insipid@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/insipid Archive: http://www.ietf.org/mail-archive/web/insipid/ An 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 are not suitable for end-to-end session identification. Perhaps the most important factor worth describing is that in real-world deployments of 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. 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 come from other working groups within the RAI area (e.g., SIPRec). Moreover, other standards organizations have identified the need for SIP and H.323 to carry the same "session ID" value so that it is possible to identify a call end-to end even when performing inter working between protocols. This group will focus on a document that will specify a SIP identifier that have the same aim as the From-tag, To-tag and Call-ID conjunction, but is less likely to be mangled by intermediaries. In doing this work, the group will pay attention to the privacy implications of a "session ID", for example considering the possibility to make it intractable for nodes to correlate "session IDs" generated by the same user for different sessions. Goal and Milestone: Dec 2012 - Specification of the new identifier sent to the IESG (PS) From keith.drage@alcatel-lucent.com Mon Mar 19 10:18:30 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AF521F88B2 for ; Mon, 19 Mar 2012 10:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.581 X-Spam-Level: X-Spam-Status: No, score=-109.581 tagged_above=-999 required=5 tests=[AWL=0.668, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 QxQFVHn5K57g for ; Mon, 19 Mar 2012 10:18:30 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id C9AA421F888D for ; Mon, 19 Mar 2012 10:18:29 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2JHIQwx005994 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 19 Mar 2012 18:18:26 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 19 Mar 2012 18:18:26 +0100 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Mon, 19 Mar 2012 18:18:25 +0100 Thread-Topic: INSIPID has been chartered Thread-Index: Ac0F9EtdD4n2q+NpR0+B/SgX+7gYaw== 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 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [Insipid] INSIPID has been chartered X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 17:18:30 -0000 The INSIPID working group has been chartered and will be meeting in Paris. = Hadriel Kaplan and myself will be chairing that session at least for Paris. http://datatracker.ietf.org/wg/insipid/charter/=20 The agenda has been posted at the meeting materials site, which automatical= ly finds its way through to a link on the IETF agenda. We only have an hour in Paris. The tentative plans for what we want to achieve in Paris are as follows: http://www.ietf.org/proceedings/83/agenda/agenda-83-insipid.txt=20 1) Not make any adoption calls for WG drafts. It is possible that other can= didates could be submitted in the future as the charter only got agreed aft= er the document deadline, and there are no current author drafts that have = been formally targeted at the INSIPID group (by including INSIPID in the na= me). 2) To discuss through the available requirements and give a chance for auth= ors to reflect views of working group members in their drafts. The most sub= stantive document is the jones draft, but there are some other documents li= sted in the agenda that may lead to discussion. Some of this will probably = lead to discussion of what is in and out of scope of the group - so please = do make yourself familiar with the charter if you have not already done so. 3) What do we need for use cases? Anything at all? 4) Quick overview of the current solutions on the table.=20 >From the meeting we would then invite the various authors to take the discu= ssions into account and revise their documents, combine with other document= s, or anything else appropriate. The opportunity also exists to submit new = drafts (particularly if you feel something has been missed from the other d= rafts). At that point we will start making adoption decisions for WG drafts= . I do encourage all and everyone to look at the current documents, particula= rly the various requirements documents, and make any comments to the list. = The sooner we get discussion going the easier we can get the work moving. Regards Keith From jmpolk@cisco.com Tue Mar 20 17:05:49 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEC721E8037; Tue, 20 Mar 2012 17:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.903 X-Spam-Level: X-Spam-Status: No, score=-109.903 tagged_above=-999 required=5 tests=[AWL=0.696, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 QP9uY-OdhTaL; Tue, 20 Mar 2012 17:05:49 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4A521E801A; Tue, 20 Mar 2012 17:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=3749; q=dns/txt; s=iport; t=1332288349; x=1333497949; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=fUPcKxx3WcMnRVIWMQjm3utUrtHImSGUwFYaQC8jAfo=; b=ioiB7d62vS5ZfQRGNwdJ86yTWc9CYUtAD3q4ocFCyTMku7oH/fgS91UZ 0DDk+twE3yIHYCqDVmLenrUH/fXAJIcxE/E+QfJXlamrMaMLxnRSR5zwq rmKNWFKKMtgBJ+tCHX8RaUu7D8GJ4Hxm7hE7fnVqc3WNqgvagA2yB0VzQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKEaaU+rRDoJ/2dsb2JhbAA6CrZqgQeCCQEBAQQBAQEPASUCNAsQBwQYDBIQGQ4wBhMJEgeHZwyXXp8pilgJhiAEiFabSIFogwWBPg X-IronPort-AV: E=Sophos;i="4.73,621,1325462400"; d="scan'208";a="34399752" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 21 Mar 2012 00:05:49 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2L05m0v013641; Wed, 21 Mar 2012 00:05:48 GMT Message-Id: <201203210005.q2L05m0v013641@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Mar 2012 19:05:47 -0500 To: IESG Secretary From: "James M. Polk" In-Reply-To: <20120319160112.16453.75719.idtracker@ietfa.amsl.com> References: <20120319160112.16453.75719.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: insipid@ietf.org Subject: Re: [Insipid] WG Action: INtermediary-safe SIP session ID (insipid) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 00:05:50 -0000 Secretariat Gonzalo Camarillo (RAI AD) asked me to ask you to make the insipid@ietf.org list associated with this new INSIPID WG. I am the current list admin, which is why he may be asking this of me. Let me know if I need to do something more or differently. I haven't done this exact task before. James At 11:01 AM 3/19/2012, you wrote: >A new IETF working group has been formed in the Real-Time Applications >and Infrastructure Area. For additional information, please contact the >Area Directors or the WG Chairs. > > >INtermediary-safe SIP session ID (insipid) >------------------------------------------ >Status: Active Working Group > >Chairs: > Keith Drage > Hadriel Kaplan > >Real-Time Applications and Infrastructure Area Directors: > Gonzalo Camarillo > Robert Sparks > >Real-Time Applications and Infrastructure Area Advisor: > Gonzalo Camarillo > >Mailing Lists: > General Discussion: insipid@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/insipid > Archive: http://www.ietf.org/mail-archive/web/insipid/ > >An 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 are not suitable >for end-to-end session identification. Perhaps the most important >factor worth describing is that in real-world deployments of >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. > >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 come from other working groups >within the RAI area (e.g., SIPRec). Moreover, other standards >organizations have identified the need for SIP and H.323 to carry the >same "session ID" value so that it is possible to identify a call >end-to end even when performing inter working between protocols. > >This group will focus on a document that will specify a SIP >identifier that have the same aim as the From-tag, To-tag and Call-ID >conjunction, but is less likely to be mangled by intermediaries. In >doing this work, the group will pay attention to the privacy >implications of a "session ID", for example considering the >possibility to make it intractable for nodes to correlate "session IDs" >generated by the same user for different sessions. > >Goal and Milestone: > >Dec 2012 - Specification of the new identifier sent to the IESG (PS) >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Sun Mar 25 18:28:25 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D894021E805A for ; Sun, 25 Mar 2012 18:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.591 X-Spam-Level: X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_20=-0.74] 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 RgIQZVfuTMtX for ; Sun, 25 Mar 2012 18:28:25 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 248F721E8056 for ; Sun, 25 Mar 2012 18:28:25 -0700 (PDT) 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 q2Q1SN32002292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 25 Mar 2012 21:28:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332725304; bh=HL5AGYwCCMT/nQk4Bo6qSPjN2qRq9VYau65K4cqQP6c=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=rIXy0TXcB84qgO0qrKLqanGqC3c9rS8pNDWxK6jxVveVSzKwUHJS+NEMAu8/Vh+FC l6ZjhJhdbhKZzNzp4WVHMla1jYRpsFvMr/Xfu2XxV0RUJxMi8uklifkKjp12tyqZdj hzXikWAq0vMWkg+HWzA85CPm3KVWiDoHPcDVrojI= From: "Paul E. Jones" To: Date: Sun, 25 Mar 2012 21:28:25 -0400 Message-ID: <04b701cd0aef$bdfa2040$39ee60c0$@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: Ac0K7709G6Ehg4tbQRC3cKNC/P3DSw== Content-Language: en-us Subject: [Insipid] Refreshed Internet Drafts posted X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 01:28:26 -0000 INSIPID WG, Please note that I have uploaded refreshed versions of the requirements document for the end-to-end session identifier and a refreshed version of the proposal we submitted previously to address the requirements. Those two documents can be found here: http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-00 http://tools.ietf.org/html/draft-jones-insipid-session-id-00 Paul From keith.drage@alcatel-lucent.com Mon Mar 26 02:49:16 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922F321F8504 for ; Mon, 26 Mar 2012 02:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.594 X-Spam-Level: X-Spam-Status: No, score=-109.594 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 J6it+SwJHZCS for ; Mon, 26 Mar 2012 02:49:15 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF8521F84DD for ; Mon, 26 Mar 2012 02:49:11 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2Q9eiKs025395 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 26 Mar 2012 11:49:07 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 26 Mar 2012 11:49:01 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Mon, 26 Mar 2012 11:48:59 +0200 Thread-Topic: Slides for IETF#83 session Thread-Index: Ac0LNastuoCYyJohS1CVITDfimWR+w== 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 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: [Insipid] Slides for IETF#83 session X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 09:49:16 -0000 (As WG co-chair) I believe all the slides are now uploaded for the INSIPID session later tod= ay. Hadriel will not be presenting slides on his solution (although he will sti= ll present the use cases). Regards Keith From adam@nostrum.com Mon Mar 26 07:13:22 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E34C21F8790 for ; Mon, 26 Mar 2012 07:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.863 X-Spam-Level: X-Spam-Status: No, score=-101.863 tagged_above=-999 required=5 tests=[AWL=0.737, 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 czpkGSzh-rNW for ; Mon, 26 Mar 2012 07:13:21 -0700 (PDT) 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 5629F21F8512 for ; Mon, 26 Mar 2012 07:13:21 -0700 (PDT) Received: from dhcp-1418.meeting.ietf.org (dhcp-1418.meeting.ietf.org [130.129.20.24]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q2QEDJUR071083 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 26 Mar 2012 09:13:20 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4F70797D.9070104@nostrum.com> Date: Mon, 26 Mar 2012 16:13:17 +0200 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: insipid@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.20.24 is authenticated by a trusted mechanism) Subject: [Insipid] Use case to consider X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 14:13:22 -0000 Here is the use case I tried to describe at the microphone. Do note that real PBXes -- some very popular, well-deployed real PBXes -- use signaling that looks like this. I don't believe the current solution provides enough information for implementors to know what to do here, and I don't think the requirements have enough language around the description of the term "session" to point to a clear way for the solution to fix that. First, I'm going to show a simple call between Alice and Bob, through a PBX that acts as a back-to-back user agent. Alice Bob PBX |(1) INVITE (UUID=A)| | |-------------------------------------->| |(2) media | | |.......................................|REQ4: UUID stays | | |the same | |(3) INVITE (UUID=A)| | |<------------------| | |(4) media | | |...................| | |(5) 200 (UUID=B) | | |------------------>| |(6) 200 (UUID=B) | | |<--------------------------------------|Session ID is | | |AB everywhere I think this is uncontroversial, based on the current charter. It's two different SIP dialogs (one from Alice to the PBX; one from the PBX to Bob), but one Session (the way the INSIPID charter seems to define it, and certainly what REQ4 implies). Now, let's consider what happens when Carol activates a call barge function. I know that call barge can be implemented with several different call flows, but here's a plausible (and actually deployed) signaling flow: Alice Bob PBX Carol |(1) INVITE (UUID=A)| | | |-------------------------------------->| | |(2) media | | | |.......................................|REQ4: UUID stays | | | |the same | | |(3) INVITE (UUID=A)| | | |<------------------| | | |(4) media | | | |...................| | | |(5) 200 (UUID=B) | | | |------------------>|REQ4: UUID stays | | | |the same | |(6) 200 (UUID=B) | | | |<--------------------------------------|Session ID is |Carol | | |AB everywhere |starts | | | |call | | | |barge | | |(7) INVITE Join | | | |(UUID=C) | | | |<------------------| |no signalling here | | | | |no signalling here | | | | |(8) media | | | |...................| | | |(9) 200 (UUID=???) | | | |------------------>| | | |REQ3...??? | You'll see that the whole thing starts falling apart around step 9. In this call scenario, there seems to be no behavior that is consistent with both REQ4 and REQ3. Certainly the call between Alice and Bob is the same session after Carol barges in as it was before. Also, keep in mind (when thinking about the solution to this) that Carol may actually be entering into a call monitoring situation, in which Alice and Bob are supposed to be unaware of Carol's presence on the call. A solution that requires the PBX to send signaling to Alice and Bob would violate the expected confidentiality. /a From oej@edvina.net Mon Mar 26 07:46:01 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E54B21E80BD for ; Mon, 26 Mar 2012 07:46:01 -0700 (PDT) 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=[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 q4OtNJPcwCTy for ; Mon, 26 Mar 2012 07:46:00 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id B663C21E80BC for ; Mon, 26 Mar 2012 07:46:00 -0700 (PDT) Received: from dhcp-1076.meeting.ietf.org (dhcp-1076.meeting.ietf.org [130.129.16.118]) by smtp7.webway.se (Postfix) with ESMTPA id 63FDC754A8AA; Mon, 26 Mar 2012 14:45:58 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Mar 2012 16:45:57 +0200 To: insipid@ietf.org Message-Id: <06343E8A-D16C-41EF-ACA9-89090A7DD6A1@edvina.net> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [Insipid] Session-ID : user or server controlled X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 14:46:01 -0000 In the meeting today, I realized that we're talking about two very = different use cases: - A user controlled session ID like in the draft - A server controlled session ID For call center applications, I need a server controlled session ID I = want to slap on a call coming in from the ISDN and keep as it traverses = several b2buas. At that point I don't even know which "user" that will = be an endpoint in the call and I don't really care. Just to confuse a little bit more, if needed. /O= From kpfleming@digium.com Mon Mar 26 09:17:28 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2445B21E80FB for ; Mon, 26 Mar 2012 09:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 YXdFFgjvzS8Y for ; Mon, 26 Mar 2012 09:17:27 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 422C821E80F1 for ; Mon, 26 Mar 2012 09:17:26 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SCCbl-0007eI-Sj for insipid@ietf.org; Mon, 26 Mar 2012 11:17:25 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id CFC8ED8011 for ; Mon, 26 Mar 2012 11:17:25 -0500 (CDT) 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 DSpjJELpwcWI for ; Mon, 26 Mar 2012 11:17:25 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 6B316D8002 for ; Mon, 26 Mar 2012 11:17:25 -0500 (CDT) Message-ID: <4F709695.3010808@digium.com> Date: Mon, 26 Mar 2012 11:17:25 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: insipid@ietf.org References: <4F70797D.9070104@nostrum.com> In-Reply-To: <4F70797D.9070104@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] Use case to consider X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:17:28 -0000 On 03/26/2012 09:13 AM, Adam Roach wrote: > Here is the use case I tried to describe at the microphone. Do note that > real PBXes -- some very popular, well-deployed real PBXes -- use > signaling that looks like this. I don't believe the current solution > provides enough information for implementors to know what to do here, > and I don't think the requirements have enough language around the > description of the term "session" to point to a clear way for the > solution to fix that. > > First, I'm going to show a simple call between Alice and Bob, through a > PBX that acts as a back-to-back user agent. > > > Alice Bob PBX > |(1) INVITE (UUID=A)| | > |-------------------------------------->| > |(2) media | | > |.......................................|REQ4: UUID stays > | | |the same > | |(3) INVITE (UUID=A)| > | |<------------------| > | |(4) media | > | |...................| > | |(5) 200 (UUID=B) | > | |------------------>| > |(6) 200 (UUID=B) | | > |<--------------------------------------|Session ID is > | | |AB everywhere > > > I think this is uncontroversial, based on the current charter. It's two > different SIP dialogs (one from Alice to the PBX; one from the PBX to > Bob), but one Session (the way the INSIPID charter seems to define it, > and certainly what REQ4 implies). > > Now, let's consider what happens when Carol activates a call barge > function. I know that call barge can be implemented with several > different call flows, but here's a plausible (and actually deployed) > signaling flow: > > Alice Bob PBX Carol > |(1) INVITE (UUID=A)| | | > |-------------------------------------->| | > |(2) media | | | > |.......................................|REQ4: UUID stays | > | | |the same | > | |(3) INVITE (UUID=A)| | > | |<------------------| | > | |(4) media | | > | |...................| | > | |(5) 200 (UUID=B) | | > | |------------------>|REQ4: UUID stays | > | | |the same | > |(6) 200 (UUID=B) | | | > |<--------------------------------------|Session ID is |Carol > | | |AB everywhere |starts > | | | |call > | | | |barge > | | |(7) INVITE Join | > | | |(UUID=C) | > | | |<------------------| > |no signalling here | | | > | |no signalling here | | > | | |(8) media | > | | |...................| > | | |(9) 200 (UUID=???) | > | | |------------------>| > | | |REQ3...??? | > > > You'll see that the whole thing starts falling apart around step 9. In > this call scenario, there seems to be no behavior that is consistent > with both REQ4 and REQ3. Certainly the call between Alice and Bob is the > same session after Carol barges in as it was before. > > Also, keep in mind (when thinking about the solution to this) that Carol > may actually be entering into a call monitoring situation, in which > Alice and Bob are supposed to be unaware of Carol's presence on the > call. A solution that requires the PBX to send signaling to Alice and > Bob would violate the expected confidentiality. Thanks for posting this; this is pretty much what I was envisioning when you were describing it during the meeting. Indeed, this sort of thing is quite common. -- 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 Mon Mar 26 09:45:16 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3090421F8607 for ; Mon, 26 Mar 2012 09:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, J_CHICKENPOX_41=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 s7oQ8gEJXV98 for ; Mon, 26 Mar 2012 09:45:15 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 63A6421F8609 for ; Mon, 26 Mar 2012 09:45:15 -0700 (PDT) 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 q2QGjDO0020809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 26 Mar 2012 12:45:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332780314; bh=fkNa/4aHat1sxqGUJlmykKQIhqNejJzmNoS+h8swX5s=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=IwBWASJT/JAFi8WWMvoQOE0SU+IQAygn0NIdo4/Wzf1xc9Ji9yXJtvPwX/3W6uv0g hq1DwDpJh+qmUv+qTdPr5Co736gOb3cMOcmHaRIIF8VHVZpg/h+acqQJC5ClA9mPAr rVBpMO6t81CNe2pg2VIKp80qWKtz1ZnYj93Qpgww= From: "Paul E. Jones" To: "'Adam Roach'" , References: <4F70797D.9070104@nostrum.com> In-Reply-To: <4F70797D.9070104@nostrum.com> Date: Mon, 26 Mar 2012 12:45:16 -0400 Message-ID: <053d01cd0b6f$d36e29a0$7a4a7ce0$@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: AQG9PF4X9wHVos1Td4S5OTcTaYF+O5acQ/MA Content-Language: en-us Subject: Re: [Insipid] Use case to consider X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:45:16 -0000 Adam, > Now, let's consider what happens when Carol activates a call barge > function. I know that call barge can be implemented with several > different call flows, but here's a plausible (and actually deployed) > signaling flow: > > Alice Bob PBX Carol > |(1) INVITE (UUID=A)| | | > |-------------------------------------->| | > |(2) media | | | > |.......................................|REQ4: UUID stays | > | | |the same | > | |(3) INVITE (UUID=A)| | > | |<------------------| | > | |(4) media | | > | |...................| | > | |(5) 200 (UUID=B) | | > | |------------------>|REQ4: UUID stays | > | | |the same | > |(6) 200 (UUID=B) | | | > |<--------------------------------------|Session ID is > |Carol > | | |AB everywhere > |starts > | | | > |call > | | | > |barge > | | |(7) INVITE Join | > | | |(UUID=C) | > | | |<------------------| > |no signalling here | | | > | |no signalling here | | > | | |(8) media | > | | |...................| > | | |(9) 200 (UUID=???) | > | | |------------------>| > | | |REQ3...??? | > > > You'll see that the whole thing starts falling apart around step 9. In > this call scenario, there seems to be no behavior that is consistent > with both REQ4 and REQ3. Certainly the call between Alice and Bob is the > same session after Carol barges in as it was before. > > Also, keep in mind (when thinking about the solution to this) that Carol > may actually be entering into a call monitoring situation, in which > Alice and Bob are supposed to be unaware of Carol's presence on the > call. A solution that requires the PBX to send signaling to Alice and > Bob would violate the expected confidentiality. One could view Carol as an active participant in the conference, even if silent, but certainly she would be an active participant if she is able to whisper to either Alice or Bob. In this case, the PBX could be viewed as an MCU. In fact, it is performing a media mixing function, so the definition fits. Alternatively, Carol could be viewed as a silent participant and not really part of the Bob/Carol conversation and more than a Wireshark capture is. So, we have three options to consider: 1) Carol is a full member of the conference, 2) Carol is whispering only to one (say, Bob) and 3) Carol is silently monitoring. For (1), the PBX would create a new UUID "E" and send it down to Alice, Bob, and Carol such that Alice sees a session ID of A || E, Bob sees a session ID of B || E, and Carol would use C || E. For anyone interested, it would be possible to see that all of these sessions are somehow related, but each has its own unique Session-ID. Also, the "end" stops at the PBX, as it is now the conference focus. For (2), we have the option of the PBX performing the media mixing and call control (2A) or Bob providing the media mixing and handling call control (2B). In both cases, we do not consider Carol to be a member of the conference as described in (1) above. For 2A, this means that we have two different conferences: one between Alice and Bob and one between Bob and Carol. The PBX is handing media and call control and does not establish a different session between Carol and Bob: call control for the session stops at the PBX. The session is remains end-to-end between Alice and Bob. The PBX accepts the INVITE from Carol with UUID=C and returns its own UUID=D, so the session between Bob and Carol is C||D. The PBX alters media it sends to Bob as it sees fit. Media from Bob to Alice remains unchanged. For 2B, Bob has the capability of managing the two sessions itself and mixing media as required locally. In that case, Carol sends the INVITE to the PBX (indicating a barge). That is forwarded to Bob. Bob formulates a second UUID=E and returns that top Carol. The session between Alice and Bob remains unchanged (A || B). There is a new session between Carol and Bob (C || E). In short, the way in which Session IDs are constructed and where the end of the media flow exists depends on how you wish to implement this feature in the PBX. I'd personally either chose to create a separate call as in (2B) or merge everything into a conference as in (1). Paul From paulej@packetizer.com Mon Mar 26 09:47:06 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366F221F8609 for ; Mon, 26 Mar 2012 09:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 XQ40mzJBoBw7 for ; Mon, 26 Mar 2012 09:47:05 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 82B9721F8607 for ; Mon, 26 Mar 2012 09:47:05 -0700 (PDT) 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 q2QGl19p020863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 26 Mar 2012 12:47:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332780422; bh=ycgTsHG7gE50kFCbmL9jSni6KsblaXXS71Yd+prQpo0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=lvUW5qgNqeZ4EudqOklLgep4iZDZ/rlUsqpyZOYFRQADJA74oRGDuHnJ8AwNvQU61 eqAbvL8nCLMb4YRJSPMlllXUrreMA5wnU0d3GNSWyd3/NiZK2hJ1BA8o/U061QhEp1 rnQE9CGh5848HHztTT2Ebzi8MRapXAw3DwpR7IAY= From: "Paul E. Jones" To: "'Olle E. Johansson'" , References: <06343E8A-D16C-41EF-ACA9-89090A7DD6A1@edvina.net> In-Reply-To: <06343E8A-D16C-41EF-ACA9-89090A7DD6A1@edvina.net> Date: Mon, 26 Mar 2012 12:47:04 -0400 Message-ID: <053f01cd0b70$136c26b0$3a447410$@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: AQHl9oeKoqc7qsKpduOGWiEHsS5KxZZK8tkw Content-Language: en-us Subject: Re: [Insipid] Session-ID : user or server controlled X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:47:06 -0000 Coming in from the ISDN, that GW is the originating user agent as far as SIP is concerned. So, I think that's a reasonable place for the Session-ID UUID to be created for one end. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Olle E. Johansson > Sent: Monday, March 26, 2012 10:46 AM > To: insipid@ietf.org > Subject: [Insipid] Session-ID : user or server controlled > > In the meeting today, I realized that we're talking about two very > different use cases: > > - A user controlled session ID like in the draft > - A server controlled session ID > > For call center applications, I need a server controlled session ID I want > to slap on a call coming in from the ISDN and keep as it traverses several > b2buas. At that point I don't even know which "user" that will be an > endpoint in the call and I don't really care. > > Just to confuse a little bit more, if needed. > > /O > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From oej@edvina.net Mon Mar 26 09:49:23 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2865E21F8572 for ; Mon, 26 Mar 2012 09:49:23 -0700 (PDT) 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=[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 1GiZquZjcdVI for ; Mon, 26 Mar 2012 09:49:22 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA5A21E80BC for ; Mon, 26 Mar 2012 09:49:21 -0700 (PDT) Received: from dhcp-1076.meeting.ietf.org (dhcp-1076.meeting.ietf.org [130.129.16.118]) by smtp7.webway.se (Postfix) with ESMTPA id 79757754A8AA; Mon, 26 Mar 2012 16:49:17 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <053f01cd0b70$136c26b0$3a447410$@packetizer.com> Date: Mon, 26 Mar 2012 18:49:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <245F6091-7D29-400C-8C10-BD1ABB27BE02@edvina.net> References: <06343E8A-D16C-41EF-ACA9-89090A7DD6A1@edvina.net> <053f01cd0b70$136c26b0$3a447410$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1257) Cc: insipid@ietf.org Subject: Re: [Insipid] Session-ID : user or server controlled X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:49:23 -0000 26 mar 2012 kl. 18:47 skrev Paul E. Jones: > Coming in from the ISDN, that GW is the originating user agent as far = as SIP > is concerned. So, I think that's a reasonable place for the = Session-ID UUID > to be created for one end. But that is totally outside of my control. I will have to wait to a = majority of the larger SIP providers in Europe support this then... Not a solution, sorry. In this application, I just need to manage it = from the man-in-the-middle-box. /O >=20 > Paul >=20 >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On = Behalf >> Of Olle E. Johansson >> Sent: Monday, March 26, 2012 10:46 AM >> To: insipid@ietf.org >> Subject: [Insipid] Session-ID : user or server controlled >>=20 >> In the meeting today, I realized that we're talking about two very >> different use cases: >>=20 >> - A user controlled session ID like in the draft >> - A server controlled session ID >>=20 >> For call center applications, I need a server controlled session ID I = want >> to slap on a call coming in from the ISDN and keep as it traverses = several >> b2buas. At that point I don't even know which "user" that will be an >> endpoint in the call and I don't really care. >>=20 >> Just to confuse a little bit more, if needed. >>=20 >> /O >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From paulej@packetizer.com Mon Mar 26 11:09:17 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E3821E80CE for ; Mon, 26 Mar 2012 11:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 P9ZMRIORFw-v for ; Mon, 26 Mar 2012 11:09:17 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9662121F8738 for ; Mon, 26 Mar 2012 11:09:15 -0700 (PDT) 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 q2QI9A2a022469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 26 Mar 2012 14:09:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332785352; bh=PYXncthSxcyqYrhAY8nLk23AS/7w6/YIcOZkZkVkk/w=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=EyfLfTJXbuAmxJv0D+C4rfMq9sqI3M0zUYgkMLRnf5ohwulNlOrJ/7A5k3+FYLvp3 SeWgRki2RAtXj7ekJhvHvNP1YyCM7SLVRozmx+AGwKArvLu6tkROdCHsqa5K6A/v8W GORkxRaVJGqdrMxQGSHK6nuYmlnGs7TQhIEENdDU= From: "Paul E. Jones" To: "'Olle E. Johansson'" References: <06343E8A-D16C-41EF-ACA9-89090A7DD6A1@edvina.net> <053f01cd0b70$136c26b0$3a447410$@packetizer.com> <245F6091-7D29-400C-8C10-BD1ABB27BE02@edvina.net> In-Reply-To: <245F6091-7D29-400C-8C10-BD1ABB27BE02@edvina.net> Date: Mon, 26 Mar 2012 14:09:13 -0400 Message-ID: <056f01cd0b7b$8e42ae30$aac80a90$@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: AQHl9oeKoqc7qsKpduOGWiEHsS5KxQHnaxoAAaDTJKuWLsd4sA== Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Session-ID : user or server controlled X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 18:09:18 -0000 Olle, > > Coming in from the ISDN, that GW is the originating user agent as far > > as SIP is concerned. So, I think that's a reasonable place for the > > Session-ID UUID to be created for one end. > But that is totally outside of my control. I will have to wait to a > majority of the larger SIP providers in Europe support this then... > Not a solution, sorry. In this application, I just need to manage it from > the man-in-the-middle-box. My mail server will insert a Message-ID header if one is not present in the incoming message headers. I believe it would be reasonable to do the same for this identifier. If it's not present, a middlebox could insert it. It might mean that the ISDN GW would be oblivious to the Session-ID, but it's a starting point to getting something. At least everything beyond the middlebox would have a common understanding of the identifier. Paul From HKaplan@acmepacket.com Mon Mar 26 11:10:24 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299DC21F8738 for ; Mon, 26 Mar 2012 11:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 NNi8+qC-BEib for ; Mon, 26 Mar 2012 11:10:20 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9A77C21F8734 for ; Mon, 26 Mar 2012 11:10:19 -0700 (PDT) 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; Mon, 26 Mar 2012 14:10:17 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Mon, 26 Mar 2012 14:10:17 -0400 From: Hadriel Kaplan To: "Olle E. Johansson" Thread-Topic: [Insipid] Session-ID : user or server controlled Thread-Index: AQHNC18sE846Ae55GkWEhVZdRwK4KpZ9DHUAgAAAnQCAABaegA== Date: Mon, 26 Mar 2012 18:10:17 +0000 Message-ID: References: <06343E8A-D16C-41EF-ACA9-89090A7DD6A1@edvina.net> <053f01cd0b70$136c26b0$3a447410$@packetizer.com> <245F6091-7D29-400C-8C10-BD1ABB27BE02@edvina.net> In-Reply-To: <245F6091-7D29-400C-8C10-BD1ABB27BE02@edvina.net> 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: <153D455C08F86640B16A450448F084CA@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "Paul E. Jones" , "" Subject: Re: [Insipid] Session-ID : user or server controlled X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 18:10:24 -0000 [as an individual] I don't see it in draft-jones-insipid-session-id-00 yet, but draft-kaplan-d= ispatch-session-id-03 had the notion that a B2BUA could generate a Session-= ID if none was in the received request. This was to provide a migration pa= th for cases where the originating UAC (softphone, gateway, whatever) did n= ot yet support Session-ID and thus did not generate it itself. (and likewis= e the B2BUA inserts it in the response if the UAS did not support Session-I= D and did not reflect it in its responses) -hadriel On Mar 26, 2012, at 6:49 PM, Olle E. Johansson wrote: >=20 > 26 mar 2012 kl. 18:47 skrev Paul E. Jones: >=20 >> Coming in from the ISDN, that GW is the originating user agent as far as= SIP >> is concerned. So, I think that's a reasonable place for the Session-ID = UUID >> to be created for one end. > But that is totally outside of my control. I will have to wait to a major= ity of the larger SIP providers in Europe support this then... > Not a solution, sorry. In this application, I just need to manage it from= the man-in-the-middle-box. >=20 > /O >=20 >=20 >>=20 >> Paul >>=20 >>> -----Original Message----- >>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Beh= alf >>> Of Olle E. Johansson >>> Sent: Monday, March 26, 2012 10:46 AM >>> To: insipid@ietf.org >>> Subject: [Insipid] Session-ID : user or server controlled >>>=20 >>> In the meeting today, I realized that we're talking about two very >>> different use cases: >>>=20 >>> - A user controlled session ID like in the draft >>> - A server controlled session ID >>>=20 >>> For call center applications, I need a server controlled session ID I w= ant >>> to slap on a call coming in from the ISDN and keep as it traverses seve= ral >>> b2buas. At that point I don't even know which "user" that will be an >>> endpoint in the call and I don't really care. >>>=20 >>> Just to confuse a little bit more, if needed. >>>=20 >>> /O >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >>=20 >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >=20 > --- > * Olle E Johansson - oej@edvina.net > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden >=20 >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From Peter.Dawes@vodafone.com Mon Mar 26 12:38:34 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FBA21E8102 for ; Mon, 26 Mar 2012 12:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 OQKRH9TD1jmC for ; Mon, 26 Mar 2012 12:38:33 -0700 (PDT) Received: from mailout01.vodafone.com (mailout01.vodafone.com [195.232.224.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6F921E80F7 for ; Mon, 26 Mar 2012 12:38:33 -0700 (PDT) Received: from mailint01 (localhost [127.0.0.1]) by mailout01 (Postfix) with ESMTP id 9634F437B for ; Mon, 26 Mar 2012 21:38:31 +0200 (CEST) Received: from avoexs02.internal.vodafone.com (unknown [145.230.4.135]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint01 (Postfix) with ESMTPS id 88AE74294; Mon, 26 Mar 2012 21:38:31 +0200 (CEST) Received: from avoexf09.internal.vodafone.com ([145.230.6.95]) by avoexs02.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 21:38:03 +0200 Received: from AVOEXH04W.internal.vodafone.com (145.230.15.136) by avoexf09.internal.vodafone.com (145.230.6.95) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 26 Mar 2012 21:38:31 +0200 Received: from VOEXM25W.internal.vodafone.com ([169.254.1.200]) by AVOEXH04W.internal.vodafone.com ([145.230.15.136]) with mapi id 14.01.0355.002; Mon, 26 Mar 2012 21:38:03 +0200 From: "Dawes, Peter, Vodafone Group" To: "James M. Polk" , "insipid@ietf.org" Thread-Topic: Proposed New Requirement: Marking for Logging Thread-Index: Ac0Lhns7B/wPInZ2SSmBECCan5AchA== Date: Mon, 26 Mar 2012 19:38:02 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D9901ABD4@VOEXM25W.internal.vodafone.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [145.230.12.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Mar 2012 19:38:03.0903 (UTC) FILETIME=[F5FBE8F0:01CD0B87] Cc: "DRAGE, Keith \(Keith\)" , Hadriel Kaplan Subject: [Insipid] Proposed New Requirement: Marking for Logging X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 19:38:34 -0000 Hello James, All, Thanks for presenting your requirements draft for the session identifier. T= he requirement I propose to add is on slide 7 of my presentation in the INS= IPID meeting materials (http://www.ietf.org/proceedings/83/slides/slides-83= -insipid-1.pdf) as follows: "It must be possible to mark a session identifier as inserted for logging p= urposes" "...in order to keep network operations and maintenance steps and also SIP = entity data volume and processing load to practical levels when troubleshoo= ting" Slides 1-6 illustrate the reasons behind this proposed requirement. Regards, Peter From HKaplan@acmepacket.com Mon Mar 26 13:04:35 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFC721E80CC for ; Mon, 26 Mar 2012 13:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.054 X-Spam-Level: X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[AWL=-1.355, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, MANGLED_PILL=2.3] 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 Mbhv+2pU8DRf for ; Mon, 26 Mar 2012 13:04:34 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 735C621E809C for ; Mon, 26 Mar 2012 13:04:34 -0700 (PDT) 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; Mon, 26 Mar 2012 16:04:32 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Mon, 26 Mar 2012 16:04:33 -0400 From: Hadriel Kaplan To: "Paul E. Jones" Thread-Topic: [Insipid] Use case to consider Thread-Index: AQHNC4uoVHrSznQK0UO0G7mJcz8ewA== Date: Mon, 26 Mar 2012 20:04:32 +0000 Message-ID: References: <4F70797D.9070104@nostrum.com> <053d01cd0b6f$d36e29a0$7a4a7ce0$@packetizer.com> In-Reply-To: <053d01cd0b6f$d36e29a0$7a4a7ce0$@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: <04917A1801CA57408E89731B2E5DF032@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" , Adam Roach Subject: Re: [Insipid] Use case to consider X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 20:04:35 -0000 [as an individual] I had some comments/questions I had been planning to send on draft-jones-in= sipid-session-id-00, which fit into Adam's use-case well I think: 1) A lot of times we think about use-cases as having one PBX, or one App-Se= rver, etc. But in practice there are often many in any given call path. F= or example Alice called Bob in Adam's diagram, with both Alice and Bob talk= ing to "the" PBX. But in the real world Bob could easily be on *another* P= BX. In that case, there could be a Frank who joins the call on Bob's PBX-1= , or Bob could conference in Frank, etc., for the same call that Carol join= ed on PBX-2. In that case, what is the UUID-pair between PBX-1 and PBX-2? 2) As Adam said, it's extremely common for the operators of PBXes to want t= o hide the details of call monitoring. I'd argue it even beyond that, to s= ay they don't even want you to know that the call moves around; for example= in a call center from an IVR to an agent-queue/ACD to an agent to potentia= lly voicemail. So does the PBX always create a virtual UUID "P", which it = answers a call with by giving back to Alice "A || P", while internally insi= de the call center it handles the separate/moving dialogs using "P || B", "= P || C", etc.? If the answer is "yes", then again as above in (1), if ther= e are *two* PBXs, we lose the end-to-end nature of the correlator value, si= nce the first PBX now bridges from "A || P1" to "P1 || P2", and the second = PBX from "P1 || P2" to "P2 || B". I don't think that's a big deal for your= intended use-cases, but for troubleshooting it's not much better than what= we have now. Yet arguably it's the multi-PBX type cases that are the hard= est to troubleshoot. 3) The draft says this: "Intermediaries such as session border controllers = MUST NOT change any Session Identifier component received from an endpoint = in a session." Do you mean this to only apply to SBCs, or to any and all B= 2BUAs as well, such as PBXs? Why would an SBC vendor comply with this, if = the second-half of the identifier changes as the call moves around, since S= BCs are also used to hide such moving? (and yes, SBCs can also process REFE= Rs, re-INVITEs and INVITEs-with-Replaces locally instead of passing them on= ) 4) It's a nit, but I don't get why the draft concatenates two UUIDs into on= e "value", instead of just keeping them explicitly separate values. Like wi= th a defined separator, for example. It also violates the ABNF of "Session= -ID-UUID" to concatenate two UUIDs into the single header field value, sinc= e a UUID is defined to be a fixed length. (again this is a nit, but I thoug= ht I'd mention it so you can fix the ABNF) -hadriel On Mar 26, 2012, at 6:45 PM, Paul E. Jones wrote: > One could view Carol as an active participant in the conference, even if > silent, but certainly she would be an active participant if she is able t= o > whisper to either Alice or Bob. In this case, the PBX could be viewed as= an > MCU. In fact, it is performing a media mixing function, so the definitio= n > fits. Alternatively, Carol could be viewed as a silent participant and n= ot > really part of the Bob/Carol conversation and more than a Wireshark captu= re > is. So, we have three options to consider: 1) Carol is a full member of = the > conference, 2) Carol is whispering only to one (say, Bob) and 3) Carol is > silently monitoring. >=20 > For (1), the PBX would create a new UUID "E" and send it down to Alice, B= ob, > and Carol such that Alice sees a session ID of A || E, Bob sees a session= ID > of B || E, and Carol would use C || E. For anyone interested, it would b= e > possible to see that all of these sessions are somehow related, but each = has > its own unique Session-ID. Also, the "end" stops at the PBX, as it is no= w > the conference focus. >=20 > For (2), we have the option of the PBX performing the media mixing and ca= ll > control (2A) or Bob providing the media mixing and handling call control > (2B). In both cases, we do not consider Carol to be a member of the > conference as described in (1) above. >=20 > For 2A, this means that we have two different conferences: one between Al= ice > and Bob and one between Bob and Carol. The PBX is handing media and call > control and does not establish a different session between Carol and Bob: > call control for the session stops at the PBX. The session is remains > end-to-end between Alice and Bob. The PBX accepts the INVITE from Carol > with UUID=3DC and returns its own UUID=3DD, so the session between Bob an= d Carol > is C||D. The PBX alters media it sends to Bob as it sees fit. Media fro= m > Bob to Alice remains unchanged. >=20 > For 2B, Bob has the capability of managing the two sessions itself and > mixing media as required locally. In that case, Carol sends the INVITE t= o > the PBX (indicating a barge). That is forwarded to Bob. Bob formulates = a > second UUID=3DE and returns that top Carol. The session between Alice an= d Bob > remains unchanged (A || B). There is a new session between Carol and Bob= (C > || E). >=20 > In short, the way in which Session IDs are constructed and where the end = of > the media flow exists depends on how you wish to implement this feature i= n > the PBX. I'd personally either chose to create a separate call as in (2B= ) > or merge everything into a conference as in (1). >=20 > Paul >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From laura.liess.dt@googlemail.com Mon Mar 26 12:51:17 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4564C21E8106 for ; Mon, 26 Mar 2012 12:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.144 X-Spam-Level: X-Spam-Status: No, score=-3.144 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 33yCYrP8mJ0M for ; Mon, 26 Mar 2012 12:51:16 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4582C21E8101 for ; Mon, 26 Mar 2012 12:51:16 -0700 (PDT) Received: by werb10 with SMTP id b10so5334717wer.31 for ; Mon, 26 Mar 2012 12:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Hjq6O1aQfMii+zG6l5MU1Hl4Qe9iAT03NxduYLFzTsY=; b=KJXXC4MZzMYufjoG0tRjgbkW9q53iyMNe+7/05IgCqlyySkDxBS6Sc1USyhx5ZJ+tJ GZ1ZV3XpmJ7aQaYVO2k9C/iyLrwVj+SCBINZKZukaUGQ5HNq5unNFkFQHgmF3cKQ4kn7 h07+IMhKB6Ux+6c6fMZJtP6N6YREDnGyE0OBgD4lSZRPYbUU37EpLJzI3+M0aQfzCJuI UlMPkRgz6douUybdOHZxhW6zaNBYFdB35t2u5ommfZDs4S/w88Bo6kZxMEGhDQDy6mvu jtsIG6p2mzprglA5Xopl8v8/ZKckriXaWw5pr133OdR7TCN2hKyyenizw0T3H9vfpTte Lhew== MIME-Version: 1.0 Received: by 10.180.85.70 with SMTP id f6mr21458153wiz.5.1332791475350; Mon, 26 Mar 2012 12:51:15 -0700 (PDT) Received: by 10.227.112.206 with HTTP; Mon, 26 Mar 2012 12:51:15 -0700 (PDT) In-Reply-To: <245F6091-7D29-400C-8C10-BD1ABB27BE02@edvina.net> References: <06343E8A-D16C-41EF-ACA9-89090A7DD6A1@edvina.net> <053f01cd0b70$136c26b0$3a447410$@packetizer.com> <245F6091-7D29-400C-8C10-BD1ABB27BE02@edvina.net> Date: Mon, 26 Mar 2012 21:51:15 +0200 Message-ID: From: Laura Liess To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 26 Mar 2012 14:29:40 -0700 Cc: "Paul E. Jones" , insipid@ietf.org, Hadriel Kaplan Subject: Re: [Insipid] Session-ID : user or server controlled X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 19:51:17 -0000 We already have the REQ7 to cover situations when end devices do not support the Session-ID. (We know from experience that users often don't allow updates for their end devices.) It would be reasonable to extend this requirement for PSTN-Gateways and even for the general case when an incoming SIP-request does not contain a Session-ID (e.g. when the sending domain does not support it yet). As Hadriel already said, the mechanism proposed in the kaplan-draft satisfies this requirement by taking the incoming Call-ID and hashing it. (The hash is to satisfy REQ5.) Thanks, Laura 2012/3/26 Olle E. Johansson : > > 26 mar 2012 kl. 18:47 skrev Paul E. Jones: > >> Coming in from the ISDN, that GW is the originating user agent as far as= SIP >> is concerned. =C2=A0So, I think that's a reasonable place for the Sessio= n-ID UUID >> to be created for one end. > But that is totally outside of my control. I will have to wait to a major= ity of the larger SIP providers in Europe support this then... > Not a solution, sorry. In this application, I just need to manage it from= the man-in-the-middle-box. > > /O > > >> >> Paul >> >>> -----Original Message----- >>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Beh= alf >>> Of Olle E. Johansson >>> Sent: Monday, March 26, 2012 10:46 AM >>> To: insipid@ietf.org >>> Subject: [Insipid] Session-ID : user or server controlled >>> >>> In the meeting today, I realized that we're talking about two very >>> different use cases: >>> >>> - A user controlled session ID like in the draft >>> - A server controlled session ID >>> >>> For call center applications, I need a server controlled session ID I w= ant >>> to slap on a call coming in from the ISDN and keep as it traverses seve= ral >>> b2buas. At that point I don't even know which "user" that will be an >>> endpoint in the call and I don't really care. >>> >>> Just to confuse a little bit more, if needed. >>> >>> /O >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > > --- > * Olle E Johansson - oej@edvina.net > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden > > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Mon Mar 26 22:06:12 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379F421F8693 for ; Mon, 26 Mar 2012 22:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=-1.049, BAYES_00=-2.599, MANGLED_PILL=2.3] 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 bRC3kU7UBQT9 for ; Mon, 26 Mar 2012 22:06:11 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 38EBF21F8685 for ; Mon, 26 Mar 2012 22:06:10 -0700 (PDT) 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 q2R566Zd002112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2012 01:06:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332824768; bh=p+zKFY0fjE1s9ImxDSOw0ddcxiDb1XH+RoV7v9HA5Ew=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=rsTrDVKpmYHC2xBx1eLDUsyFyuEvc8WS84Ou87hKKV1w36w933wodg8FtC4Ebup23 dejQy5O6C6kk6l6kmjGjqeVhktyXDIOZpDIuyTD9ylOOLZWT1Tr4fQBiKjy4/IVuoY DLvyYanpkb9n0Hey7WvKJBuOe/dEzVwtY5AHdXo0= From: "Paul E. Jones" To: "'Hadriel Kaplan'" References: <4F70797D.9070104@nostrum.com> <053d01cd0b6f$d36e29a0$7a4a7ce0$@packetizer.com> In-Reply-To: Date: Tue, 27 Mar 2012 01:06:08 -0400 Message-ID: <001901cd0bd7$52dd4740$f897d5c0$@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: AQG9PF4X9wHVos1Td4S5OTcTaYF+OwErs5leAjscWoCWgfa9cA== Content-Language: en-us Cc: insipid@ietf.org, 'Adam Roach' Subject: Re: [Insipid] Use case to consider X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 05:06:12 -0000 Hadriel, > 1) A lot of times we think about use-cases as having one PBX, or one App- > Server, etc. But in practice there are often many in any given call path. > For example Alice called Bob in Adam's diagram, with both Alice and Bob > talking to "the" PBX. But in the real world Bob could easily be on > *another* PBX. In that case, there could be a Frank who joins the call on > Bob's PBX-1, or Bob could conference in Frank, etc., for the same call > that Carol joined on PBX-2. In that case, what is the UUID-pair between > PBX-1 and PBX-2? I'm having trouble following who is on PBX-1 and PBX-2, but let me provide an example... Assuming Alice (using UUID A1) is on PBX-1 and Bob (using UUID B1) is on PBX-2, then the call from Alice to Bob would have an end-to-end Session-ID of (A1||B1), with the concatenation order as specified in the draft or, if we wanted, with each component kept distinct. (I'm not sure if it matters whether we concatenate or not, but it is important that we have these distinct values.) Assume Frank is on PBX-3 and is brought into the conference somehow by Bob. The "somehow" is important. Let's say Bob is in a call with Frank. Then in that case, Bob has a separate call with Frank whose Session-ID is (B2||F1). Now, if Bob "joins" the call locally on his phone, then there are still two SIP sessions in progress. There is one from Bob to Alice and one from Bob to Frank. Bob might be mixing media locally, but these are two independent calls and nothing changed w.r.t. to the Session ID as a result of the join. If, however, Bob somehow pulled both calls into a conference hosted at the PBX or an MCU, then things changed. Likely, there was a conference Q created and the devices were REFERed to Q. So, there would be a call from Alice to Q (A1||Q), Bob to Q (B1||Q), and Frank to Q (F1||Q). B2 disappeared, since that call effectively vanished with the transfer. It is also possible that the PBX does some magic where it merges media together. That's similar to the other example Hadriel asked about and to which I replied. SIP allows for one to use very "open" signaling (like a REFER) to bring calls into a conference and it's also possible that calls are kept separate and media mixed such that devices are oblivious to the fact that things are merged. Perhaps it's useful to ask: who would respond to the BYE message should Alice send one at any point? That is indicative of where the session ends from her perspective. If the PBX effectively took over as the endpoint replacing Bob, for example, then that's where the session ends. It's really a conference focus without being named as such in this example. > 2) As Adam said, it's extremely common for the operators of PBXes to want > to hide the details of call monitoring. I'd argue it even beyond that, to > say they don't even want you to know that the call moves around; for > example in a call center from an IVR to an agent-queue/ACD to an agent to > potentially voicemail. So does the PBX always create a virtual UUID "P", > which it answers a call with by giving back to Alice "A || P", while > internally inside the call center it handles the separate/moving dialogs > using "P || B", "P || C", etc.? If the answer is "yes", then again as > above in (1), if there are *two* PBXs, we lose the end-to-end nature of > the correlator value, since the first PBX now bridges from "A || P1" to > "P1 || P2", and the second PBX from "P1 || P2" to "P2 || B". I don't > think that's a big deal for your intended use-cases, but for > troubleshooting it's not much better than what we have now. Yet arguably > it's the multi-PBX type cases that are the hardest to troubleshoot. What you describe seems to be counter to the objective of having an end-to-end session identifier. Certainly, a device could have this virtual "P", but that is like having an SBC today terminate a call and re-originate it using different identifiers. In some of the examples Hadriel was offering, I saw questions of "are we creating a conference and, thus a new call, or are we just mixing media at some point for calls?" Those questions have answers that yield different signaling topologies and, thus, different answers to what the Session-ID is. So, this question of introducing "P" and the desire to hide details seems to go against the objective of the work we're doing here. Certainly, it could be done, but not desirable if we want to track anything end-to-end. This puts the SBC at the "end", when it's actually in the middle. > 3) The draft says this: "Intermediaries such as session border controllers > MUST NOT change any Session Identifier component received from an endpoint > in a session." Do you mean this to only apply to SBCs, or to any and all > B2BUAs as well, such as PBXs? Why would an SBC vendor comply with this, > if the second-half of the identifier changes as the call moves around, > since SBCs are also used to hide such moving? (and yes, SBCs can also > process REFERs, re-INVITEs and INVITEs-with-Replaces locally instead of > passing them on) The "such as" was intended to mean SBCs are just one example. The same would be true for a PBX. The intent was to say that an SBC cannot receive a UUID "A" from an incoming call and re-write that as "B" on the outgoing call. It must remain as "A". If we want to change the rules so that the intermediary can re-write the UUID, then we lose the end-to-end property. > 4) It's a nit, but I don't get why the draft concatenates two UUIDs into > one "value", instead of just keeping them explicitly separate values. Like > with a defined separator, for example. It also violates the ABNF of > "Session-ID-UUID" to concatenate two UUIDs into the single header field > value, since a UUID is defined to be a fixed length. (again this is a nit, > but I thought I'd mention it so you can fix the ABNF) I went around on this a bit, too. I could be persuaded easily to change this. What I did not want is to have two headers. I wanted to have "value" that could be efficiently compared (versus two where we have to have the logic "if ((X==a) && (Y=b)) || (X=b) && (Y=a))" to do a comparison. So, I specified an order of concatenation to produce a single "value". Splitting it right down the middle re-produces the two individual UUIDs, of course. In any case, I'm open to any suggestions here that make it easier to use. Paul From paulej@packetizer.com Mon Mar 26 22:21:43 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC5321F877E for ; Mon, 26 Mar 2012 22:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 Ios69mjPZTfU for ; Mon, 26 Mar 2012 22:21:43 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 527D721F877C for ; Mon, 26 Mar 2012 22:21:42 -0700 (PDT) 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 q2R5Lbsp002502 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2012 01:21:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332825698; bh=3kbrA5C+OWS3h/62vbTlaWe04sU4/zigeOELpPaVpLc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=okwm1kcpoeYOw8wzv6tVgx9QAKFGZ9ksk1zUPCuaYrx/XyZNR/fNOEFNkZbsxeoZg 4AGFsq2v04wWRyecbnUgBQkIRDa+bdRoh0bv0JJXTDa9hkcOSWoa5a7/WEMjsuxX7i QqAE3KihXJpN5Qg7AD6qzzrunldpc4QTU6vLqZyM= From: "Paul E. Jones" To: "'Dawes, Peter, Vodafone Group'" , "'James M. Polk'" , References: <4A4F136CBD0E0D44AE1EDE36C4CD9D9901ABD4@VOEXM25W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D9901ABD4@VOEXM25W.internal.vodafone.com> Date: Tue, 27 Mar 2012 01:21:38 -0400 Message-ID: <001d01cd0bd9$7d6c49f0$7844ddd0$@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: AQIDJoHi/+D+cqb/LD7Uujh9nSHOWZYRZRfA Content-Language: en-us Cc: "'DRAGE, Keith \(Keith\)'" , 'Hadriel Kaplan' Subject: Re: [Insipid] Proposed New Requirement: Marking for Logging X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 05:21:44 -0000 Peter, Let me try to understand... There might be numerous calls happening all the time, but you do not wish to do logging for all of those calls that appear to be working properly. However, you'd like to introduce an extra flag that would trigger logging for a particular session when that flag is set. So, the logging would turn on only for flagged calls. Is that correct? Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Dawes, Peter, Vodafone Group > Sent: Monday, March 26, 2012 3:38 PM > To: James M. Polk; insipid@ietf.org > Cc: DRAGE, Keith (Keith); Hadriel Kaplan > Subject: [Insipid] Proposed New Requirement: Marking for Logging > > Hello James, All, > Thanks for presenting your requirements draft for the session identifier. > The requirement I propose to add is on slide 7 of my presentation in the > INSIPID meeting materials > (http://www.ietf.org/proceedings/83/slides/slides-83-insipid-1.pdf) as > follows: > > "It must be possible to mark a session identifier as inserted for logging > purposes" > "...in order to keep network operations and maintenance steps and also SIP > entity data volume and processing load to practical levels when > troubleshooting" > > Slides 1-6 illustrate the reasons behind this proposed requirement. > > Regards, > Peter > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From Peter.Dawes@vodafone.com Mon Mar 26 22:30:55 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1023121F85AA for ; Mon, 26 Mar 2012 22:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 70OOrbxJhK4J for ; Mon, 26 Mar 2012 22:30:54 -0700 (PDT) Received: from mailout04.vodafone.com (mailout04.vodafone.com [195.232.224.73]) by ietfa.amsl.com (Postfix) with ESMTP id EF3C821F85A4 for ; Mon, 26 Mar 2012 22:30:53 -0700 (PDT) Received: from mailint04 (localhost [127.0.0.1]) by mailout04 (Postfix) with ESMTP id 3EB091325AE for ; Tue, 27 Mar 2012 07:30:52 +0200 (CEST) Received: from avoexs02.internal.vodafone.com (unknown [145.230.4.135]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint04 (Postfix) with ESMTPS id 31A941323A1; Tue, 27 Mar 2012 07:30:52 +0200 (CEST) Received: from avoexf10.internal.vodafone.com ([145.230.6.94]) by avoexs02.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 07:30:24 +0200 Received: from AVOEXH04W.internal.vodafone.com (145.230.15.136) by avoexf10.internal.vodafone.com (145.230.6.94) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 27 Mar 2012 07:30:51 +0200 Received: from VOEXM25W.internal.vodafone.com ([169.254.1.200]) by AVOEXH04W.internal.vodafone.com ([145.230.15.136]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 07:30:23 +0200 From: "Dawes, Peter, Vodafone Group" To: "'paulej@packetizer.com'" , "'jmpolk@cisco.com'" , "'insipid@ietf.org'" Thread-Topic: [Insipid] Proposed New Requirement: Marking for Logging Thread-Index: Ac0Lhns7B/wPInZ2SSmBECCan5AchAAQj08AAAR/FM0= Date: Tue, 27 Mar 2012 05:30:22 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D9901B0D2@VOEXM25W.internal.vodafone.com> In-Reply-To: <001d01cd0bd9$7d6c49f0$7844ddd0$@packetizer.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [145.230.12.29] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Mar 2012 05:30:24.0482 (UTC) FILETIME=[B5D1E420:01CD0BDA] Cc: "'keith.drage@alcatel-lucent.com'" , "'HKaplan@acmepacket.com'" Subject: Re: [Insipid] Proposed New Requirement: Marking for Logging X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 05:30:55 -0000 Hi Paul, Yes that is correct, and having such a flag on the very few calls of intere= st simplifies the operation of the core network (network entity default beh= aviour can be to check for the flag and log such signalling).=20 Rgds, Peter=20 ----- Original Message ----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Tuesday, March 27, 2012 07:21 AM=0A= To: Dawes, Peter, Vodafone Group; 'James M. Polk' ; insip= id@ietf.org Cc: 'DRAGE, Keith (Keith)' ; 'Hadriel Kapla= n' Subject: RE: [Insipid] Proposed New Requirement: Marking for Logging Peter, Let me try to understand... There might be numerous calls happening all the time, but you do not wish t= o do logging for all of those calls that appear to be working properly. However, you'd like to introduce an extra flag that would trigger logging for a particular session when that flag is set. So, the logging would turn on only for flagged calls. Is that correct? Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of Dawes, Peter, Vodafone Group > Sent: Monday, March 26, 2012 3:38 PM > To: James M. Polk; insipid@ietf.org > Cc: DRAGE, Keith (Keith); Hadriel Kaplan > Subject: [Insipid] Proposed New Requirement: Marking for Logging >=20 > Hello James, All, > Thanks for presenting your requirements draft for the session identifier. > The requirement I propose to add is on slide 7 of my presentation in the > INSIPID meeting materials > (http://www.ietf.org/proceedings/83/slides/slides-83-insipid-1.pdf) as > follows: >=20 > "It must be possible to mark a session identifier as inserted for logging > purposes" > "...in order to keep network operations and maintenance steps and also SI= P > entity data volume and processing load to practical levels when > troubleshooting" >=20 > Slides 1-6 illustrate the reasons behind this proposed requirement. >=20 > Regards, > Peter >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From andrew.hutton@siemens-enterprise.com Tue Mar 27 01:31:24 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6DC21F88C4 for ; Tue, 27 Mar 2012 01:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 sG+b1jc+c8eC for ; Tue, 27 Mar 2012 01:31:23 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD8A21F88B8 for ; Tue, 27 Mar 2012 01:31:23 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 0546E23F0417; Tue, 27 Mar 2012 10:31:21 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 27 Mar 2012 10:31:20 +0200 From: "Hutton, Andrew" To: Hadriel Kaplan , "Olle E. Johansson" Date: Tue, 27 Mar 2012 10:31:19 +0200 Thread-Topic: [Insipid] Session-ID : user or server controlled Thread-Index: AQHNC18sE846Ae55GkWEhVZdRwK4KpZ9DHUAgAAAnQCAABaegIAArFBw Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31296BC68CA@MCHP058A.global-ad.net> References: <06343E8A-D16C-41EF-ACA9-89090A7DD6A1@edvina.net> <053f01cd0b70$136c26b0$3a447410$@packetizer.com> <245F6091-7D29-400C-8C10-BD1ABB27BE02@edvina.net> 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: "Paul E. Jones" , "" Subject: Re: [Insipid] Session-ID : user or server controlled X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:31:24 -0000 I am thinking that we also need to consider 3PCC scenarios in which the B2B= UA effectively initiates the two legs in this case the B2BUA is going to ge= nerate the session-id when it generates the initial INVITE request. Regards Andy > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: 26 March 2012 20:10 > To: Olle E. Johansson > Cc: Paul E. Jones; > Subject: Re: [Insipid] Session-ID : user or server controlled >=20 >=20 > [as an individual] >=20 > I don't see it in draft-jones-insipid-session-id-00 yet, but draft- > kaplan-dispatch-session-id-03 had the notion that a B2BUA could > generate a Session-ID if none was in the received request. This was to > provide a migration path for cases where the originating UAC > (softphone, gateway, whatever) did not yet support Session-ID and thus > did not generate it itself. (and likewise the B2BUA inserts it in the > response if the UAS did not support Session-ID and did not reflect it > in its responses) >=20 > -hadriel >=20 > On Mar 26, 2012, at 6:49 PM, Olle E. Johansson wrote: >=20 > > > > 26 mar 2012 kl. 18:47 skrev Paul E. Jones: > > > >> Coming in from the ISDN, that GW is the originating user agent as > far as SIP > >> is concerned. So, I think that's a reasonable place for the > Session-ID UUID > >> to be created for one end. > > But that is totally outside of my control. I will have to wait to a > majority of the larger SIP providers in Europe support this then... > > Not a solution, sorry. In this application, I just need to manage it > from the man-in-the-middle-box. > > > > /O > > > > > >> > >> Paul > >> > >>> -----Original Message----- > >>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf > >>> Of Olle E. Johansson > >>> Sent: Monday, March 26, 2012 10:46 AM > >>> To: insipid@ietf.org > >>> Subject: [Insipid] Session-ID : user or server controlled > >>> > >>> In the meeting today, I realized that we're talking about two very > >>> different use cases: > >>> > >>> - A user controlled session ID like in the draft > >>> - A server controlled session ID > >>> > >>> For call center applications, I need a server controlled session ID > I want > >>> to slap on a call coming in from the ISDN and keep as it traverses > several > >>> b2buas. At that point I don't even know which "user" that will be > an > >>> endpoint in the call and I don't really care. > >>> > >>> Just to confuse a little bit more, if needed. > >>> > >>> /O > >>> _______________________________________________ > >>> insipid mailing list > >>> insipid@ietf.org > >>> https://www.ietf.org/mailman/listinfo/insipid > >> > >> _______________________________________________ > >> insipid mailing list > >> insipid@ietf.org > >> https://www.ietf.org/mailman/listinfo/insipid > > > > --- > > * Olle E Johansson - oej@edvina.net > > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden > > > > > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From pravindran@sonusnet.com Tue Mar 27 01:45:29 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE82E21E8085 for ; Tue, 27 Mar 2012 01:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.111 X-Spam-Level: X-Spam-Status: No, score=-5.111 tagged_above=-999 required=5 tests=[AWL=1.488, 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 UBl0A7NkArxs for ; Tue, 27 Mar 2012 01:45:28 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id 417EB21F8931 for ; Tue, 27 Mar 2012 01:45:15 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKT3F+GjSnC4awSWdAxjHhR0zxQ/XzUtRG@postini.com; Tue, 27 Mar 2012 01:45:15 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 27 Mar 2012 04:45:32 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 14:15:06 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , Hadriel Kaplan , "Olle E. Johansson" Thread-Topic: [Insipid] Session-ID : user or server controlled Thread-Index: AQHNC18sg0JToSB8h0+DsKWuUyGO7ZZ8bTMAgAAAnQCAABajgIAA8JKAgABe1sA= Date: Tue, 27 Mar 2012 08:45:25 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E220A03@inba-mail01.sonusnet.com> References: <06343E8A-D16C-41EF-ACA9-89090A7DD6A1@edvina.net> <053f01cd0b70$136c26b0$3a447410$@packetizer.com> <245F6091-7D29-400C-8C10-BD1ABB27BE02@edvina.net> <101C6067BEC68246B0C3F6843BCCC1E31296BC68CA@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31296BC68CA@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Paul E. Jones" , "" Subject: Re: [Insipid] Session-ID : user or server controlled X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:45:29 -0000 Andy, I agree with you for 3PCC scenario. IMO, Paul Jones session-id serves the p= urpose as each UA attach their own URN UUID.=20 Thanks Partha Note: Paul Jones Session-id shall be considered as concatenation of partici= pant URN UUID in SIPREC terms >-----Original Message----- >From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >Behalf Of Hutton, Andrew >Sent: Tuesday, March 27, 2012 2:01 PM >To: Hadriel Kaplan; Olle E. Johansson >Cc: Paul E. Jones; >Subject: Re: [Insipid] Session-ID : user or server controlled > >I am thinking that we also need to consider 3PCC scenarios in which the >B2BUA effectively initiates the two legs in this case the B2BUA is going >to generate the session-id when it generates the initial INVITE request. > >Regards >Andy > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf Of Hadriel Kaplan >> Sent: 26 March 2012 20:10 >> To: Olle E. Johansson >> Cc: Paul E. Jones; >> Subject: Re: [Insipid] Session-ID : user or server controlled >> >> >> [as an individual] >> >> I don't see it in draft-jones-insipid-session-id-00 yet, but draft- >> kaplan-dispatch-session-id-03 had the notion that a B2BUA could >> generate a Session-ID if none was in the received request. This was >> to provide a migration path for cases where the originating UAC >> (softphone, gateway, whatever) did not yet support Session-ID and thus >> did not generate it itself. (and likewise the B2BUA inserts it in the >> response if the UAS did not support Session-ID and did not reflect it >> in its responses) >> >> -hadriel >> >> On Mar 26, 2012, at 6:49 PM, Olle E. Johansson wrote: >> >> > >> > 26 mar 2012 kl. 18:47 skrev Paul E. Jones: >> > >> >> Coming in from the ISDN, that GW is the originating user agent as >> far as SIP >> >> is concerned. So, I think that's a reasonable place for the >> Session-ID UUID >> >> to be created for one end. >> > But that is totally outside of my control. I will have to wait to a >> majority of the larger SIP providers in Europe support this then... >> > Not a solution, sorry. In this application, I just need to manage it >> from the man-in-the-middle-box. >> > >> > /O >> > >> > >> >> >> >> Paul >> >> >> >>> -----Original Message----- >> >>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] >> >>> On >> Behalf >> >>> Of Olle E. Johansson >> >>> Sent: Monday, March 26, 2012 10:46 AM >> >>> To: insipid@ietf.org >> >>> Subject: [Insipid] Session-ID : user or server controlled >> >>> >> >>> In the meeting today, I realized that we're talking about two very >> >>> different use cases: >> >>> >> >>> - A user controlled session ID like in the draft >> >>> - A server controlled session ID >> >>> >> >>> For call center applications, I need a server controlled session >> >>> ID >> I want >> >>> to slap on a call coming in from the ISDN and keep as it traverses >> several >> >>> b2buas. At that point I don't even know which "user" that will be >> an >> >>> endpoint in the call and I don't really care. >> >>> >> >>> Just to confuse a little bit more, if needed. >> >>> >> >>> /O >> >>> _______________________________________________ >> >>> insipid mailing list >> >>> insipid@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/insipid >> >> >> >> _______________________________________________ >> >> insipid mailing list >> >> insipid@ietf.org >> >> https://www.ietf.org/mailman/listinfo/insipid >> > >> > --- >> > * Olle E Johansson - oej@edvina.net >> > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden >> > >> > >> > >> > _______________________________________________ >> > insipid mailing list >> > insipid@ietf.org >> > https://www.ietf.org/mailman/listinfo/insipid >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Tue Mar 27 09:04:38 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F36921E80AB for ; Tue, 27 Mar 2012 09:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 U6CHeHINUTAY for ; Tue, 27 Mar 2012 09:04:37 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 335F921E8040 for ; Tue, 27 Mar 2012 09:04:37 -0700 (PDT) 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 q2RG4WuA011264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2012 12:04:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332864274; bh=J3KAX2Xyd3mRCtswSCouJSem67u1IBVnmqE+yq/8zFI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=JZVtUzrtgAXOHv4xuufM6P2/sbzVUqTJ9uOboaatD/Bh2KqEQqsOmTdWWzES7UJLl ojCVsySUS/1bgrWgTc9ZKEULkZz2oV/q+JjnmgJkHkqK5pNWc9+XvNMj0gqO47kF3P 6n1RSWSP4a9lrMMbPbnkzjWR92g33i5z/Py9laNs= From: "Paul E. Jones" To: "'Hutton, Andrew'" , "'Hadriel Kaplan'" , "'Olle E. Johansson'" References: <06343E8A-D16C-41EF-ACA9-89090A7DD6A1@edvina.net> <053f01cd0b70$136c26b0$3a447410$@packetizer.com> <245F6091-7D29-400C-8C10-BD1ABB27BE02@edvina.net> <101C6067BEC68246B0C3F6843BCCC1E31296BC68CA@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31296BC68CA@MCHP058A.global-ad.net> Date: Tue, 27 Mar 2012 12:04:35 -0400 Message-ID: <00aa01cd0c33$4ed527b0$ec7f7710$@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: AQHl9oeKoqc7qsKpduOGWiEHsS5KxQHnaxoAAaDTJKsBeKZ9QAHX7L88lhWySVA= Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Session-ID : user or server controlled X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 16:04:38 -0000 It seems there is general agreement with that point. We had inserted it into the requirements as REQ7, but we had not covered that in draft-jones-insipid-session-id. We should have, though. Indeed, I expect that phones connected to a PBX may or may not generate a UUID (depending on the date of their firmware) to generate these UUIDs, but we would certainly want the network to benefit from being able to track a session at least to the PBX, if not to the phone. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Hutton, Andrew > Sent: Tuesday, March 27, 2012 4:31 AM > To: Hadriel Kaplan; Olle E. Johansson > Cc: Paul E. Jones; > Subject: Re: [Insipid] Session-ID : user or server controlled > > I am thinking that we also need to consider 3PCC scenarios in which the > B2BUA effectively initiates the two legs in this case the B2BUA is going > to generate the session-id when it generates the initial INVITE request. > > Regards > Andy > > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf Of Hadriel Kaplan > > Sent: 26 March 2012 20:10 > > To: Olle E. Johansson > > Cc: Paul E. Jones; > > Subject: Re: [Insipid] Session-ID : user or server controlled > > > > > > [as an individual] > > > > I don't see it in draft-jones-insipid-session-id-00 yet, but draft- > > kaplan-dispatch-session-id-03 had the notion that a B2BUA could > > generate a Session-ID if none was in the received request. This was > > to provide a migration path for cases where the originating UAC > > (softphone, gateway, whatever) did not yet support Session-ID and thus > > did not generate it itself. (and likewise the B2BUA inserts it in the > > response if the UAS did not support Session-ID and did not reflect it > > in its responses) > > > > -hadriel > > > > On Mar 26, 2012, at 6:49 PM, Olle E. Johansson wrote: > > > > > > > > 26 mar 2012 kl. 18:47 skrev Paul E. Jones: > > > > > >> Coming in from the ISDN, that GW is the originating user agent as > > far as SIP > > >> is concerned. So, I think that's a reasonable place for the > > Session-ID UUID > > >> to be created for one end. > > > But that is totally outside of my control. I will have to wait to a > > majority of the larger SIP providers in Europe support this then... > > > Not a solution, sorry. In this application, I just need to manage it > > from the man-in-the-middle-box. > > > > > > /O > > > > > > > > >> > > >> Paul > > >> > > >>> -----Original Message----- > > >>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] > > >>> On > > Behalf > > >>> Of Olle E. Johansson > > >>> Sent: Monday, March 26, 2012 10:46 AM > > >>> To: insipid@ietf.org > > >>> Subject: [Insipid] Session-ID : user or server controlled > > >>> > > >>> In the meeting today, I realized that we're talking about two very > > >>> different use cases: > > >>> > > >>> - A user controlled session ID like in the draft > > >>> - A server controlled session ID > > >>> > > >>> For call center applications, I need a server controlled session > > >>> ID > > I want > > >>> to slap on a call coming in from the ISDN and keep as it traverses > > several > > >>> b2buas. At that point I don't even know which "user" that will be > > an > > >>> endpoint in the call and I don't really care. > > >>> > > >>> Just to confuse a little bit more, if needed. > > >>> > > >>> /O > > >>> _______________________________________________ > > >>> insipid mailing list > > >>> insipid@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/insipid > > >> > > >> _______________________________________________ > > >> insipid mailing list > > >> insipid@ietf.org > > >> https://www.ietf.org/mailman/listinfo/insipid > > > > > > --- > > > * Olle E Johansson - oej@edvina.net > > > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden > > > > > > > > > > > > _______________________________________________ > > > insipid mailing list > > > insipid@ietf.org > > > https://www.ietf.org/mailman/listinfo/insipid > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Tue Mar 27 10:33:17 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362A521E808A for ; Tue, 27 Mar 2012 10:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 Fodc96SuwN-a for ; Tue, 27 Mar 2012 10:33:16 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by ietfa.amsl.com (Postfix) with ESMTP id AE5AE21E8029 for ; Tue, 27 Mar 2012 10:33:13 -0700 (PDT) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta15.emeryville.ca.mail.comcast.net with comcast id qgxo1i0011ZMdJ4AFhZDwW; Tue, 27 Mar 2012 17:33:13 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta16.emeryville.ca.mail.comcast.net with comcast id qhZ31i02V5EhBnE8chZ6bo; Tue, 27 Mar 2012 17:33:11 +0000 Message-ID: <4F71F9CF.1090302@alum.mit.edu> Date: Tue, 27 Mar 2012 19:33:03 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <4A4F136CBD0E0D44AE1EDE36C4CD9D9901ABD4@VOEXM25W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D9901ABD4@VOEXM25W.internal.vodafone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] Proposed New Requirement: Marking for Logging X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 17:33:17 -0000 I don't quite get this. It sounds like you are bundling two things that don't need to be bundled: - the session-id - a request to log the call I see no need to couple those things. If you can mark the call to be logged, and if it happens to have a sesson-id, then there will be data about the call, including the session-id, in logs of all the systems traversed. But you can still have session-ids without logging, and you can have logging without session-ids. Thanks, Paul On 3/26/12 9:38 PM, Dawes, Peter, Vodafone Group wrote: > Hello James, All, > Thanks for presenting your requirements draft for the session identifier. The requirement I propose to add is on slide 7 of my presentation in the INSIPID meeting materials (http://www.ietf.org/proceedings/83/slides/slides-83-insipid-1.pdf) as follows: > > "It must be possible to mark a session identifier as inserted for logging purposes" > "...in order to keep network operations and maintenance steps and also SIP entity data volume and processing load to practical levels when troubleshooting" > > Slides 1-6 illustrate the reasons behind this proposed requirement. > > Regards, > Peter > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From pkyzivat@alum.mit.edu Tue Mar 27 23:32:41 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DAB21F8759 for ; Tue, 27 Mar 2012 23:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 wH8ZPjQHECw1 for ; Tue, 27 Mar 2012 23:32:40 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by ietfa.amsl.com (Postfix) with ESMTP id 75DE821F8758 for ; Tue, 27 Mar 2012 23:32:39 -0700 (PDT) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta15.emeryville.ca.mail.comcast.net with comcast id quVC1i0010QkzPwAFuYeoD; Wed, 28 Mar 2012 06:32:38 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta02.emeryville.ca.mail.comcast.net with comcast id quYV1i00D5EhBnE8NuYXhS; Wed, 28 Mar 2012 06:32:36 +0000 Message-ID: <4F722AA0.3010807@alum.mit.edu> Date: Tue, 27 Mar 2012 23:01:20 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <4F70797D.9070104@nostrum.com> <053d01cd0b6f$d36e29a0$7a4a7ce0$@packetizer.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] Use case to consider X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 06:32:41 -0000 On 3/26/12 10:04 PM, Hadriel Kaplan wrote: > Yet arguably it's the multi-PBX type cases that are the hardest to *troubles hoot*. Best part of the discussion so far. :-) Thanks, Paul From pkyzivat@alum.mit.edu Tue Mar 27 23:32:50 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34EDD21F8759 for ; Tue, 27 Mar 2012 23:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[AWL=-1.470, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, MANGLED_PILL=2.3] 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 nMvuyMgZhTn4 for ; Tue, 27 Mar 2012 23:32:49 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by ietfa.amsl.com (Postfix) with ESMTP id 78F2A21F8758 for ; Tue, 27 Mar 2012 23:32:49 -0700 (PDT) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta10.emeryville.ca.mail.comcast.net with comcast id quY51i00316AWCUAAuYp1U; Wed, 28 Mar 2012 06:32:49 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta06.emeryville.ca.mail.comcast.net with comcast id quYf1i00T5EhBnE8SuYi7c; Wed, 28 Mar 2012 06:32:47 +0000 Message-ID: <4F722D02.3050709@alum.mit.edu> Date: Tue, 27 Mar 2012 23:11:30 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <4F70797D.9070104@nostrum.com> <053d01cd0b6f$d36e29a0$7a4a7ce0$@packetizer.com> <001901cd0bd7$52dd4740$f897d5c0$@packetizer.com> In-Reply-To: <001901cd0bd7$52dd4740$f897d5c0$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] Use case to consider X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 06:32:50 -0000 Paul J, IIRC, what your draft is really proposing is that an identifier be assigned per call-*leg*, and that each UA keep track of its own call-leg-id and the call-leg-id of some other call-leg in a "session" with it. Maybe that is the call-leg-id of the *first* other leg in the session, though it could equally well be the *most recent* call-leg-id. And then when logging, etc. it is to record both of those call-leg-ids. In principle, I suppose a UA could keep track of more than one call-leg-id of other legs in its session, if it becomes aware of them. And then it could log whichever it has. Thanks, Paul K On 3/27/12 7:06 AM, Paul E. Jones wrote: > Hadriel, > >> 1) A lot of times we think about use-cases as having one PBX, or one App- >> Server, etc. But in practice there are often many in any given call path. >> For example Alice called Bob in Adam's diagram, with both Alice and Bob >> talking to "the" PBX. But in the real world Bob could easily be on >> *another* PBX. In that case, there could be a Frank who joins the call on >> Bob's PBX-1, or Bob could conference in Frank, etc., for the same call >> that Carol joined on PBX-2. In that case, what is the UUID-pair between >> PBX-1 and PBX-2? > > I'm having trouble following who is on PBX-1 and PBX-2, but let me provide > an example... > > Assuming Alice (using UUID A1) is on PBX-1 and Bob (using UUID B1) is on > PBX-2, then the call from Alice to Bob would have an end-to-end Session-ID > of (A1||B1), with the concatenation order as specified in the draft or, if > we wanted, with each component kept distinct. (I'm not sure if it matters > whether we concatenate or not, but it is important that we have these > distinct values.) > > Assume Frank is on PBX-3 and is brought into the conference somehow by Bob. > The "somehow" is important. Let's say Bob is in a call with Frank. Then in > that case, Bob has a separate call with Frank whose Session-ID is (B2||F1). > Now, if Bob "joins" the call locally on his phone, then there are still two > SIP sessions in progress. There is one from Bob to Alice and one from Bob > to Frank. Bob might be mixing media locally, but these are two independent > calls and nothing changed w.r.t. to the Session ID as a result of the join. > > If, however, Bob somehow pulled both calls into a conference hosted at the > PBX or an MCU, then things changed. Likely, there was a conference Q > created and the devices were REFERed to Q. So, there would be a call from > Alice to Q (A1||Q), Bob to Q (B1||Q), and Frank to Q (F1||Q). B2 > disappeared, since that call effectively vanished with the transfer. > > It is also possible that the PBX does some magic where it merges media > together. That's similar to the other example Hadriel asked about and to > which I replied. > > SIP allows for one to use very "open" signaling (like a REFER) to bring > calls into a conference and it's also possible that calls are kept separate > and media mixed such that devices are oblivious to the fact that things are > merged. Perhaps it's useful to ask: who would respond to the BYE message > should Alice send one at any point? That is indicative of where the session > ends from her perspective. If the PBX effectively took over as the endpoint > replacing Bob, for example, then that's where the session ends. It's really > a conference focus without being named as such in this example. > >> 2) As Adam said, it's extremely common for the operators of PBXes to want >> to hide the details of call monitoring. I'd argue it even beyond that, to >> say they don't even want you to know that the call moves around; for >> example in a call center from an IVR to an agent-queue/ACD to an agent to >> potentially voicemail. So does the PBX always create a virtual UUID "P", >> which it answers a call with by giving back to Alice "A || P", while >> internally inside the call center it handles the separate/moving dialogs >> using "P || B", "P || C", etc.? If the answer is "yes", then again as >> above in (1), if there are *two* PBXs, we lose the end-to-end nature of >> the correlator value, since the first PBX now bridges from "A || P1" to >> "P1 || P2", and the second PBX from "P1 || P2" to "P2 || B". I don't >> think that's a big deal for your intended use-cases, but for >> troubleshooting it's not much better than what we have now. Yet arguably >> it's the multi-PBX type cases that are the hardest to troubleshoot. > > What you describe seems to be counter to the objective of having an > end-to-end session identifier. Certainly, a device could have this virtual > "P", but that is like having an SBC today terminate a call and re-originate > it using different identifiers. In some of the examples Hadriel was > offering, I saw questions of "are we creating a conference and, thus a new > call, or are we just mixing media at some point for calls?" Those questions > have answers that yield different signaling topologies and, thus, different > answers to what the Session-ID is. > > So, this question of introducing "P" and the desire to hide details seems to > go against the objective of the work we're doing here. Certainly, it could > be done, but not desirable if we want to track anything end-to-end. This > puts the SBC at the "end", when it's actually in the middle. > > >> 3) The draft says this: "Intermediaries such as session border controllers >> MUST NOT change any Session Identifier component received from an endpoint >> in a session." Do you mean this to only apply to SBCs, or to any and all >> B2BUAs as well, such as PBXs? Why would an SBC vendor comply with this, >> if the second-half of the identifier changes as the call moves around, >> since SBCs are also used to hide such moving? (and yes, SBCs can also >> process REFERs, re-INVITEs and INVITEs-with-Replaces locally instead of >> passing them on) > > The "such as" was intended to mean SBCs are just one example. The same > would be true for a PBX. The intent was to say that an SBC cannot receive a > UUID "A" from an incoming call and re-write that as "B" on the outgoing > call. It must remain as "A". > > If we want to change the rules so that the intermediary can re-write the > UUID, then we lose the end-to-end property. > >> 4) It's a nit, but I don't get why the draft concatenates two UUIDs into >> one "value", instead of just keeping them explicitly separate values. Like >> with a defined separator, for example. It also violates the ABNF of >> "Session-ID-UUID" to concatenate two UUIDs into the single header field >> value, since a UUID is defined to be a fixed length. (again this is a nit, >> but I thought I'd mention it so you can fix the ABNF) > > I went around on this a bit, too. I could be persuaded easily to change > this. What I did not want is to have two headers. I wanted to have "value" > that could be efficiently compared (versus two where we have to have the > logic "if ((X==a)&& (Y=b)) || (X=b)&& (Y=a))" to do a comparison. So, I > specified an order of concatenation to produce a single "value". Splitting > it right down the middle re-produces the two individual UUIDs, of course. > > In any case, I'm open to any suggestions here that make it easier to use. > > Paul > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From Peter.Dawes@vodafone.com Wed Mar 28 08:44:38 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6580F21E81D2 for ; Wed, 28 Mar 2012 08:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 E9Ym9SlNCKd9 for ; Wed, 28 Mar 2012 08:44:37 -0700 (PDT) Received: from mailout02.vodafone.com (mailout02.vodafone.com [195.232.224.71]) by ietfa.amsl.com (Postfix) with ESMTP id CCF6121E80BD for ; Wed, 28 Mar 2012 08:44:26 -0700 (PDT) Received: from mailint02 (localhost [127.0.0.1]) by mailout02 (Postfix) with ESMTP id 8954D2146BF for ; Wed, 28 Mar 2012 17:44:24 +0200 (CEST) Received: from avoexs01.internal.vodafone.com (unknown [145.230.4.134]) by mailint02 (Postfix) with ESMTP id 7DB7F2146A3; Wed, 28 Mar 2012 17:44:24 +0200 (CEST) Received: from avoexf09.internal.vodafone.com ([145.230.6.95]) by avoexs01.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 17:43:56 +0200 Received: from VOEXC02W.internal.vodafone.com (145.230.101.22) by avoexf09.internal.vodafone.com (145.230.6.95) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 28 Mar 2012 17:44:24 +0200 Received: from VOEXM25W.internal.vodafone.com ([169.254.1.200]) by VOEXC02W.internal.vodafone.com ([145.230.101.22]) with mapi id 14.01.0355.002; Wed, 28 Mar 2012 17:43:56 +0200 From: "Dawes, Peter, Vodafone Group" To: Paul Kyzivat , "insipid@ietf.org" Thread-Topic: [Insipid] Proposed New Requirement: Marking for Logging Thread-Index: Ac0Lhns7B/wPInZ2SSmBECCan5AchAAqGq+AADJ5xcA= Date: Wed, 28 Mar 2012 15:43:55 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D9901BB6A@VOEXM25W.internal.vodafone.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D9901ABD4@VOEXM25W.internal.vodafone.com> <4F71F9CF.1090302@alum.mit.edu> In-Reply-To: <4F71F9CF.1090302@alum.mit.edu> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [145.230.12.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Mar 2012 15:43:56.0745 (UTC) FILETIME=[960D3390:01CD0CF9] Subject: Re: [Insipid] Proposed New Requirement: Marking for Logging X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 15:44:38 -0000 Hello Paul, One of the use cases of session-id is end-to-end troubleshooting, including= when session end points are in different networks, and I believe that the = marking is needed to make this troubleshooting practical and scaleable. So = I believe these two things need to be bundled. Regards, Peter -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 27 March 2012 18:33 To: insipid@ietf.org Subject: Re: [Insipid] Proposed New Requirement: Marking for Logging I don't quite get this. It sounds like you are bundling two things that don= 't need to be bundled: - the session-id - a request to log the call I see no need to couple those things. If you can mark the call to be logged= , and if it happens to have a sesson-id, then there will be data about the = call, including the session-id, in logs of all the systems traversed. But y= ou can still have session-ids without logging, and you can have logging wit= hout session-ids. Thanks, Paul On 3/26/12 9:38 PM, Dawes, Peter, Vodafone Group wrote: > Hello James, All, > Thanks for presenting your requirements draft for the session identifier.= The requirement I propose to add is on slide 7 of my presentation in the I= NSIPID meeting materials (http://www.ietf.org/proceedings/83/slides/slides-= 83-insipid-1.pdf) as follows: > > "It must be possible to mark a session identifier as inserted for logging= purposes" > "...in order to keep network operations and maintenance steps and also SI= P entity data volume and processing load to practical levels when troublesh= ooting" > > Slides 1-6 illustrate the reasons behind this proposed requirement. > > Regards, > Peter > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Wed Mar 28 16:06:01 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1388821E8153 for ; Wed, 28 Mar 2012 16:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[AWL=-1.048, BAYES_00=-2.599, MANGLED_PILL=2.3] 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 zDTpCuAA73sy for ; Wed, 28 Mar 2012 16:06:00 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A05C521E8151 for ; Wed, 28 Mar 2012 16:05:59 -0700 (PDT) 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 q2SN5sZl030237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Mar 2012 19:05:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332975957; bh=rRQwiIwUsBqx9UI6Wo5+0zSO5ZOYT+NJ89v4Gk7WoeQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=TsfVSHHRmU267yup/QRaaqsLjpIPwMktB+PH5uXNBZDr26+t28WucG+XAJ37DSSjf 0Dc05j4IU0JlberOlqROKPcs7znu8YG3Z1HAVJO5v6ekNIy27RC2vKeiGm1XIhW9Td Q2zcpG5LjJDjFe6KwdAf3UgyxrhxC43r7WFcJxj4= From: "Paul E. Jones" To: "'Paul Kyzivat'" , References: <4F70797D.9070104@nostrum.com> <053d01cd0b6f$d36e29a0$7a4a7ce0$@packetizer.com> <001901cd0bd7$52dd4740$f897d5c0$@packetizer.com> <4F722D02.3050709@alum.mit.edu> In-Reply-To: <4F722D02.3050709@alum.mit.edu> Date: Wed, 28 Mar 2012 19:06:00 -0400 Message-ID: <025001cd0d37$58c7bda0$0a5738e0$@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: AQG9PF4X9wHVos1Td4S5OTcTaYF+OwErs5leAjscWoACo8MgOwGwLLw+lmIemyA= Content-Language: en-us Subject: Re: [Insipid] Use case to consider X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 23:06:01 -0000 Paul, As long as "leg" extends end-to-end, then that's roughly correct. However, there is enough confusion in terms, so I'd prefer we uses "Session-ID-UUID" or something. But, yes, there are two unique IDs, one from Alice and one from Bob. These two IDs together are the Session-ID. For a given call, there should never be more than two UUIDs to track (Alice's and Bob's). The remote UUID (Bob's) might change, though, due to service interactions (e.g., Bob transfers the call to Alice, or Bob's PBX merges two calls locally into one new call). Such changes would be noted with an INVITE (likely) coming to Alice with a new Session-ID-UUID. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Tuesday, March 27, 2012 5:12 PM > To: insipid@ietf.org > Subject: Re: [Insipid] Use case to consider > > Paul J, > > IIRC, what your draft is really proposing is that an identifier be > assigned per call-*leg*, and that each UA keep track of its own call-leg- > id and the call-leg-id of some other call-leg in a "session" > with it. Maybe that is the call-leg-id of the *first* other leg in the > session, though it could equally well be the *most recent* call-leg-id. > And then when logging, etc. it is to record both of those call-leg-ids. > > In principle, I suppose a UA could keep track of more than one call-leg-id > of other legs in its session, if it becomes aware of them. > And then it could log whichever it has. > > Thanks, > Paul K > > On 3/27/12 7:06 AM, Paul E. Jones wrote: > > Hadriel, > > > >> 1) A lot of times we think about use-cases as having one PBX, or one > >> App- Server, etc. But in practice there are often many in any given > call path. > >> For example Alice called Bob in Adam's diagram, with both Alice and > >> Bob talking to "the" PBX. But in the real world Bob could easily be > >> on > >> *another* PBX. In that case, there could be a Frank who joins the > >> call on Bob's PBX-1, or Bob could conference in Frank, etc., for the > >> same call that Carol joined on PBX-2. In that case, what is the > >> UUID-pair between > >> PBX-1 and PBX-2? > > > > I'm having trouble following who is on PBX-1 and PBX-2, but let me > > provide an example... > > > > Assuming Alice (using UUID A1) is on PBX-1 and Bob (using UUID B1) is > > on PBX-2, then the call from Alice to Bob would have an end-to-end > > Session-ID of (A1||B1), with the concatenation order as specified in > > the draft or, if we wanted, with each component kept distinct. (I'm > > not sure if it matters whether we concatenate or not, but it is > > important that we have these distinct values.) > > > > Assume Frank is on PBX-3 and is brought into the conference somehow by > Bob. > > The "somehow" is important. Let's say Bob is in a call with Frank. > > Then in that case, Bob has a separate call with Frank whose Session-ID > is (B2||F1). > > Now, if Bob "joins" the call locally on his phone, then there are > > still two SIP sessions in progress. There is one from Bob to Alice > > and one from Bob to Frank. Bob might be mixing media locally, but > > these are two independent calls and nothing changed w.r.t. to the > Session ID as a result of the join. > > > > If, however, Bob somehow pulled both calls into a conference hosted at > > the PBX or an MCU, then things changed. Likely, there was a > > conference Q created and the devices were REFERed to Q. So, there > > would be a call from Alice to Q (A1||Q), Bob to Q (B1||Q), and Frank > > to Q (F1||Q). B2 disappeared, since that call effectively vanished with > the transfer. > > > > It is also possible that the PBX does some magic where it merges media > > together. That's similar to the other example Hadriel asked about and > > to which I replied. > > > > SIP allows for one to use very "open" signaling (like a REFER) to > > bring calls into a conference and it's also possible that calls are > > kept separate and media mixed such that devices are oblivious to the > > fact that things are merged. Perhaps it's useful to ask: who would > > respond to the BYE message should Alice send one at any point? That > > is indicative of where the session ends from her perspective. If the > > PBX effectively took over as the endpoint replacing Bob, for example, > > then that's where the session ends. It's really a conference focus > without being named as such in this example. > > > >> 2) As Adam said, it's extremely common for the operators of PBXes to > >> want to hide the details of call monitoring. I'd argue it even > >> beyond that, to say they don't even want you to know that the call > >> moves around; for example in a call center from an IVR to an > >> agent-queue/ACD to an agent to potentially voicemail. So does the > >> PBX always create a virtual UUID "P", which it answers a call with by > >> giving back to Alice "A || P", while internally inside the call > >> center it handles the separate/moving dialogs using "P || B", "P || > >> C", etc.? If the answer is "yes", then again as above in (1), if > >> there are *two* PBXs, we lose the end-to-end nature of the correlator > >> value, since the first PBX now bridges from "A || P1" to > >> "P1 || P2", and the second PBX from "P1 || P2" to "P2 || B". I don't > >> think that's a big deal for your intended use-cases, but for > >> troubleshooting it's not much better than what we have now. Yet > >> arguably it's the multi-PBX type cases that are the hardest to > troubleshoot. > > > > What you describe seems to be counter to the objective of having an > > end-to-end session identifier. Certainly, a device could have this > > virtual "P", but that is like having an SBC today terminate a call and > > re-originate it using different identifiers. In some of the examples > > Hadriel was offering, I saw questions of "are we creating a conference > > and, thus a new call, or are we just mixing media at some point for > > calls?" Those questions have answers that yield different signaling > > topologies and, thus, different answers to what the Session-ID is. > > > > So, this question of introducing "P" and the desire to hide details > > seems to go against the objective of the work we're doing here. > > Certainly, it could be done, but not desirable if we want to track > > anything end-to-end. This puts the SBC at the "end", when it's actually > in the middle. > > > > > >> 3) The draft says this: "Intermediaries such as session border > >> controllers MUST NOT change any Session Identifier component received > >> from an endpoint in a session." Do you mean this to only apply to > >> SBCs, or to any and all B2BUAs as well, such as PBXs? Why would an > >> SBC vendor comply with this, if the second-half of the identifier > >> changes as the call moves around, since SBCs are also used to hide > >> such moving? (and yes, SBCs can also process REFERs, re-INVITEs and > >> INVITEs-with-Replaces locally instead of passing them on) > > > > The "such as" was intended to mean SBCs are just one example. The > > same would be true for a PBX. The intent was to say that an SBC > > cannot receive a UUID "A" from an incoming call and re-write that as > > "B" on the outgoing call. It must remain as "A". > > > > If we want to change the rules so that the intermediary can re-write > > the UUID, then we lose the end-to-end property. > > > >> 4) It's a nit, but I don't get why the draft concatenates two UUIDs > >> into one "value", instead of just keeping them explicitly separate > >> values. Like with a defined separator, for example. It also violates > >> the ABNF of "Session-ID-UUID" to concatenate two UUIDs into the > >> single header field value, since a UUID is defined to be a fixed > >> length. (again this is a nit, but I thought I'd mention it so you can > >> fix the ABNF) > > > > I went around on this a bit, too. I could be persuaded easily to > > change this. What I did not want is to have two headers. I wanted to > have "value" > > that could be efficiently compared (versus two where we have to have > > the logic "if ((X==a)&& (Y=b)) || (X=b)&& (Y=a))" to do a > > comparison. So, I specified an order of concatenation to produce a > > single "value". Splitting it right down the middle re-produces the two > individual UUIDs, of course. > > > > In any case, I'm open to any suggestions here that make it easier to > use. > > > > Paul > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From gonzalo.camarillo@ericsson.com Thu Mar 29 00:30:13 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EB321F86B8 for ; Thu, 29 Mar 2012 00:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.375 X-Spam-Level: X-Spam-Status: No, score=-110.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 P1AANsO+rtDN for ; Thu, 29 Mar 2012 00:30:12 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A3CA021F866B for ; Thu, 29 Mar 2012 00:30:11 -0700 (PDT) X-AuditID: c1b4fb3d-b7b5aae000002dcb-0e-4f740f7ef8ec Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EE.E9.11723.E7F047F4; Thu, 29 Mar 2012 09:30:07 +0200 (CEST) Received: from [131.160.126.209] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Thu, 29 Mar 2012 09:30:06 +0200 Message-ID: <4F740F7D.30808@ericsson.com> Date: Thu, 29 Mar 2012 09:30:05 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: insipid@ietf.org X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [Insipid] INSIPID chairs X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 07:30:13 -0000 Folks, as you know, Hadriel and Keith had agreed to chair the first INSIPID session until we found more permanent chairs. Now we have found them. They will be Keith Drage and Gonzalo Salgueiro. I have already asked the Secretary to update the charter page accordingly. I would like to thank Hadriel for his help kicking off this group. I expect him to continue being involved in this group as an individual contributor. Cheers, Gonzalo From pkyzivat@alum.mit.edu Thu Mar 29 05:09:08 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6865421F8A55 for ; Thu, 29 Mar 2012 05:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] 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 gD4rcKUMYPlM for ; Thu, 29 Mar 2012 05:09:01 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id AD08C21F88DC for ; Thu, 29 Mar 2012 05:08:56 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA11.westchester.pa.mail.comcast.net with comcast id rQ5k1i0030QuhwU5BQ8wbg; Thu, 29 Mar 2012 12:08:56 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta02.westchester.pa.mail.comcast.net with comcast id rQ8m1i0075EhBnE3NQ8ohW; Thu, 29 Mar 2012 12:08:54 +0000 Message-ID: <4F737D50.5050000@alum.mit.edu> Date: Wed, 28 Mar 2012 23:06:24 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: "Dawes, Peter, Vodafone Group" References: <4A4F136CBD0E0D44AE1EDE36C4CD9D9901ABD4@VOEXM25W.internal.vodafone.com> <4F71F9CF.1090302@alum.mit.edu> <4A4F136CBD0E0D44AE1EDE36C4CD9D9901BB6A@VOEXM25W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D9901BB6A@VOEXM25W.internal.vodafone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "insipid@ietf.org" Subject: Re: [Insipid] Proposed New Requirement: Marking for Logging X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:09:08 -0000 On 3/28/12 5:43 PM, Dawes, Peter, Vodafone Group wrote: > Hello Paul, > One of the use cases of session-id is end-to-end troubleshooting, including when session end points are in different networks, and I believe that the marking is needed to make this troubleshooting practical and scaleable. So I believe these two things need to be bundled. Peter, Surely there is a lot of trouble shooting that could proceed using session id *without* a way to signal a request to log this call. The ability to make such a signal might indeed be useful. But its separable. It especially doesn't have to be in the same header. And I expect that if we end up defining a new header for session id, it will have an extension point (e.g. parameters) that could be used to define such a signal. Thanks, Paul > Regards, > Peter > > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 27 March 2012 18:33 > To: insipid@ietf.org > Subject: Re: [Insipid] Proposed New Requirement: Marking for Logging > > I don't quite get this. It sounds like you are bundling two things that don't need to be bundled: > - the session-id > - a request to log the call > > I see no need to couple those things. If you can mark the call to be logged, and if it happens to have a sesson-id, then there will be data about the call, including the session-id, in logs of all the systems traversed. But you can still have session-ids without logging, and you can have logging without session-ids. > > Thanks, > Paul > > On 3/26/12 9:38 PM, Dawes, Peter, Vodafone Group wrote: >> Hello James, All, >> Thanks for presenting your requirements draft for the session identifier. The requirement I propose to add is on slide 7 of my presentation in the INSIPID meeting materials (http://www.ietf.org/proceedings/83/slides/slides-83-insipid-1.pdf) as follows: >> >> "It must be possible to mark a session identifier as inserted for logging purposes" >> "...in order to keep network operations and maintenance steps and also SIP entity data volume and processing load to practical levels when troubleshooting" >> >> Slides 1-6 illustrate the reasons behind this proposed requirement. >> >> Regards, >> Peter >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >> > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From pkyzivat@alum.mit.edu Thu Mar 29 06:55:43 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFBB21F8B96 for ; Thu, 29 Mar 2012 06:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[AWL=-0.826, BAYES_00=-2.599, MANGLED_PILL=2.3] 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 2kEv7MWSk9fN for ; Thu, 29 Mar 2012 06:55:42 -0700 (PDT) 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 104F021F8973 for ; Thu, 29 Mar 2012 06:55:41 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta10.westchester.pa.mail.comcast.net with comcast id rQCq1i0041swQuc5ARvi3b; Thu, 29 Mar 2012 13:55:42 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta15.westchester.pa.mail.comcast.net with comcast id rRvW1i01M5EhBnE3bRvZiE; Thu, 29 Mar 2012 13:55:40 +0000 Message-ID: <4F7469D1.4050509@alum.mit.edu> Date: Thu, 29 Mar 2012 15:55:29 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <4F70797D.9070104@nostrum.com> <053d01cd0b6f$d36e29a0$7a4a7ce0$@packetizer.com> <001901cd0bd7$52dd4740$f897d5c0$@packetizer.com> <4F722D02.3050709@alum.mit.edu> <025001cd0d37$58c7bda0$0a5738e0$@packetizer.com> In-Reply-To: <025001cd0d37$58c7bda0$0a5738e0$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: insipid@ietf.org Subject: Re: [Insipid] Use case to consider X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:55:43 -0000 On 3/29/12 1:06 AM, Paul E. Jones wrote: > Paul, > > As long as "leg" extends end-to-end, then that's roughly correct. However, > there is enough confusion in terms, so I'd prefer we uses "Session-ID-UUID" > or something. But, yes, there are two unique IDs, one from Alice and one > from Bob. These two IDs together are the Session-ID. I know you are describing it as one thing, but what you are proposing is a *pair* of things. My point is that each "leg" (aka "half call") has its own id, and becomes part of a pair. This is exactly analogous to the tags (to-tag and from-tag) that form part of the dialog id. > For a given call, there should never be more than two UUIDs to track > (Alice's and Bob's). The remote UUID (Bob's) might change, though, due to > service interactions (e.g., Bob transfers the call to Alice, or Bob's PBX > merges two calls locally into one new call). Such changes would be noted > with an INVITE (likely) coming to Alice with a new Session-ID-UUID. Its here that what you say gets a bit controversial. Your use of "call" here is pretty loose - we probably won't all agree with what it means, when it starts or ends, etc. Sip has no notion of a half call, that can be joined to other half calls to make a full call. (Even though B2BUAs do this all the time there is no generally accepted terminology for it.) If we only discuss full e2e calls, and say that they consist of a pair of these IDs, fine. But then you start talking about relating calls based on matching just half of a pair. This starts to sound to me like it requires a sort of framework that describes these half calls assembled in various ways, how IDs are assigned and reassigned to the various pieces, and how and when pairs are formed. Thanks, Paul K > Paul > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Tuesday, March 27, 2012 5:12 PM >> To: insipid@ietf.org >> Subject: Re: [Insipid] Use case to consider >> >> Paul J, >> >> IIRC, what your draft is really proposing is that an identifier be >> assigned per call-*leg*, and that each UA keep track of its own call-leg- >> id and the call-leg-id of some other call-leg in a "session" >> with it. Maybe that is the call-leg-id of the *first* other leg in the >> session, though it could equally well be the *most recent* call-leg-id. >> And then when logging, etc. it is to record both of those call-leg-ids. >> >> In principle, I suppose a UA could keep track of more than one call-leg-id >> of other legs in its session, if it becomes aware of them. >> And then it could log whichever it has. >> >> Thanks, >> Paul K >> >> On 3/27/12 7:06 AM, Paul E. Jones wrote: >>> Hadriel, >>> >>>> 1) A lot of times we think about use-cases as having one PBX, or one >>>> App- Server, etc. But in practice there are often many in any given >> call path. >>>> For example Alice called Bob in Adam's diagram, with both Alice and >>>> Bob talking to "the" PBX. But in the real world Bob could easily be >>>> on >>>> *another* PBX. In that case, there could be a Frank who joins the >>>> call on Bob's PBX-1, or Bob could conference in Frank, etc., for the >>>> same call that Carol joined on PBX-2. In that case, what is the >>>> UUID-pair between >>>> PBX-1 and PBX-2? >>> >>> I'm having trouble following who is on PBX-1 and PBX-2, but let me >>> provide an example... >>> >>> Assuming Alice (using UUID A1) is on PBX-1 and Bob (using UUID B1) is >>> on PBX-2, then the call from Alice to Bob would have an end-to-end >>> Session-ID of (A1||B1), with the concatenation order as specified in >>> the draft or, if we wanted, with each component kept distinct. (I'm >>> not sure if it matters whether we concatenate or not, but it is >>> important that we have these distinct values.) >>> >>> Assume Frank is on PBX-3 and is brought into the conference somehow by >> Bob. >>> The "somehow" is important. Let's say Bob is in a call with Frank. >>> Then in that case, Bob has a separate call with Frank whose Session-ID >> is (B2||F1). >>> Now, if Bob "joins" the call locally on his phone, then there are >>> still two SIP sessions in progress. There is one from Bob to Alice >>> and one from Bob to Frank. Bob might be mixing media locally, but >>> these are two independent calls and nothing changed w.r.t. to the >> Session ID as a result of the join. >>> >>> If, however, Bob somehow pulled both calls into a conference hosted at >>> the PBX or an MCU, then things changed. Likely, there was a >>> conference Q created and the devices were REFERed to Q. So, there >>> would be a call from Alice to Q (A1||Q), Bob to Q (B1||Q), and Frank >>> to Q (F1||Q). B2 disappeared, since that call effectively vanished with >> the transfer. >>> >>> It is also possible that the PBX does some magic where it merges media >>> together. That's similar to the other example Hadriel asked about and >>> to which I replied. >>> >>> SIP allows for one to use very "open" signaling (like a REFER) to >>> bring calls into a conference and it's also possible that calls are >>> kept separate and media mixed such that devices are oblivious to the >>> fact that things are merged. Perhaps it's useful to ask: who would >>> respond to the BYE message should Alice send one at any point? That >>> is indicative of where the session ends from her perspective. If the >>> PBX effectively took over as the endpoint replacing Bob, for example, >>> then that's where the session ends. It's really a conference focus >> without being named as such in this example. >>> >>>> 2) As Adam said, it's extremely common for the operators of PBXes to >>>> want to hide the details of call monitoring. I'd argue it even >>>> beyond that, to say they don't even want you to know that the call >>>> moves around; for example in a call center from an IVR to an >>>> agent-queue/ACD to an agent to potentially voicemail. So does the >>>> PBX always create a virtual UUID "P", which it answers a call with by >>>> giving back to Alice "A || P", while internally inside the call >>>> center it handles the separate/moving dialogs using "P || B", "P || >>>> C", etc.? If the answer is "yes", then again as above in (1), if >>>> there are *two* PBXs, we lose the end-to-end nature of the correlator >>>> value, since the first PBX now bridges from "A || P1" to >>>> "P1 || P2", and the second PBX from "P1 || P2" to "P2 || B". I don't >>>> think that's a big deal for your intended use-cases, but for >>>> troubleshooting it's not much better than what we have now. Yet >>>> arguably it's the multi-PBX type cases that are the hardest to >> troubleshoot. >>> >>> What you describe seems to be counter to the objective of having an >>> end-to-end session identifier. Certainly, a device could have this >>> virtual "P", but that is like having an SBC today terminate a call and >>> re-originate it using different identifiers. In some of the examples >>> Hadriel was offering, I saw questions of "are we creating a conference >>> and, thus a new call, or are we just mixing media at some point for >>> calls?" Those questions have answers that yield different signaling >>> topologies and, thus, different answers to what the Session-ID is. >>> >>> So, this question of introducing "P" and the desire to hide details >>> seems to go against the objective of the work we're doing here. >>> Certainly, it could be done, but not desirable if we want to track >>> anything end-to-end. This puts the SBC at the "end", when it's actually >> in the middle. >>> >>> >>>> 3) The draft says this: "Intermediaries such as session border >>>> controllers MUST NOT change any Session Identifier component received >>>> from an endpoint in a session." Do you mean this to only apply to >>>> SBCs, or to any and all B2BUAs as well, such as PBXs? Why would an >>>> SBC vendor comply with this, if the second-half of the identifier >>>> changes as the call moves around, since SBCs are also used to hide >>>> such moving? (and yes, SBCs can also process REFERs, re-INVITEs and >>>> INVITEs-with-Replaces locally instead of passing them on) >>> >>> The "such as" was intended to mean SBCs are just one example. The >>> same would be true for a PBX. The intent was to say that an SBC >>> cannot receive a UUID "A" from an incoming call and re-write that as >>> "B" on the outgoing call. It must remain as "A". >>> >>> If we want to change the rules so that the intermediary can re-write >>> the UUID, then we lose the end-to-end property. >>> >>>> 4) It's a nit, but I don't get why the draft concatenates two UUIDs >>>> into one "value", instead of just keeping them explicitly separate >>>> values. Like with a defined separator, for example. It also violates >>>> the ABNF of "Session-ID-UUID" to concatenate two UUIDs into the >>>> single header field value, since a UUID is defined to be a fixed >>>> length. (again this is a nit, but I thought I'd mention it so you can >>>> fix the ABNF) >>> >>> I went around on this a bit, too. I could be persuaded easily to >>> change this. What I did not want is to have two headers. I wanted to >> have "value" >>> that could be efficiently compared (versus two where we have to have >>> the logic "if ((X==a)&& (Y=b)) || (X=b)&& (Y=a))" to do a >>> comparison. So, I specified an order of concatenation to produce a >>> single "value". Splitting it right down the middle re-produces the two >> individual UUIDs, of course. >>> >>> In any case, I'm open to any suggestions here that make it easier to >> use. >>> >>> Paul >>> >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >>> >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > > From paulej@packetizer.com Thu Mar 29 20:37:09 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587CE21F847B for ; Thu, 29 Mar 2012 20:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 nPQ5GZdEX88z for ; Thu, 29 Mar 2012 20:37:08 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6C721E8093 for ; Thu, 29 Mar 2012 20:36:56 -0700 (PDT) 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 q2U3as3m030363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Mar 2012 23:36:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1333078615; bh=/nMzSxVNljtiVPUPjs+IWuzPj/GHCT+ilBAJRTddB1U=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=T2TRjvsGPn6rSBlECOd/hVVtUCeIlWPF/dD9z2HZoHhR7QbYALlK0LV9nEPZBgOie DQ9GKJzzindFNttOyx+kBZNiJaE8zR8X42ZzxOs/twX5YjmJ16NEVXoYnH7Yk51qVV t9qqkAekqi86pr3OtSQ0FSDABTC/UqKWKQgnZz7A= From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <4F70797D.9070104@nostrum.com> <053d01cd0b6f$d36e29a0$7a4a7ce0$@packetizer.com> <001901cd0bd7$52dd4740$f897d5c0$@packetizer.com> <4F722D02.3050709@alum.mit.edu> <025001cd0d37$58c7bda0$0a5738e0$@packetizer.com> <4F7469D1.4050509@alum.mit.edu> In-Reply-To: <4F7469D1.4050509@alum.mit.edu> Date: Thu, 29 Mar 2012 23:37:02 -0400 Message-ID: <03d901cd0e26$5f29bf50$1d7d3df0$@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: AQG9PF4X9wHVos1Td4S5OTcTaYF+OwErs5leAjscWoACo8MgOwGwLLw+AfCKqwMBin0a4JZIIe5g Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Use case to consider X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 03:37:09 -0000 Paul, > > For a given call, there should never be more than two UUIDs to track > > (Alice's and Bob's). The remote UUID (Bob's) might change, though, > > due to service interactions (e.g., Bob transfers the call to Alice, or > > Bob's PBX merges two calls locally into one new call). Such changes > > would be noted with an INVITE (likely) coming to Alice with a new > Session-ID-UUID. > > Its here that what you say gets a bit controversial. Of course. Is anything related to SIP ever not? :-) > Your use of "call" here is pretty loose - we probably won't all agree with > what it means, when it starts or ends, etc. Sip has no notion of a half > call, that can be joined to other half calls to make a full call. > (Even though B2BUAs do this all the time there is no generally accepted > terminology for it.) Yeah, my use of call here is loose. And, while SIP has this end-to-end notion, the reality is often different. This gets us back to the definition discussion we had for a "session". I'd prefer to not use "call" since we're talking about the "session" initiation protocol... there is a session here somewhere, and it's not just a media session. > If we only discuss full e2e calls, and say that they consist of a pair of > these IDs, fine. But then you start talking about relating calls based on > matching just half of a pair. I assume you're referring to the MCU case where we're proposing that the MCU use the same UUID for all participants in a given conference? It is that case where I say we can relate calls. Don't try to complicate this with some "half call" notion. Look at it only for what it is: there is a conference and each participant in the conference has a Session-ID. The Session-ID is comprised of two components, one of which is the same value for all participants in the conference. > This starts to sound to me like it requires a sort of framework that > describes these half calls assembled in various ways, how IDs are assigned > and reassigned to the various pieces, and how and when pairs are formed. I don't think that's necessary. We're not creating and kind of new call flow or call scenario that does not already exist in the market. We should simply specify that Alice assigns a value A. Bob assigns a value B. To accommodate those call flows of which we cannot speak, Alice or Bob should be permitted to change its UUID at any time. We know it might be for reasons for which we cannot speak, but officially it would be because either Alice or Bob may change its UUID. Paul