From dean.willis@softarmor.com Mon Apr 2 10:01:40 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 27FE821F85A5 for ; Mon, 2 Apr 2012 10:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsTZw7xajB9t for ; Mon, 2 Apr 2012 10:01:39 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7F721F8598 for ; Mon, 2 Apr 2012 10:01:39 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2167390obb.31 for ; Mon, 02 Apr 2012 10:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer; bh=qJkH3WfmXgDBVp/RF7+Us2A1XKZ7SQc8SheS6Ou5kVw=; b=IOQX/ew9jxudtS5+d1W4eGaDPrVGkXs7qdnVfL5n4/h58OuYZc31IBIAHQmRCxTOkc TVMGNeF0RfRs8Isrp1k0eyBjqRuD9+C7XrzD+G8cqoLQyXMd/1soDZWE7CptsRHLbDfr SV90p8nC1TmGo735j8Zskob+C4kwceoQCpnqY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer:x-gm-message-state; bh=qJkH3WfmXgDBVp/RF7+Us2A1XKZ7SQc8SheS6Ou5kVw=; b=it4cB2OSHH8TIKCNJNc0/a1ofCPL2U9zXLHRqlESq07sn11K/DjXNbpec7MZeaMd5b vO861wjRBtJBZAWA5tgTK+K2uzaXY8cglCyqgfB9R6xTIIyXByTdcOvStKd0CZDZK5Hf i2gCrawmDqv4IhKmoj5Nkmmwo2N6S7UADYxqjz/Myxd7pgL4Al3JQhbcqFmheI77AKun /jkQ9nqP7d4KVO9ILkSYBHL2HbwUg5oNl1CNvZZBrQ10QtR+7xruJH4Yhl73hOeWBwHb +vHt0eFGFA+eLZuSAI9hz6kB9g1alqUzTY3/coA5fpv4eLQlYevy3BPp5PdbM3HbZFPg v54w== Received: by 10.182.1.104 with SMTP id 8mr13753171obl.19.1333386099014; Mon, 02 Apr 2012 10:01:39 -0700 (PDT) Received: from [192.168.2.124] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id o9sm18604626obd.21.2012.04.02.10.01.37 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 10:01:38 -0700 (PDT) From: Dean Willis Content-Type: text/plain; charset=us-ascii Message-Id: Date: Mon, 2 Apr 2012 12:01:37 -0500 To: insipid@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkwxJbT+F4cJvjskQ9tdR+4T5gLXNGEdJmkf537NeAXAiiU1lDn5MUyCf/oyGZgXOOWWW/Y Subject: [Insipid] Possible IPR related to INSIPID work 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, 02 Apr 2012 17:01:40 -0000 You might look at US patent application 11/646,982 and US patent 7983240 = (which has a number of our participants as authors) when considering = this problem space. From rjsparks@nostrum.com Wed Apr 4 11:17: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 ADF2721F866C for ; Wed, 4 Apr 2012 11:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0IdZR-Ma1KQC for ; Wed, 4 Apr 2012 11:17:23 -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 18AB621F866A for ; Wed, 4 Apr 2012 11:17:22 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q34IHKpU043103 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 4 Apr 2012 13:17:22 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <4F7C902F.8090403@nostrum.com> Date: Wed, 04 Apr 2012 13:17:19 -0500 From: Robert Sparks 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 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: Re: [Insipid] Possible IPR related to INSIPID work 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, 04 Apr 2012 18:17:23 -0000 Also, please note RjS On 4/2/12 12:01 PM, Dean Willis wrote: > You might look at US patent application 11/646,982 and US patent 7983240 (which has a number of our participants as authors) when considering this problem space. > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Wed Apr 4 11:42:56 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 DEF6511E80AD for ; Wed, 4 Apr 2012 11:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 bckBufHcjE2C for ; Wed, 4 Apr 2012 11:42:56 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4554211E80AA for ; Wed, 4 Apr 2012 11:42: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 q34IgtEm000485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 4 Apr 2012 14:42:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1333564975; bh=x4RhQsDFV4xR3ZG+2yUsAtOJruQNVK6mgrZewbi5xJU=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=OgqeTVIw2e2KSSmCpUsj8IoeF7oyxI624S7LXMsviq1njkGaY3w8ETfnMCw/Q5Unm kMD40xA73+hQ0flbwQiBjYSkKTAZ5x7Jd76ReCFFLxpWxHmY2Him8h6gGHoIo1MSQA Z5E19adkSNopSOCgkuDoGAI4i+OzEfp5SxFZqyq0= From: "Paul E. Jones" To: References: <4F7C902F.8090403@nostrum.com> In-Reply-To: <4F7C902F.8090403@nostrum.com> Date: Wed, 4 Apr 2012 14:43:02 -0400 Message-ID: <04a501cd1292$c4698fb0$4d3caf10$@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: AQFbYgU+Kk/Nn5OtQgOIT31kalSRigMT4Olxl1XCa6A= Content-Language: en-us Subject: Re: [Insipid] Possible IPR related to INSIPID work 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, 04 Apr 2012 18:42:57 -0000 And note: https://datatracker.ietf.org/ipr/1453/ > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Robert Sparks > Sent: Wednesday, April 04, 2012 2:17 PM > To: insipid@ietf.org > Subject: Re: [Insipid] Possible IPR related to INSIPID work > > Also, please note > > RjS > > On 4/2/12 12:01 PM, Dean Willis wrote: > > You might look at US patent application 11/646,982 and US patent 7983240 > (which has a number of our participants as authors) when considering this > problem space. > > > > > > _______________________________________________ > > 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 hs@123.org Thu Apr 19 02:39:31 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 54FC221F85B1 for ; Thu, 19 Apr 2012 02:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJbueOXr4Rlz for ; Thu, 19 Apr 2012 02:39:30 -0700 (PDT) Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5822021F85AF for ; Thu, 19 Apr 2012 02:39:30 -0700 (PDT) X-RZG-AUTH: :JH8HfU+kYd9xQ6m0ynnj9hHxvZXYXks+pm8dQxa2PdmCs29rNz9cViORD2RqGtwR9Q== X-RZG-CLASS-ID: mo05 Received: from [172.30.0.242] (31-18-176-221-dynip.superkabel.de [31.18.176.221]) by smtp.strato.de (klopstock mo49) (RZmta 28.1 DYNA|AUTH) with ESMTPA id Y006ado3J87WEc ; Thu, 19 Apr 2012 11:39:02 +0200 (MEST) Message-ID: <4F8FDD36.8000004@123.org> Date: Thu, 19 Apr 2012 11:39:02 +0200 From: Hendrik Scholz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: insipid@ietf.org, R.Jesske@telekom.de, paulej@packetizer.com, Hadriel Kaplan , laura.liess.dt@gmail.com, salvatore.loreto@ericsson.com, jmpolk@cisco.com, pravindran@sonusnet.com, gsalguei@cisco.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Insipid] Comments on draft-jones-insipid-session-id-reqts-00 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, 19 Apr 2012 09:39:31 -0000 Hi! Here are a few comments on the -00 version: REQ-5: I've seen Media Gateway Controllers which constructed the Call-ID using the A and B party phone numbers. Obviously this turned anonymous calls into not-so-anonymous calls. I suggest adding 'subscriber ID' and/or 'phone number' to the list of prohibited identifiers. REQ-9: An RFC 5576 (RTP SSRC) style SDP attribute would fulfill the requirement. It would require boxes to parse SDP and SDP is only present in few messages. I believe we all know that by SIP we mean 'SIP and outside SDP' but I just wanted to utter my opinion on this ;) In order to implement conferencing and transfers there might be a need to have a) multiple Session-IDs attached to a single session or b) re-negotiate the Session-ID. Sample call case: Alice calls Bob. Session-ID is 'ab'. Carol calls Dave. Session-ID is 'cd'. Scenario One: Alice (while still on the phone with Bob) calls Carol. There is a new 'ac' Session-ID. Now she joins the two 'ab' and 'ac' calls into a single conference call in which her phone is mixing audio. What would the Session ID look like? Scenario Two: Based on the previous scenario Carol now also bridges Dave (Session 'cd') into the conference. Which segments (both participant- and time-wise) should the Session-ID describe? Regards, Hendrik -- Hendrik Scholz From paulej@packetizer.com Thu Apr 19 11:41:48 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 605DC11E80AF for ; Thu, 19 Apr 2012 11:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.308, 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 tE3s3b37rCWh for ; Thu, 19 Apr 2012 11:41:47 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6216D11E809A for ; Thu, 19 Apr 2012 11:41:47 -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 q3JIfaTI013411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Apr 2012 14:41:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334860898; bh=jVE385J7mZbvYv2EdQIXq3Ee2toqBAbs3dZe1cwLwv8=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=PPKw2X7aGcP+uJuCgnM7MDhOmqi2FhplzOiD3do/IMlysdChFEPK2yeRUfnKAkK7g qX8rx2DkfgcpU/c73tp49UjTgr+yZV2/yWR4pYiVO9n0wJU/O0BwcHgx0S5v1gsqIQ /GP8KgdhCQBbparAhuQnfDVzITqU8xTHzl1DYJdY= From: "Paul E. Jones" To: "'Hendrik Scholz'" , , , "'Hadriel Kaplan'" , , , , , References: <4F8FDD36.8000004@123.org> In-Reply-To: <4F8FDD36.8000004@123.org> Date: Thu, 19 Apr 2012 14:41:56 -0400 Message-ID: <082c01cd1e5c$19fd2f20$4df78d60$@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: AQJvwVHvipuPiPklmvGQFsNOsrJw+5VdL4Jw Content-Language: en-us Subject: Re: [Insipid] Comments on draft-jones-insipid-session-id-reqts-00 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, 19 Apr 2012 18:41:48 -0000 Hendrik, > REQ-5: > I've seen Media Gateway Controllers which constructed the Call-ID using > the A and B party phone numbers. > Obviously this turned anonymous calls into not-so-anonymous calls. > I suggest adding 'subscriber ID' and/or 'phone number' > to the list of prohibited identifiers. Noting these are all example, but I certainly have no objection. I will add "Subscriber ID" to the -01 draft. > REQ-9: > An RFC 5576 (RTP SSRC) style SDP attribute would fulfill the requirement. > It would require boxes to parse SDP and SDP is only present in few > messages. > I believe we all know that by SIP we mean 'SIP and outside SDP' but I just > wanted to utter my opinion on this ;) I don't understand this one. The Session-ID is not a media-level element. In SIP, I would expect it to be carried in the SIP header and in H.323 it would be in the H.225.0 call signaling messages. Most likely, INVITE and SETUP messages, but perhaps also UPDATE and FACILITY messages. (Mixing protocols here; hopefully it's not confusing.) Requirement 9 says that whatever the Session-ID is, it's something suitable for insertion in other protocols. It does not say where we insert it. I doubt we would put it in SDP, since it is in SIP already. We might want to include it in RTCP or RSVP, though. Those are companion protocols that could potentially make use of the Session ID. > In order to implement conferencing and transfers there might be a need to > have a) multiple Session-IDs attached to a single session or b) re- > negotiate the Session-ID. If we follow the approach we propose in the draft-jones-insipid-session-id-00 draft, it would be possible for the MCU (Conference Focus) to assign the same "half" value to all participants and then each individual participant would contribute the other half. It would be immediately clear that all of the participants in a conference are somehow related, though the relationship is not clear. We do not have a requirement to define that clear relationship. When we do a transfer, we could fabricate an entirely new session ID. I'd personally like Alice to retain the value she was using, though, because this allows one to trace calls in the network. We could see, for example, that Alice was interacting with Bob and is then later interacting with Carol. I think this could aid in troubleshooting. Perhaps not, but we can certainly have that discussion. > Sample call case: > Alice calls Bob. Session-ID is 'ab'. > Carol calls Dave. Session-ID is 'cd'. > > Scenario One: > Alice (while still on the phone with Bob) calls Carol. > There is a new 'ac' Session-ID. Now she joins the two 'ab' and 'ac' calls > into a single conference call in which her phone is mixing audio. > What would the Session ID look like? If Alice calls Carol, neither would reuse 'a' or 'c'. For any new call that is initiated or any new call accepted (or even acknowledged), the calling or called endpoint MUST produce a new Session-ID-UUID. In our draft, we were only suggesting that we retain a value as a call is transferred or joined. The challenge we've had is describing this in SIP terms, but in human terms it's like this: >From the time I pick up my phone to call Bob to the time I hang up my phone call with Bob (regardless if my call to Bob got transferred or joined somehow to another call), my phone should use the same Session-ID-UUID for that call. If I put Bob on hold and place a separate call to Carol, my phone would use a different UUID, as those are two entirely separate communication sessions. The challenge we've had is that "session" is an overloaded or ill-defined term... I'm still not sure which. How can we have a "Session Initiation Protocol" if we cannot define "session" or "communication session"? :-) > Scenario Two: > Based on the previous scenario Carol now also bridges Dave (Session 'cd') > into the conference. > > Which segments (both participant- and time-wise) should the Session-ID > describe? Carol bridges Dave into what conference? You mean Carol brings together the call with her, Alice, and Dave? If so, it depends. If she transfers the call to an MCU, then I'd expect the MCU to use a UUID 'm' to each of Carol, Bob, and Dave. We'd see three session IDs. If Carol locally bridges media and mixes it, there may be two Session-IDs: one between Alice and Carol and one between Carol and Dave. Locally merging a call has no effect on session signaling, so we should not see that reflected in SIP in any way, IMO. Paul From jmpolk@cisco.com Thu Apr 19 21:59:18 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 AFBC421F86F5 for ; Thu, 19 Apr 2012 21:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.451 X-Spam-Level: X-Spam-Status: No, score=-110.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 8XA1DFkHgGnL for ; Thu, 19 Apr 2012 21:59:16 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2CC21F86F1 for ; Thu, 19 Apr 2012 21:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=5652; q=dns/txt; s=iport; t=1334897956; x=1336107556; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=F/zzT00zBXCjS73cjN996+QJvpE8E96dwfwfOfaxnTo=; b=DjKmYNJaNUpDZWXI3lXAYtDC+QNQnDX8ESWkDRacChTdgivDhvmQqAwu s5BOWcXBQwiJpibRh4RAVEvkm5ynsRR2/uw3Z9rx7rWDFaLsDu3CPxbqp NzG/iF1+zufxd4P3Mme2EFU9UIEjE9VkvcRbESc0UZnQHDkvhRJwONTiL A=; X-IronPort-AV: E=Sophos;i="4.75,451,1330905600"; d="scan'208";a="38268491" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 20 Apr 2012 04:59:16 +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 q3K4xFTQ027201; Fri, 20 Apr 2012 04:59:15 GMT Message-Id: <201204200459.q3K4xFTQ027201@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 19 Apr 2012 23:59:14 -0500 To: "Paul E. Jones" , "'Hendrik Scholz'" , , , "'Hadriel Kaplan'" , , , , , From: "James M. Polk" In-Reply-To: <082c01cd1e5c$19fd2f20$4df78d60$@packetizer.com> References: <4F8FDD36.8000004@123.org> <082c01cd1e5c$19fd2f20$4df78d60$@packetizer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Thu, 19 Apr 2012 22:10:05 -0700 Subject: Re: [Insipid] Comments on draft-jones-insipid-session-id-reqts-00 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, 20 Apr 2012 04:59:18 -0000 At 01:41 PM 4/19/2012, Paul E. Jones wrote: >Hendrik, > > > REQ-5: > > I've seen Media Gateway Controllers which constructed the Call-ID using > > the A and B party phone numbers. > > Obviously this turned anonymous calls into not-so-anonymous calls. > > I suggest adding 'subscriber ID' and/or 'phone number' > > to the list of prohibited identifiers. > >Noting these are all example, but I certainly have no objection. I will add >"Subscriber ID" to the -01 draft. > > > REQ-9: > > An RFC 5576 (RTP SSRC) style SDP attribute would fulfill the requirement. > > It would require boxes to parse SDP and SDP is only present in few > > messages. > > I believe we all know that by SIP we mean 'SIP and outside SDP' but I just > > wanted to utter my opinion on this ;) > >I don't understand this one. The Session-ID is not a media-level element. >In SIP, I would expect it to be carried in the SIP header and in H.323 it >would be in the H.225.0 call signaling messages. Most likely, INVITE and >SETUP messages, but perhaps also UPDATE and FACILITY messages. (Mixing >protocols here; hopefully it's not confusing.) > >Requirement 9 says that whatever the Session-ID is, it's something suitable >for insertion in other protocols. It does not say where we insert it. I >doubt we would put it in SDP, since it is in SIP already. We might want to >include it in RTCP or RSVP, though. Those are companion protocols that >could potentially make use of the Session ID. > > > In order to implement conferencing and transfers there might be a need to > > have a) multiple Session-IDs attached to a single session or b) re- > > negotiate the Session-ID. > >If we follow the approach we propose in the >draft-jones-insipid-session-id-00 draft, it would be possible for the MCU >(Conference Focus) to assign the same "half" value to all participants and >then each individual participant would contribute the other half. It would >be immediately clear that all of the participants in a conference are >somehow related, though the relationship is not clear. We do not have a >requirement to define that clear relationship. > >When we do a transfer, we could fabricate an entirely new session ID. I'd >personally like Alice to retain the value she was using, though, because >this allows one to trace calls in the network. We could see, for example, >that Alice was interacting with Bob and is then later interacting with >Carol. I think this could aid in troubleshooting. Perhaps not, but we can >certainly have that discussion. > > > Sample call case: > > Alice calls Bob. Session-ID is 'ab'. > > Carol calls Dave. Session-ID is 'cd'. > > > > Scenario One: > > Alice (while still on the phone with Bob) calls Carol. Hendrik this would cause the original 'a' to become 'a1' between alice and bob. then when alice calls carol, this session-id is a2-c. It all comes down to where is the media mixing, i.e., at alice's UA or at an MCU. What you described is a case of independent calls from alice to bob (a1-b) and also alice to carol (a2-b). That is different than if bob transfers alice to carol, which we prefer for alice to keep her half key for session tracking purposes (resulting in the original alice to bob (ab) becoming alice to carol (ac)). > > There is a new 'ac' Session-ID. Now she joins the two 'ab' and 'ac' calls > > into a single conference call in which her phone is mixing audio. > > What would the Session ID look like? > >If Alice calls Carol, neither would reuse 'a' or 'c'. For any new call that >is initiated or any new call accepted (or even acknowledged), the calling or >called endpoint MUST produce a new Session-ID-UUID. In our draft, we were >only suggesting that we retain a value as a call is transferred or joined. >The challenge we've had is describing this in SIP terms, but in human terms >it's like this: > > From the time I pick up my phone to call Bob to the time I hang up my phone >call with Bob (regardless if my call to Bob got transferred or joined >somehow to another call), my phone should use the same Session-ID-UUID for >that call. If I put Bob on hold and place a separate call to Carol, my >phone would use a different UUID, as those are two entirely separate >communication sessions. > >The challenge we've had is that "session" is an overloaded or ill-defined >term... I'm still not sure which. How can we have a "Session Initiation >Protocol" if we cannot define "session" or "communication session"? :-) > > > Scenario Two: > > Based on the previous scenario Carol now also bridges Dave (Session 'cd') > > into the conference. where is the media mixing? if at carol's UA, then there are two independent calls or sessions with different session-ids, (ac) and (cd). if in an MCU alice's half key would marry with the MCU's half key for that conference (am), carol's session-id would become (cm), and dave's would be (dm). > > > > Which segments (both participant- and time-wise) should the Session-ID > > describe? > >Carol bridges Dave into what conference? You mean Carol brings together the >call with her, Alice, and Dave? > >If so, it depends. If she transfers the call to an MCU, then I'd expect the >MCU to use a UUID 'm' to each of Carol, Bob, and Dave. We'd see three >session IDs. > >If Carol locally bridges media and mixes it, there may be two Session-IDs: >one between Alice and Carol and one between Carol and Dave. Locally merging >a call has no effect on session signaling, so we should not see that >reflected in SIP in any way, IMO. > >Paul From pkyzivat@alum.mit.edu Fri Apr 20 07:26:02 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 1924D21F86EC for ; Fri, 20 Apr 2012 07:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 0cpXPoYSImI3 for ; Fri, 20 Apr 2012 07:26:01 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7C821F86E8 for ; Fri, 20 Apr 2012 07:26:00 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta07.westchester.pa.mail.comcast.net with comcast id 0Bhx1j0011ZXKqc57ES11G; Fri, 20 Apr 2012 14:26:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id 0ES01j00j07duvL3hES0Gq; Fri, 20 Apr 2012 14:26:01 +0000 Message-ID: <4F9171F7.9050308@alum.mit.edu> Date: Fri, 20 Apr 2012 10:25:59 -0400 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: insipid@ietf.org References: <4F8FDD36.8000004@123.org> <082c01cd1e5c$19fd2f20$4df78d60$@packetizer.com> <201204200459.q3K4xFTQ027201@mtv-core-4.cisco.com> In-Reply-To: <201204200459.q3K4xFTQ027201@mtv-core-4.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] Comments on draft-jones-insipid-session-id-reqts-00 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, 20 Apr 2012 14:26:02 -0000 On 4/20/12 12:59 AM, James M. Polk wrote: > At 01:41 PM 4/19/2012, Paul E. Jones wrote: >> > Scenario One: >> > Alice (while still on the phone with Bob) calls Carol. > > Hendrik > > this would cause the original 'a' to become 'a1' between alice and bob. > then when alice calls carol, this session-id is a2-c. It all comes down > to where is the media mixing, i.e., at alice's UA or at an MCU. What you > described is a case of independent calls from alice to bob (a1-b) and > also alice to carol (a2-b). That is different than if bob transfers > alice to carol, which we prefer for alice to keep her half key for > session tracking purposes (resulting in the original alice to bob (ab) > becoming alice to carol (ac)). > >> > There is a new 'ac' Session-ID. Now she joins the two 'ab' and 'ac' >> calls >> > into a single conference call in which her phone is mixing audio. >> > What would the Session ID look like? >> >> If Alice calls Carol, neither would reuse 'a' or 'c'. For any new call >> that >> is initiated or any new call accepted (or even acknowledged), the >> calling or >> called endpoint MUST produce a new Session-ID-UUID. In our draft, we were >> only suggesting that we retain a value as a call is transferred or >> joined. If an INVITE/replaces is accepted, are you proposing that the half-id from the replaced call be reused? >> The challenge we've had is describing this in SIP terms, but in human >> terms >> it's like this: >> >> From the time I pick up my phone to call Bob to the time I hang up my >> phone >> call with Bob (regardless if my call to Bob got transferred or joined >> somehow to another call), my phone should use the same Session-ID-UUID >> for >> that call. If I put Bob on hold and place a separate call to Carol, my >> phone would use a different UUID, as those are two entirely separate >> communication sessions. The problem with the latter is that there are two different scenarios covered by this case: - You complete the call with Carol, end it, and resume the call with Bob. It makes sense that the two calls a labeled differently. - You verify that Carol is available, fill her in on what you have been discussing with Bob, and then join the two calls into a conference. You would probably prefer that your end of both calls be labeled the same. If your UI is structured so that your phone knows, at the time you initiate the call to Carol, that you intend to form a conference, or not, then it could do the "right" thing in both cases. But there are common examples where this is not known at the time the call to Carol is initiated. (You might not even know yet.) If so, then it becomes impossible to satisfy both cases. >> The challenge we've had is that "session" is an overloaded or ill-defined >> term... I'm still not sure which. How can we have a "Session Initiation >> Protocol" if we cannot define "session" or "communication session"? :-) IMO its *both* overloaded and ill-defined. :-) The solution is to recognize this and either avoid the word entirely, or else always use it with a qualifying adjective. >> > Scenario Two: >> > Based on the previous scenario Carol now also bridges Dave (Session >> 'cd') >> > into the conference. > > where is the media mixing? Why does it matter? > if at carol's UA, then there are two independent calls or sessions with > different session-ids, (ac) and (cd). ISTM you are confusing your assumed mechanism with the intended result. Thanks, Paul From hs@123.org Mon Apr 23 02:52:26 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 A84AC21F85B4 for ; Mon, 23 Apr 2012 02:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 F3nCondjkp9H for ; Mon, 23 Apr 2012 02:52:26 -0700 (PDT) Received: from mo6-p05-ob.rzone.de (mo6-p05-ob.rzone.de [IPv6:2a01:238:20a:202:5305::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F2721F855B for ; Mon, 23 Apr 2012 02:52:25 -0700 (PDT) X-RZG-AUTH: :JH8HfU+kYd9xQ6m0ynnj9hHxvZXYXks+pm8dQxa2PdmCs29qNyJDXGPSHqedfmnO X-RZG-CLASS-ID: mo05 Received: from [192.168.1.207] ([213.218.5.34]) by smtp.strato.de (jored mo100) (RZmta 28.12 DYNA|AUTH) with ESMTPA id l030e3o3N9fpYx for ; Mon, 23 Apr 2012 11:52:18 +0200 (CEST) Message-ID: <4F952652.6040508@123.org> Date: Mon, 23 Apr 2012 11:52:18 +0200 From: Hendrik Scholz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <4F8FDD36.8000004@123.org> <082c01cd1e5c$19fd2f20$4df78d60$@packetizer.com> <201204200459.q3K4xFTQ027201@mtv-core-4.cisco.com> <4F9171F7.9050308@alum.mit.edu> In-Reply-To: <4F9171F7.9050308@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] Comments on draft-jones-insipid-session-id-reqts-00 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, 23 Apr 2012 09:52:26 -0000 Hi, thanks for all the input. The requirements document did not state that the construction of the Session-ID must be based on the UUID from both endpoints. That's what made it confusing. I'll read the implementation description and will come back if there are any open questions. Hendrik -- Hendrik Scholz From paulej@packetizer.com Mon Apr 23 07:29: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 227DC21F86A0 for ; Mon, 23 Apr 2012 07:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 PnslJfotgEPR for ; Mon, 23 Apr 2012 07:29:08 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 62ED721F869E for ; Mon, 23 Apr 2012 07:29:08 -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 q3NET3gl009657 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Apr 2012 10:29:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335191344; bh=lX6OTE5At8FzOaxkUlxyubcLGl9tN5oERbWNSaZpBsA=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=f7Cozrw3NRguR6DRDkIHN+0mHZ404wKmXOqYIFWCaHtjgtrVrKBVV7+TF7Hm55woo uXiAieuIOfz0dJLj2fB3ERQ4QeJg8MlLd4GBriGPqa8PuIS3bDAd4SQPeihSUcit+x +6H50n9Ujug34DvgBb/ASzZ8H5zEdM8yirRAjiWE= From: "Paul E. Jones" To: "'Hendrik Scholz'" , References: <4F8FDD36.8000004@123.org> <082c01cd1e5c$19fd2f20$4df78d60$@packetizer.com> <201204200459.q3K4xFTQ027201@mtv-core-4.cisco.com> <4F9171F7.9050308@alum.mit.edu> <4F952652.6040508@123.org> In-Reply-To: <4F952652.6040508@123.org> Date: Mon, 23 Apr 2012 10:29:06 -0400 Message-ID: <013501cd215d$70ccaf70$52660e50$@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: AQJvwVHvipuPiPklmvGQFsNOsrJw+wIDHq2YAfZ5H/sCa2srIAImB6VBlR7fpwA= Content-Language: en-us Subject: Re: [Insipid] Comments on draft-jones-insipid-session-id-reqts-00 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, 23 Apr 2012 14:29:09 -0000 Hendrik, Hopefully I did not confuse you further. The requirements document does not mention UUIDs since that is one proposed solution, not a requirement. The requirements should, indeed, stand on their own independent of a particular solution. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Hendrik Scholz > Sent: Monday, April 23, 2012 5:52 AM > To: insipid@ietf.org > Subject: Re: [Insipid] Comments on draft-jones-insipid-session-id-reqts-00 > > Hi, > > thanks for all the input. The requirements document did not state that the > construction of the Session-ID must be based on the UUID from both > endpoints. That's what made it confusing. > > I'll read the implementation description and will come back if there are > any open questions. > > Hendrik > > -- > Hendrik Scholz > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From laura.liess.dt@googlemail.com Thu Apr 26 06:50: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 7CA2421F86D8 for ; Thu, 26 Apr 2012 06:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 hnbgdb2zqnRo for ; Thu, 26 Apr 2012 06:50:03 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB5921F86D4 for ; Thu, 26 Apr 2012 06:50:03 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so5430562wib.1 for ; Thu, 26 Apr 2012 06:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=87LiNiVMFNUxbhkOUuovNbbEZU5BP7yx9UHl3O3YS+A=; b=H8MAl8eA+8vnjpqCeGZZRMqW6TvYtk/alSYQZxOFxwPO4EU5NHmIWJIZrz0gIuawrX dgtjjI1e84yPnpgl0JLo6gl05fpSfHtPEdg6pCsBTS1pni6dUKsiE9u6omrbHf6+c/N7 y+NqjpBsOHExb5tUfSBgesn1cHHeAvQ6M0cbmR5jWq7bR72cEkOCEU7otdfYz+m/jGYN 9d+YBG9WbdVqRNu2OHwBnX70l56kY4dxGnUzoi5fJI598yLG9nHpjHisNGsN/KxW6w94 yql3j7GOG2Clo+UKsJSn7bQG4wcJOzTQ/tayyNnbvQgCTdwqYGlnDhjXMQJq54q+E/B/ 50WQ== MIME-Version: 1.0 Received: by 10.216.139.25 with SMTP id b25mr4130855wej.41.1335448202596; Thu, 26 Apr 2012 06:50:02 -0700 (PDT) Received: by 10.227.205.195 with HTTP; Thu, 26 Apr 2012 06:50:02 -0700 (PDT) Date: Thu, 26 Apr 2012 15:50:02 +0200 Message-ID: From: Laura Liess To: "insipid@ietf.org" , Paul Jones , Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Cc: =?UTF-8?Q?Martin_H=C3=BClsemann?= Subject: [Insipid] Comment on REQ1, REQ6 and REQ7 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, 26 Apr 2012 13:50:04 -0000 Hi, What is the reason for having REQ6? Do we realy need it? It seems to me that it will be difficult to fulfill all REQ1 and REQ6 and REQ7 at the same time. Take the following scenario: ----------- ------------- ----------- | A | ---------Call-ID x---------------------->| B2BUA |-------------Call-ID y------->| AS |-------- ----------- ------------- Session-ID z ----------- A is an end device that does not support Session-ID. AS is an Application Server and in the context of REQ6 the receiver of the Session-ID. The B2BUA changes the Call-ID from x to y and calculates a Session-ID z. By REQ1 and REQ7, an external device monitoring the SIP-traffic must be able to find out that messages with the Call-ID x and messages with the Session-ID z belong to the same session. So the B2BUA must build z as a function of x, let's say z =F(x) and the monitoring the B2BUA and the monitoring system have to know F. Otherwise, by REQ6, the AS is not allowed to know F, otherwise he is able to find out that z /= F(y). Maybe it is in theoreticaly possible for a network to have a for each node a different F and the the monitoring systems knowing which F to use for a call leg, but in practice this is probably too complex. Thanks, Laura From paulej@packetizer.com Thu Apr 26 10:48: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 709E021E8028 for ; Thu, 26 Apr 2012 10:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OulM1HqodLah for ; Thu, 26 Apr 2012 10:48:00 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 971D421E8092 for ; Thu, 26 Apr 2012 10:48:00 -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 q3QHluZ1009847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Apr 2012 13:47:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335462477; bh=LPrnki93wzmb3fKOIGLccE+2HDrUxPJZajdYQB3Dh6c=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=gVwpMNihOGxfjEwNqKW0AqLm6tN8rlNzI2j2ildnNI1zu13pzuJx/iFVL6GkEwOSs 782MlAe/4LCps6SoT+i6re+DNjqbQgaD6/paJEx/+oCIVxl64KD6sEOfELq8OJs0c6 2mm0ZmZy1N3WlyE9EqzOu55kOdCBGaZ1q2zslasM= From: "Paul E. Jones" To: "'Laura Liess'" , , "'Hadriel Kaplan'" References: In-Reply-To: Date: Thu, 26 Apr 2012 13:48:06 -0400 Message-ID: <06bb01cd23d4$bcd5a790$3680f6b0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGIzDIhPrSRnsgS3fDRFNQsoMNSP5c2DIYg Content-Language: en-us Cc: =?utf-8?Q?'Martin_H=C3=BClsemann'?= Subject: Re: [Insipid] Comment on REQ1, REQ6 and REQ7 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, 26 Apr 2012 17:48:01 -0000 Laura, I assume the desire for REQ6 relates to ensuring the kind of privacy = that is afforded by SBCs. They can hide network topologies, peering = relations, etc. This requirements suggests that we do not want those = things disclosed via the Session-ID. REQ7 is a means of assigning an ID when the endpoint does not. That = would perhaps mean one cannot inspect all the way to the endpoint, but = one can at least track sessions to the assigning element. REQ1 seems conflicting on the surface, but one may not always have = access into every segment everywhere. Those topologies and business = relationships remain hidden. Even so, it's possible to perhaps have = multiple people and organizations talking about the same Session-ID, = regardless of what other data is changed. In short, I don't think it matters if something can determine changes = made by the B2BUA if it's that something is in a position to do so = (e.g., has physical access to all network segments), but the AS should = not be able to see that Carrier A peered with Carrier B or some such or = that the caller is using Mobile Operator C. Paul > -----Original Message----- > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > Sent: Thursday, April 26, 2012 9:50 AM > To: insipid@ietf.org; Paul Jones; Hadriel Kaplan > Cc: Martin H=C3=BClsemann > Subject: Comment on REQ1, REQ6 and REQ7 >=20 > Hi, >=20 > What is the reason for having REQ6? Do we realy need it? It seems to = me > that it will be difficult to fulfill all REQ1 and REQ6 and REQ7 at the > same time. >=20 > Take the following scenario: >=20 > ----------- > ------------- ----------- > | A | ---------Call-ID x---------------------->| B2BUA > |-------------Call-ID y------->| AS |-------- > ----------- > ------------- Session-ID z ----------- >=20 > A is an end device that does not support Session-ID. AS is an = Application > Server and in the context of REQ6 the receiver of the Session-ID. The > B2BUA changes the Call-ID from x to y and calculates a Session-ID z. > By REQ1 and REQ7, an external device monitoring the SIP-traffic must = be > able to find out that messages with the Call-ID x and messages with = the > Session-ID z belong to the same session. So the B2BUA must build z as = a > function of x, let's say z =3DF(x) and the monitoring the B2BUA and = the > monitoring system have to know F. > Otherwise, by REQ6, the AS is not allowed to know F, otherwise he is = able > to find out that z /=3D F(y). > Maybe it is in theoreticaly possible for a network to have a for each = node > a different F and the the monitoring systems knowing which F to use = for a > call leg, but in practice this is probably too complex. >=20 > Thanks, > Laura From jmpolk@cisco.com Thu Apr 26 13:06:51 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 7D89721F87A1 for ; Thu, 26 Apr 2012 13:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 QcnwDbncJsDL for ; Thu, 26 Apr 2012 13:06:50 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6D84B21F87A0 for ; Thu, 26 Apr 2012 13:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=797; q=dns/txt; s=iport; t=1335470810; x=1336680410; h=message-id:date:to:from:subject:mime-version; bh=fXymYtNHX+B7Pu3CUjAzP/WXjNNPLckeEHBqkScvIho=; b=FLmTGvd08KnD0NgylhlB0Ki/YBApAjdO0/oVkbyLpQ7YlHYVCeKSlSWA cMXIUKT4ZXZTbY/x3Zf6t5LMmY5SIrHpTuF6YTndTfEXpE4yEniIIVTyZ 8ezycyGlzvWwJwxX3vOAzSCa23UGbL4avW8c18iwTUxBVl9jpt2lhg4jn 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHupmU+rRDoI/2dsb2JhbAA7CgGxb4EHgiIBJQIuKDopRBwZh2oMmSyBKKAdinmFbASIY5txgWmDBg X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="39211699" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 26 Apr 2012 20:06:50 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3QK6n7b027203 for ; Thu, 26 Apr 2012 20:06:49 GMT Message-Id: <201204262006.q3QK6n7b027203@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Apr 2012 15:03:04 -0500 To: "insipid@ietf.org" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] INSIPID Req#3 - comments? 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, 26 Apr 2012 20:06:52 -0000 Figure it is about time I sent these requirements out to the list. Comments, questions and wordsmithing are encouraged. Let's see if we can leave much of the wordsmithing till the end of the discussion, once we have agreed on the requirement's worthiness and contents. Let's also keep the discussion on *this* thread to just *this* requirement for tracking purposes. There are 9 current requirements. Therefore, there will be 9 different messages sent to this list. Here is REQ#3 as currently written in http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id-reqts-00.txt REQ3: It must be possible to identify all sessions participating in a multipoint or multi-party conference by observing the end-to-end session identifiers of each session. From jmpolk@cisco.com Thu Apr 26 13:06: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 A733021F87AA for ; Thu, 26 Apr 2012 13:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.497 X-Spam-Level: X-Spam-Status: No, score=-110.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 PrJOUpQP-sNQ for ; Thu, 26 Apr 2012 13:06:55 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 21E5E21F87A5 for ; Thu, 26 Apr 2012 13:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=915; q=dns/txt; s=iport; t=1335470815; x=1336680415; h=message-id:date:to:from:subject:mime-version; bh=DvQ/+oiUCSLqpvG4jogJqQ0PQASepeE4R++hJcEXRGM=; b=OBK2ZOMdcXzbDDQfn/MPE9O5nvUHC80J46PcPaNYeZX/E2e3oC0fetot ZKpokPcAX4BXPh6cpgucnjDvEkeQZmXnLLGWf/ONr+q/vIHqheFz8p2Gx dFZIt0fQi7LzjgsHd+sZyg03oYkfQtfXv6TIef5ZEy0nas+YQkRCdbtT3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFALKqmU+rRDoI/2dsb2JhbAA7CgGoZ4kIgQeCIgElAjgeOilEHBmHagyZKYEooB+KeYVsBIhjm3GBaYMG X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="42234293" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 26 Apr 2012 20:06:42 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3QK6fTr027133 for ; Thu, 26 Apr 2012 20:06:42 GMT Message-Id: <201204262006.q3QK6fTr027133@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Apr 2012 15:01:37 -0500 To: "insipid@ietf.org" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] INSIPID Req#1 - comments? 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, 26 Apr 2012 20:06:55 -0000 Figure it is about time I sent these requirements out to the list. Comments, questions and wordsmithing are encouraged. Let's see if we can leave much of the wordsmithing till the end of the discussion, once we have agreed on the requirement's worthiness and contents. Let's also keep the discussion on *this* thread to just *this* requirement for tracking purposes. There are 9 current requirements. Therefore, there will be 9 different messages sent to this list. Here is REQ#1 as currently written in http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id-reqts-00.txt REQ1: It must be possible for an administrator or an external device which monitors the SIP-traffic to use the identifier to identify a set of dialogs which have a relationship with each other, such that they represent the same SIP session, with as high a probability as possible. From jmpolk@cisco.com Thu Apr 26 13:06: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 C624121F87A5 for ; Thu, 26 Apr 2012 13:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.503 X-Spam-Level: X-Spam-Status: No, score=-110.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 2A0iJUglS9KQ for ; Thu, 26 Apr 2012 13:06:55 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 33F7721F87A7 for ; Thu, 26 Apr 2012 13:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=795; q=dns/txt; s=iport; t=1335470815; x=1336680415; h=message-id:date:to:from:subject:mime-version; bh=0Uc0MQQ4Zn0GAI4BLSSjfJ6szs2iAY6z5UlWqQyNq/4=; b=WJwx3d7RLFLztJQ2Q+hsgpwiQGXK20WQc1KR1hiUMexfBiUvoo3JACF4 ACxDSpWFwSTy9sSUmI0XAze3fiGTT1mmLbMgxvT0bKItt2YoZhQ8ZadAz JhjjUodRq0Lt3UXdVXbJ6QzcW6TpdhMvwR3oDvdSbDzAjIUJhT7UtufDt 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALKqmU+rRDoJ/2dsb2JhbAA7CgGxb4EHgiIBJQJWOilEChIZh2oMmSmBKKAfinmFCWMEiGObcYFpgwY X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="42234298" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 26 Apr 2012 20:06:45 +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 q3QK6isF007654 for ; Thu, 26 Apr 2012 20:06:45 GMT Message-Id: <201204262006.q3QK6isF007654@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Apr 2012 15:02:11 -0500 To: "insipid@ietf.org" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] INSIPID Req#2 - comments? 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, 26 Apr 2012 20:06:56 -0000 Figure it is about time I sent these requirements out to the list. Comments, questions and wordsmithing are encouraged. Let's see if we can leave much of the wordsmithing till the end of the discussion, once we have agreed on the requirement's worthiness and contents. Let's also keep the discussion on *this* thread to just *this* requirement for tracking purposes. There are 9 current requirements. Therefore, there will be 9 different messages sent to this list. Here is REQ#2 as currently written in http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id-reqts-00.txt REQ2: It must be possible to identify the end-to-end session when a session is transferred or if two different sessions are joined together via an intermediary (e.g., a PBX). From jmpolk@cisco.com Thu Apr 26 13:06:56 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 9AF3521F87A5 for ; Thu, 26 Apr 2012 13:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.509 X-Spam-Level: X-Spam-Status: No, score=-110.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 2XTl3c8YsVb1 for ; Thu, 26 Apr 2012 13:06:56 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0A24021F87A7 for ; Thu, 26 Apr 2012 13:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=718; q=dns/txt; s=iport; t=1335470816; x=1336680416; h=message-id:date:to:from:subject:mime-version; bh=btWJvVsSyqktyoKbaTtR9DQZwR+NHqnAlp2DPsJ/XxU=; b=l7TVLYn+FeLExEOoD3KrAFinkjp1O5xwmstvTJMNtkr2Tq0LbL9Argl2 p4mH8Hbyoyp/cdQfjXy7mAJ2MtsGklrm6Fott+2TKM+/hFE2jKcntos6i 42/hxok+1rKUM8Hagh2X5X0YK0kabSoAMVBDFWJi3Vwqx3v6+Ry0M3Gqy Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHupmU+rRDoJ/2dsb2JhbABFAbFvgQeCIgElAlY6KUQcGYdqDJksgSigHZBlBIhjm3GBaYMG X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="39211712" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 26 Apr 2012 20:06:55 +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 q3QK6tXa007754 for ; Thu, 26 Apr 2012 20:06:55 GMT Message-Id: <201204262006.q3QK6tXa007754@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Apr 2012 15:03:30 -0500 To: "insipid@ietf.org" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] INSIPID Req#4 - comments? 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, 26 Apr 2012 20:06:56 -0000 Figure it is about time I sent these requirements out to the list. Comments, questions and wordsmithing are encouraged. Let's see if we can leave much of the wordsmithing till the end of the discussion, once we have agreed on the requirement's worthiness and contents. Let's also keep the discussion on *this* thread to just *this* requirement for tracking purposes. There are 9 current requirements. Therefore, there will be 9 different messages sent to this list. Here is REQ#4 as currently written in http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id-reqts-00.txt REQ4: It must be possible to pass the identifier unchanged through SIP B2BUAs or other intermediaries. From jmpolk@cisco.com Thu Apr 26 13:07: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 C12C821F87AE for ; Thu, 26 Apr 2012 13:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 d9cGDlWv3Tft for ; Thu, 26 Apr 2012 13:07:01 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BD83921F87A3 for ; Thu, 26 Apr 2012 13:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=857; q=dns/txt; s=iport; t=1335470820; x=1336680420; h=message-id:date:to:from:subject:mime-version; bh=Ri/CFheszIBAuUxVG3aLkZOmmNTtokrMAmJbpKXIDBQ=; b=k40gLtksyn9A+82GOmfvXyPB0EUuyuWFOzuQMxQB6NqkBzbXfQ3yVyUP 2/dcxEYGpUDBWCdOoMCKOpogXRkdVs/W0G2iZa4e3Jhp5Pe0Vf/9H2lB7 Qxgiw1zOHHE3JDB11qSIY3I7TkEJB17PvaUFdQRjvkjgTB+403jPSWbxX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHupmU+rRDoI/2dsb2JhbAA8CQGxb4EHgiIBJQJWOilEHBmHagyZLIEooB2KeoVrBIhjm3GBaYMG X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="39211716" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 26 Apr 2012 20:07:00 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3QK70XR027317 for ; Thu, 26 Apr 2012 20:07:00 GMT Message-Id: <201204262007.q3QK70XR027317@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Apr 2012 15:04:08 -0500 To: "insipid@ietf.org" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] INSIPID Req#5 - comments? 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, 26 Apr 2012 20:07:02 -0000 Figure it is about time I sent these requirements out to the list. Comments, questions and wordsmithing are encouraged. Let's see if we can leave much of the wordsmithing till the end of the discussion, once we have agreed on the requirement's worthiness and contents. Let's also keep the discussion on *this* thread to just *this* requirement for tracking purposes. There are 9 current requirements. Therefore, there will be 9 different messages sent to this list. Here is REQ#5 as currently written in http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id-reqts-00.txt REQ5: The identifier must not reveal any information related to any SIP device or domain identity, including IP Address, port, hostname, domain name, username, Address-of-Record, MAC address, IP address family, transport type, etc. From jmpolk@cisco.com Thu Apr 26 13:07:05 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 CD67B21F87B8 for ; Thu, 26 Apr 2012 13:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.518 X-Spam-Level: X-Spam-Status: No, score=-110.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 yIVUnT4jMo6o for ; Thu, 26 Apr 2012 13:07:05 -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 45F4321F87B4 for ; Thu, 26 Apr 2012 13:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=822; q=dns/txt; s=iport; t=1335470825; x=1336680425; h=message-id:date:to:from:subject:mime-version; bh=t5XopRb/44oL8kgP2JtzwlAVx5la/zgrhLM+XaHOgOM=; b=jk27VHJp39zyzr5vQxhIKMn94ufB3nO1UJY11t1rfBkHG3YqRJMJsz/G FABeRctgqFArlL2UAg8zrY7GAUKNQJ4q2i4/GIrukEjSUM1EJZ08F48iJ TEMMbmHS+sRSPbRoRR+Ho3UDAAuYndnT4E34iNGM2AwdJx/x/7QBOhp37 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAB+qmU+rRDoJ/2dsb2JhbABFAbFvgQeCIgElAlY6KUQcGYdqDJkqgSigHZBlBIhjm3GBaYMG X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="39750213" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 26 Apr 2012 20:07:05 +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 q3QK73AU007837 for ; Thu, 26 Apr 2012 20:07:04 GMT Message-Id: <201204262007.q3QK73AU007837@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Apr 2012 15:04:42 -0500 To: "insipid@ietf.org" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] INSIPID Req#6 - comments? 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, 26 Apr 2012 20:07:06 -0000 Figure it is about time I sent these requirements out to the list. Comments, questions and wordsmithing are encouraged. Let's see if we can leave much of the wordsmithing till the end of the discussion, once we have agreed on the requirement's worthiness and contents. Let's also keep the discussion on *this* thread to just *this* requirement for tracking purposes. There are 9 current requirements. Therefore, there will be 9 different messages sent to this list. Here is REQ#6 as currently written in http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id-reqts-00.txt REQ6: The identifier must not reveal to the receiver of it that the Call-ID, tags, or any other SIP header or body portion have been changed by middleboxes, with as high a probability as possible. From jmpolk@cisco.com Thu Apr 26 13:07: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 2110021F87B4 for ; Thu, 26 Apr 2012 13:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.522 X-Spam-Level: X-Spam-Status: No, score=-110.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 mRqJzFUXyi+0 for ; Thu, 26 Apr 2012 13:07:08 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9436721F87A5 for ; Thu, 26 Apr 2012 13:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=871; q=dns/txt; s=iport; t=1335470828; x=1336680428; h=message-id:date:to:from:subject:mime-version; bh=fDdONNEUZTWkXnUFZjmccO0U7u1aLkTfzQItGQkA56o=; b=adHthGqYmdXUZZus38W0qIUkFOYdEhjh08XVaeovyYV/veY2lBfMoyVO Q6CFRRcIsiNmrGhgYSddJhoMyEm7+NAbweJvOqnL5qkahizEhF8KAIJXE iv2vEOQEeEyXszgMZDtXAGpucM92Yx7BjEYL6heX8Q/cYZr3tWNNe6bAS w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALKqmU+rRDoJ/2dsb2JhbAA8CQGxb4EHgiIBJQJWOilEHBmHagyZKYEooB+KeoVrBIhjm3GBaYMG X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="42234342" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 26 Apr 2012 20:07:08 +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 q3QK77W4007875 for ; Thu, 26 Apr 2012 20:07:08 GMT Message-Id: <201204262007.q3QK77W4007875@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Apr 2012 15:05:26 -0500 To: "insipid@ietf.org" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] INSIPID Req#7 - comments? 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, 26 Apr 2012 20:07:13 -0000 Figure it is about time I sent these requirements out to the list. Comments, questions and wordsmithing are encouraged. Let's see if we can leave much of the wordsmithing till the end of the discussion, once we have agreed on the requirement's worthiness and contents. Let's also keep the discussion on *this* thread to just *this* requirement for tracking purposes. There are 9 current requirements. Therefore, there will be 9 different messages sent to this list. Here is REQ#7 as currently written in http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id-reqts-00.txt REQ7: It must be possible to identity SIP traffic with an end-to-end session identifier from and to end devices that do not support this new identifier, such as by allowing an intermediary to inject an identifier into the session signaling. From jmpolk@cisco.com Thu Apr 26 13:07: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 EC74F21F87A0 for ; Thu, 26 Apr 2012 13:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.525 X-Spam-Level: X-Spam-Status: No, score=-110.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 lVEt+Ka2qSHR for ; Thu, 26 Apr 2012 13:07:12 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC7A21F87AD for ; Thu, 26 Apr 2012 13:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=696; q=dns/txt; s=iport; t=1335470830; x=1336680430; h=message-id:date:to:from:subject:mime-version; bh=BWDV3dW0mGHB3CeJpI0pVMUSTTfe2JAJd/jeX4nupgY=; b=B3Xy+UAUM3JBNLxAwOvhXWgeGiZTHd2oWGaG6EXipWWB48rilX+vd4eu TVYX8KzKaZlTTNafm4o1tdh75UbbRDliTED1WJ9flgI0gZ/f+PpltTgpY FWkT5DAtxGTi0TMUmNaOhGnDqZUmeBXIrz/r8nMulcqoOyotJl53Su8ka s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALKqmU+rRDoI/2dsb2JhbABFAbFvgQeCIgElAlY6KUQcGYdqDJkpgSigH5ACYwSIY5txgWmDBg X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="42234346" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 26 Apr 2012 20:07:10 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3QK79oC027453 for ; Thu, 26 Apr 2012 20:07:09 GMT Message-Id: <201204262007.q3QK79oC027453@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Apr 2012 15:05:50 -0500 To: "insipid@ietf.org" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] INSIPID Req#8 - comments? 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, 26 Apr 2012 20:07:13 -0000 Figure it is about time I sent these requirements out to the list. Comments, questions and wordsmithing are encouraged. Let's see if we can leave much of the wordsmithing till the end of the discussion, once we have agreed on the requirement's worthiness and contents. Let's also keep the discussion on *this* thread to just *this* requirement for tracking purposes. There are 9 current requirements. Therefore, there will be 9 different messages sent to this list. Here is REQ#8 as currently written in http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id-reqts-00.txt REQ8: The identifier should be unique in time and space, similar to the Call-ID. From jmpolk@cisco.com Thu Apr 26 13:08:14 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 31CE221F87A2 for ; Thu, 26 Apr 2012 13:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.528 X-Spam-Level: X-Spam-Status: No, score=-110.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 yj+O9wxtsPmw for ; Thu, 26 Apr 2012 13:08:13 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id B52E921F87AE for ; Thu, 26 Apr 2012 13:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=756; q=dns/txt; s=iport; t=1335470893; x=1336680493; h=message-id:date:to:from:subject:mime-version; bh=e3JaNsQNmt2m9WSC4AG+JFKK0u8+1O5FJfOwAMFaPAk=; b=kO/sJA9O2b39hmVpjE2oueL2qVOmL7hpgkvGkjmOnbHPeX3vqSey+prt ptwqbrUls4qvq0uBC9oIDV2LMpr4O8GSKmqEATRxu0ydQsdQupGHFO67N HOOjUgoSMzKxDkrG3lmyUe+SVSKBuMZ1e7mxidPqdzGBm7hKMgS2gCg/D M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHupmU+rRDoI/2dsb2JhbABFAbFvgQeCIgElAlY6KUQcGYdqDJksgSigHZBlBIhjm3GBaYMG X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="39211746" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 26 Apr 2012 20:07:12 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3QK7CO2027512 for ; Thu, 26 Apr 2012 20:07:12 GMT Message-Id: <201204262007.q3QK7CO2027512@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Apr 2012 15:06:25 -0500 To: "insipid@ietf.org" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] INSIPID Req#9 - comments? 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, 26 Apr 2012 20:08:14 -0000 Figure it is about time I sent these requirements out to the list. Comments, questions and wordsmithing are encouraged. Let's see if we can leave much of the wordsmithing till the end of the discussion, once we have agreed on the requirement's worthiness and contents. Let's also keep the discussion on *this* thread to just *this* requirement for tracking purposes. There are 9 current requirements. Therefore, there will be 9 different messages sent to this list. Here is REQ#9 as currently written in http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id-reqts-00.txt REQ9: The identifier should be constructed in such a way as to make it suitable for transmission in SIP, H.323, RSVP [3], and RTCP [4]. From pkyzivat@alum.mit.edu Thu Apr 26 13:59: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 A6C3A21E8157 for ; Thu, 26 Apr 2012 13:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 bwiJyvQwIa-1 for ; Thu, 26 Apr 2012 13:59:01 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 078B621E80CF for ; Thu, 26 Apr 2012 13:59:00 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta07.westchester.pa.mail.comcast.net with comcast id 2knk1j00W1GhbT857kz1E7; Thu, 26 Apr 2012 20:59:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta07.westchester.pa.mail.comcast.net with comcast id 2kz31j01507duvL3Tkz3ul; Thu, 26 Apr 2012 20:59:04 +0000 Message-ID: <4F99B713.1040503@alum.mit.edu> Date: Thu, 26 Apr 2012 16:58:59 -0400 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: insipid@ietf.org References: <201204262006.q3QK6fTr027133@mtv-core-3.cisco.com> In-Reply-To: <201204262006.q3QK6fTr027133@mtv-core-3.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] INSIPID Req#1 - comments? 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, 26 Apr 2012 20:59:01 -0000 On 4/26/12 4:01 PM, James M. Polk wrote: > > REQ1: It must be possible for an administrator or an > external device which monitors the SIP-traffic to use > the identifier to identify a set of dialogs which have a > relationship with each other, such that they represent > the same SIP session, with as high a probability as > possible. Re: "identify a set of dialogs which have ***a*** relationship" Does "a relationship" mean some particular relationship to be specified as part of this process? Or does it mean any relationship of interest to the administrator? Or what? There needs t be more specificity here. Thanks, Paul From pkyzivat@alum.mit.edu Thu Apr 26 14:02: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 8B12A21E8120 for ; Thu, 26 Apr 2012 14:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 enadaScHCyPs for ; Thu, 26 Apr 2012 14:02:11 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id D7EDF21E8110 for ; Thu, 26 Apr 2012 14:02:10 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta15.westchester.pa.mail.comcast.net with comcast id 2h9Q1j0021ZXKqc5Fl29c4; Thu, 26 Apr 2012 21:02:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id 2l2A1j00F07duvL3hl2A9S; Thu, 26 Apr 2012 21:02:10 +0000 Message-ID: <4F99B7D1.90207@alum.mit.edu> Date: Thu, 26 Apr 2012 17:02:09 -0400 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: insipid@ietf.org References: <201204262006.q3QK6isF007654@mtv-core-4.cisco.com> In-Reply-To: <201204262006.q3QK6isF007654@mtv-core-4.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] INSIPID Req#2 - comments? 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, 26 Apr 2012 21:02:11 -0000 On 4/26/12 4:02 PM, James M. Polk wrote: > > REQ2: It must be possible to identify the end-to-end session > when a session is transferred or if two different sessions > are joined together via an intermediary (e.g., a PBX). This could be more precise about the transfer case: I presume this means something like: it must be possible to identify that the session prior to transfer is related to the session after transfer. Thanks, Paul From pkyzivat@alum.mit.edu Thu Apr 26 14:06:03 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 A199E21F86C4 for ; Thu, 26 Apr 2012 14:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 9EKZusi9YucT for ; Thu, 26 Apr 2012 14:06:03 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 14E0521F86C1 for ; Thu, 26 Apr 2012 14:06:02 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id 2heJ1j0011YDfWL53l644l; Thu, 26 Apr 2012 21:06:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id 2l621j00u07duvL3gl6261; Thu, 26 Apr 2012 21:06:02 +0000 Message-ID: <4F99B8BA.5000602@alum.mit.edu> Date: Thu, 26 Apr 2012 17:06:02 -0400 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: insipid@ietf.org References: <201204262006.q3QK6n7b027203@mtv-core-3.cisco.com> In-Reply-To: <201204262006.q3QK6n7b027203@mtv-core-3.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] INSIPID Req#3 - comments? 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, 26 Apr 2012 21:06:03 -0000 On 4/26/12 4:03 PM, James M. Polk wrote: > REQ3: It must be possible to identify all sessions > participating in a multipoint or multi-party conference > by observing the end-to-end session identifiers of each > session. What sorts of conference topologies does this apply to? I expect it was written with a star topology in mind. Is it expected to apply to other topologies as well - such as two connected stars? Thanks, Paul From pkyzivat@alum.mit.edu Thu Apr 26 14:12: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 965D511E807F for ; Thu, 26 Apr 2012 14:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 C-Gsy4qqyGHQ for ; Thu, 26 Apr 2012 14:12:08 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 87B2B11E8073 for ; Thu, 26 Apr 2012 14:11:59 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id 2lAR1j0060xGWP853lC0aD; Thu, 26 Apr 2012 21:12:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta12.westchester.pa.mail.comcast.net with comcast id 2lBx1j00U07duvL3YlByJy; Thu, 26 Apr 2012 21:11:58 +0000 Message-ID: <4F99BA1E.4030406@alum.mit.edu> Date: Thu, 26 Apr 2012 17:11:58 -0400 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: insipid@ietf.org References: <201204262006.q3QK6tXa007754@mtv-core-4.cisco.com> In-Reply-To: <201204262006.q3QK6tXa007754@mtv-core-4.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] INSIPID Req#4 - comments? 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, 26 Apr 2012 21:12:09 -0000 On 4/26/12 4:03 PM, James M. Polk wrote: > > REQ4: It must be possible to pass the identifier unchanged > through SIP B2BUAs or other intermediaries. I'm struggling with "possible" here. Its *possible* to pass the callid through unmodified. The problem is that it isn't guaranteed that it will go through unmodified. So ideally this would say something stronger, like: "the identifier MUST NOT be changed when passing through ..." But I think we all know it will be impossible to meet that. So we must be looking for something else. I think it is that the form of the identifier should not contain anything that can be easily correlated to the identity of either endpoint or to the topology of the network connecting them. Thanks, Paul From gsalguei@cisco.com Thu Apr 26 21:52:07 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 0A84421F874C for ; Thu, 26 Apr 2012 21:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 H8UQ1ckCYx3F for ; Thu, 26 Apr 2012 21:52:05 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 90D0921F874A for ; Thu, 26 Apr 2012 21:52:05 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3R4q2v3027761 for ; Fri, 27 Apr 2012 00:52:02 -0400 (EDT) Received: from rtp-gsalguei-8716.cisco.com (rtp-gsalguei-8716.cisco.com [10.116.61.55]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3R4q1rX007878 for ; Fri, 27 Apr 2012 00:52:01 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Apr 2012 00:52:01 -0400 Message-Id: <77659F77-CB15-4681-95F2-691B5B572277@cisco.com> To: insipid@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [Insipid] INSIPID Virtual Interim Doodle Poll 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, 27 Apr 2012 04:52:07 -0000 Folks -=20 As decided at IETF83 the INSIPID WG is planning a virtual interim = meeting to discuss and make progress on finalizing the list of = requirements for the end-to-end session identifier. I was pleased to = see James Polk started individual discussions on the alias for each = requirement. My hope is that we are able to make good progress on the = list so we can be as efficient as possible at the interim meeting. = Please indicate your preferences by the end of Thursday, May 3. I have = added a diverse selection of days/times to accommodate most. If you = think other times should be added to the poll, let the chairs knows. This will be a 2 hour long webex meeting (I'll send out meeting details = once we converge on a date/time). Please indicate your availability at: http://www.doodle.com/sfdpmipnhtqtxn6e The times specified on the poll are EDT but it should be intelligent = enough to translate to your local time. Cheers, Gonzalo= From jan.van.geel@belgacom.be Thu Apr 26 23:43:15 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 9ADA221F86F4 for ; Thu, 26 Apr 2012 23:43:15 -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 1OEVJ1cVwXLQ for ; Thu, 26 Apr 2012 23:43:14 -0700 (PDT) Received: from mx24.belgacom.be (mx24.belgacom.be [213.181.45.234]) by ietfa.amsl.com (Postfix) with ESMTP id 72AA721F86E8 for ; Thu, 26 Apr 2012 23:43:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,489,1330902000"; d="scan'208";a="21092862" Received: from unknown (HELO A03007.BGC.NET) ([10.120.129.162]) by mx24.belgacom.be with ESMTP; 27 Apr 2012 08:43:11 +0200 X-TM-IMSS-Message-ID: <1203450b00042183@belgacom.be> Received: from A04023.BGC.NET ([10.120.135.24]) by belgacom.be ([10.120.129.162]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 1203450b00042183 ; Fri, 27 Apr 2012 08:43:10 +0200 Received: from A04067.BGC.NET ([10.121.135.38]) by A04023.BGC.NET ([10.120.135.24]) with mapi id 14.01.0355.002; Fri, 27 Apr 2012 08:43:08 +0200 From: "VAN GEEL Jan (SDV/PSE)" To: "insipid@ietf.org" Thread-Topic: [Insipid] INSIPID Req#2 - comments? Thread-Index: AQHNI+gjxJmVnJvU4EScg3G/+gZ7HZatdliAgADDXOA= Date: Fri, 27 Apr 2012 06:43:08 +0000 Message-ID: <1E97FFD1485F1142BC075FF145A53A1E0B3510@A04067.BGC.NET> References: <201204262006.q3QK6isF007654@mtv-core-4.cisco.com> <4F99B7D1.90207@alum.mit.edu> In-Reply-To: <4F99B7D1.90207@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.115.28.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] INSIPID Req#2 - comments? 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, 27 Apr 2012 06:43:15 -0000 Question for my understanding: Does the word "transfer" in this requirement refer to a service known as "c= all transfer", or is it to be understood more generic, meaning any kind of = "transfer" caused by services like call transfer, call forwarding, etc... ? Kind regards Jan Van Geel IT and Network Specialist Belgacom SDE/SDV/PSE/FVC Tel: +32 2 202 1035 Tel: +32 2 207 9032 Email : jan.van.geel@belgacom.be -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 26 April 2012 23:02 To: insipid@ietf.org Subject: Re: [Insipid] INSIPID Req#2 - comments? On 4/26/12 4:02 PM, James M. Polk wrote: > > REQ2: It must be possible to identify the end-to-end session when a > session is transferred or if two different sessions are joined > together via an intermediary (e.g., a PBX). This could be more precise about the transfer case: I presume this means something like: it must be possible to identify that t= he session prior to transfer is related to the session after transfer. Thanks, Paul _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid ________________________________ ***** Disclaimer ***** http://www.belgacom.be/maildisclaimer From laura.liess.dt@googlemail.com Fri Apr 27 06:08:00 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 6BAAB21F86AD for ; Fri, 27 Apr 2012 06:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 4nXqfyX1HFfB for ; Fri, 27 Apr 2012 06:07:59 -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 6894221F86B7 for ; Fri, 27 Apr 2012 06:07:59 -0700 (PDT) Received: by werb10 with SMTP id b10so527690wer.31 for ; Fri, 27 Apr 2012 06:07:58 -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=yxcGbVPb9MZG7lmpLpLq5BxEcdzxbV25QNB2VWlyjSU=; b=Rs5OEICDsEgdAH1vNbFWS5hSgg21A/fb80GX5dwQYA4TgagNVd3bclcV3YcEVRA1BG DZmKAe1IHturJf1ej3aCL2LPmGewKkHJnztcVjh7u09MyB9QgvFuXj0St00rgfH9dSIe ZcBHc4YlwsgNdMf1ss4c5+efZlUfKusCIkG+6HfGdyYCrek5SlZPaxxbFOqcfIHTnx+9 cSHjZ3DfCIE3kdf9fnvDHVrVhQXsfO6yLer6Jzu93zeDTSxVMAFnDBtSXIIq8otltiMP 2WbBrot7i/38xKtSpanJXX+dOyl5fZcVIQnVsWtKOc5Y6kLXNRP7C+ojd1pHJj6nYAQi EI3w== MIME-Version: 1.0 Received: by 10.216.139.25 with SMTP id b25mr6569848wej.41.1335532078323; Fri, 27 Apr 2012 06:07:58 -0700 (PDT) Received: by 10.227.205.195 with HTTP; Fri, 27 Apr 2012 06:07:58 -0700 (PDT) In-Reply-To: <201204262007.q3QK73AU007837@mtv-core-4.cisco.com> References: <201204262007.q3QK73AU007837@mtv-core-4.cisco.com> Date: Fri, 27 Apr 2012 15:07:58 +0200 Message-ID: From: Laura Liess To: "James M. Polk" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "insipid@ietf.org" , =?UTF-8?Q?Martin_H=C3=BClsemann?= Subject: Re: [Insipid] INSIPID Req#6 - comments? 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, 27 Apr 2012 13:08:00 -0000 Hi, The benefit of having this requirement is not clear to me. What may happen if we do not have it? We have REQ5, which ensure hiding of every kid of device identity, in order to avoid B2BUAs to change the Session-ID. REQ5 is important. But REQ6? If we can not find out what the reason for it is, I propose to drop it, because having REQ6 may complicate the solution, I think. Thanks Laura 2012/4/26 James M. Polk : > Figure it is about time I sent these requirements out to the list. Commen= ts, > questions and wordsmithing are encouraged. Let's see if we can leave much= of > the wordsmithing till the end of the discussion, once we have agreed on t= he > requirement's worthiness and contents. > > Let's also keep the discussion on *this* thread to just *this* requiremen= t > for tracking purposes. There are 9 current requirements. Therefore, there > will be 9 different messages sent to this list. > > Here is REQ#6 as currently written in > http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id-reqts-= 00.txt > > =C2=A0 REQ6: The identifier must not reveal to the receiver of it > =C2=A0 that the Call-ID, tags, or any other SIP header or body > =C2=A0 portion have been changed by middleboxes, with as high a > =C2=A0 probability as possible. > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From laura.liess.dt@googlemail.com Fri Apr 27 06:18:20 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 4F28A21F85F8 for ; Fri, 27 Apr 2012 06:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 m2MBxqB61fep for ; Fri, 27 Apr 2012 06:18:19 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3C39021F85EF for ; Fri, 27 Apr 2012 06:18:19 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so477824wib.13 for ; Fri, 27 Apr 2012 06:18:18 -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=wlcP28JxzDSZE4M243841DZffHHQuJPrzv7Go8oJcGY=; b=keTg7aUMELxzqC2cyNr2rKBgDAl38Y3BiX2oyfSMt7wjAn929zeJodLOqRyEmKnhIR XkEdaCrih9/Ya1AICO20FdcUcevLtOyd+KerHIazdQDZcjQmPqo+LjsPyuXNxPantCJU nGse+msADhtaklEgi+6URKuCfCKsuln0KpoqsBpEBQXZN5SsYe4ZLcqLlxhSs/Ojftrq 7hzsd3C4+60ksj74Fqk4c+1R4YlVAhWajW3E1lA2qdzlcvuM7pse3u7Ytr216MhyQ4eB Yi/EJk3Z3CDLkDKeeIBa4RHrdsvDQD+lMYlvWQcEI7iq70ATKWVxooXqc6MP4fE0VLp+ gzqw== MIME-Version: 1.0 Received: by 10.180.105.194 with SMTP id go2mr5889393wib.22.1335532698205; Fri, 27 Apr 2012 06:18:18 -0700 (PDT) Received: by 10.227.205.195 with HTTP; Fri, 27 Apr 2012 06:18:18 -0700 (PDT) In-Reply-To: <06bb01cd23d4$bcd5a790$3680f6b0$@packetizer.com> References: <06bb01cd23d4$bcd5a790$3680f6b0$@packetizer.com> Date: Fri, 27 Apr 2012 15:18:18 +0200 Message-ID: From: Laura Liess To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: insipid@ietf.org, =?UTF-8?Q?Martin_H=C3=BClsemann?= , Hadriel Kaplan Subject: Re: [Insipid] Comment on REQ1, REQ6 and REQ7 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, 27 Apr 2012 13:18:20 -0000 Paul, What I tried to say was that I think we can drop REQ6. REQ5 and REC1 are important for us. (Unfortunately, the was drawing which arrived at the mailing list was not what I intended to send. So the example is quite difficult to understand.) Kind regards Laura 2012/4/26 Paul E. Jones : > Laura, > > I assume the desire for REQ6 relates to ensuring the kind of privacy that= is afforded by SBCs. =C2=A0They can hide network topologies, peering relat= ions, etc. =C2=A0This requirements suggests that we do not want those thing= s disclosed via the Session-ID. > > REQ7 is a means of assigning an ID when the endpoint does not. =C2=A0That= would perhaps mean one cannot inspect all the way to the endpoint, but one= can at least track sessions to the assigning element. > > REQ1 seems conflicting on the surface, but one may not always have access= into every segment everywhere. =C2=A0Those topologies and business relatio= nships remain hidden. =C2=A0Even so, it's possible to perhaps have multiple= people and organizations talking about the same Session-ID, regardless of = what other data is changed. > > In short, I don't think it matters if something can determine changes mad= e by the B2BUA if it's that something is in a position to do so (e.g., has = physical access to all network segments), but the AS should not be able to = see that Carrier A peered with Carrier B or some such or that the caller is= using Mobile Operator C. > > Paul > >> -----Original Message----- >> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >> Sent: Thursday, April 26, 2012 9:50 AM >> To: insipid@ietf.org; Paul Jones; Hadriel Kaplan >> Cc: Martin H=C3=BClsemann >> Subject: Comment on REQ1, REQ6 and REQ7 >> >> Hi, >> >> What is the reason for having REQ6? =C2=A0Do we realy need it? It seems = to me >> that it will be difficult to fulfill all REQ1 and REQ6 and REQ7 at the >> same time. >> >> Take the following scenario: >> >> =C2=A0 =C2=A0 ----------- >> ------------- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0------= ----- >> =C2=A0 =C2=A0| =C2=A0 =C2=A0A =C2=A0 =C2=A0 | ---------Call-ID x--------= -------------->| B2BUA >> |-------------Call-ID y------->| =C2=A0 =C2=A0AS =C2=A0 |-------- >> =C2=A0 =C2=A0 ----------- >> ------------- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Session-ID= z =C2=A0 =C2=A0----------- >> >> A is an end device that does not support Session-ID. =C2=A0AS is an Appl= ication >> Server and in the context of REQ6 the receiver of the Session-ID. The >> B2BUA changes the Call-ID from x to y and calculates a Session-ID z. >> By REQ1 and REQ7, an external device monitoring the SIP-traffic must be >> able to find out that messages with the Call-ID x and messages with the >> Session-ID z belong to the same session. So the B2BUA must build z as a >> function of x, let's say z =3DF(x) and the monitoring the B2BUA and the >> monitoring system have to know F. >> Otherwise, =C2=A0by REQ6, the AS is not allowed to know F, otherwise he = is able >> to find out that z /=3D F(y). >> Maybe it is in theoreticaly possible for a network to have a for each no= de >> a different F and the the monitoring systems knowing which F to use for = a >> call leg, but in practice this is probably too complex. >> >> Thanks, >> Laura > From pravindran@sonusnet.com Fri Apr 27 08:07:31 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 C7AD821F8759 for ; Fri, 27 Apr 2012 08:07:31 -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 aF7-mZFB+7Tj for ; Fri, 27 Apr 2012 08:07:31 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6936321F8752 for ; Fri, 27 Apr 2012 08:07:30 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKT5q2MRouDx4fwqwxI3z+KFwiKXc1rnvy@postini.com; Fri, 27 Apr 2012 08:07:30 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 27 Apr 2012 11:07:31 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Fri, 27 Apr 2012 20:37:25 +0530 From: "Ravindran, Parthasarathi" To: Laura Liess , "Paul E. Jones" Thread-Topic: [Insipid] Comment on REQ1, REQ6 and REQ7 Thread-Index: AQHNI7OBxm6Ux2YUtUeiPceD7Rb+H5atBd0AgAFG9ACAAHo48A== Date: Fri, 27 Apr 2012 15:07:24 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E23AC3B@inba-mail01.sonusnet.com> References: <06bb01cd23d4$bcd5a790$3680f6b0$@packetizer.com> In-Reply-To: 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "insipid@ietf.org" , =?utf-8?B?TWFydGluIEjDvGxzZW1hbm4=?= , Hadriel Kaplan Subject: Re: [Insipid] Comment on REQ1, REQ6 and REQ7 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, 27 Apr 2012 15:07:31 -0000 UkVRLTYgaXMgaW1wb3J0YW50IHRvIGF2b2lkIHVzaW5nIFNlc3Npb24taWQgYmVpbmcgdXNlZCBh cyByYXRob2xlIGZvciBwYXNzaW5nIGFueSBpbmZvcm1hdGlvbi4gSU1PLCBpdCBpcyBpbXBvcnRh bnQuIA0KDQpUaGFua3MNClBhcnRoYQ0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5G cm9tOiBpbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppbnNpcGlkLWJvdW5jZXNAaWV0 Zi5vcmddIE9uDQo+QmVoYWxmIE9mIExhdXJhIExpZXNzDQo+U2VudDogRnJpZGF5LCBBcHJpbCAy NywgMjAxMiA2OjQ4IFBNDQo+VG86IFBhdWwgRS4gSm9uZXMNCj5DYzogaW5zaXBpZEBpZXRmLm9y ZzsgTWFydGluIEjDvGxzZW1hbm47IEhhZHJpZWwgS2FwbGFuDQo+U3ViamVjdDogUmU6IFtJbnNp cGlkXSBDb21tZW50IG9uIFJFUTEsIFJFUTYgYW5kIFJFUTcNCj4NCj5QYXVsLA0KPg0KPldoYXQg SSB0cmllZCB0byBzYXkgd2FzIHRoYXQgSSB0aGluayB3ZSBjYW4gZHJvcCBSRVE2LiBSRVE1IGFu ZCBSRUMxIGFyZQ0KPmltcG9ydGFudCBmb3IgdXMuDQo+DQo+KFVuZm9ydHVuYXRlbHksIHRoZSB3 YXMgZHJhd2luZyB3aGljaCBhcnJpdmVkIGF0IHRoZSBtYWlsaW5nIGxpc3Qgd2FzDQo+bm90IHdo YXQgSSBpbnRlbmRlZCB0byBzZW5kLiBTbyB0aGUgZXhhbXBsZSBpcyBxdWl0ZSBkaWZmaWN1bHQg dG8NCj51bmRlcnN0YW5kLikNCj4NCj5LaW5kIHJlZ2FyZHMNCj5MYXVyYQ0KPg0KPg0KPjIwMTIv NC8yNiBQYXVsIEUuIEpvbmVzIDxwYXVsZWpAcGFja2V0aXplci5jb20+Og0KPj4gTGF1cmEsDQo+ Pg0KPj4gSSBhc3N1bWUgdGhlIGRlc2lyZSBmb3IgUkVRNiByZWxhdGVzIHRvIGVuc3VyaW5nIHRo ZSBraW5kIG9mIHByaXZhY3kNCj50aGF0IGlzIGFmZm9yZGVkIGJ5IFNCQ3MuIMKgVGhleSBjYW4g aGlkZSBuZXR3b3JrIHRvcG9sb2dpZXMsIHBlZXJpbmcNCj5yZWxhdGlvbnMsIGV0Yy4gwqBUaGlz IHJlcXVpcmVtZW50cyBzdWdnZXN0cyB0aGF0IHdlIGRvIG5vdCB3YW50IHRob3NlDQo+dGhpbmdz IGRpc2Nsb3NlZCB2aWEgdGhlIFNlc3Npb24tSUQuDQo+Pg0KPj4gUkVRNyBpcyBhIG1lYW5zIG9m IGFzc2lnbmluZyBhbiBJRCB3aGVuIHRoZSBlbmRwb2ludCBkb2VzIG5vdC4gwqBUaGF0DQo+d291 bGQgcGVyaGFwcyBtZWFuIG9uZSBjYW5ub3QgaW5zcGVjdCBhbGwgdGhlIHdheSB0byB0aGUgZW5k cG9pbnQsIGJ1dA0KPm9uZSBjYW4gYXQgbGVhc3QgdHJhY2sgc2Vzc2lvbnMgdG8gdGhlIGFzc2ln bmluZyBlbGVtZW50Lg0KPj4NCj4+IFJFUTEgc2VlbXMgY29uZmxpY3Rpbmcgb24gdGhlIHN1cmZh Y2UsIGJ1dCBvbmUgbWF5IG5vdCBhbHdheXMgaGF2ZQ0KPmFjY2VzcyBpbnRvIGV2ZXJ5IHNlZ21l bnQgZXZlcnl3aGVyZS4gwqBUaG9zZSB0b3BvbG9naWVzIGFuZCBidXNpbmVzcw0KPnJlbGF0aW9u c2hpcHMgcmVtYWluIGhpZGRlbi4gwqBFdmVuIHNvLCBpdCdzIHBvc3NpYmxlIHRvIHBlcmhhcHMg aGF2ZQ0KPm11bHRpcGxlIHBlb3BsZSBhbmQgb3JnYW5pemF0aW9ucyB0YWxraW5nIGFib3V0IHRo ZSBzYW1lIFNlc3Npb24tSUQsDQo+cmVnYXJkbGVzcyBvZiB3aGF0IG90aGVyIGRhdGEgaXMgY2hh bmdlZC4NCj4+DQo+PiBJbiBzaG9ydCwgSSBkb24ndCB0aGluayBpdCBtYXR0ZXJzIGlmIHNvbWV0 aGluZyBjYW4gZGV0ZXJtaW5lIGNoYW5nZXMNCj5tYWRlIGJ5IHRoZSBCMkJVQSBpZiBpdCdzIHRo YXQgc29tZXRoaW5nIGlzIGluIGEgcG9zaXRpb24gdG8gZG8gc28NCj4oZS5nLiwgaGFzIHBoeXNp Y2FsIGFjY2VzcyB0byBhbGwgbmV0d29yayBzZWdtZW50cyksIGJ1dCB0aGUgQVMgc2hvdWxkDQo+ bm90IGJlIGFibGUgdG8gc2VlIHRoYXQgQ2FycmllciBBIHBlZXJlZCB3aXRoIENhcnJpZXIgQiBv ciBzb21lIHN1Y2ggb3INCj50aGF0IHRoZSBjYWxsZXIgaXMgdXNpbmcgTW9iaWxlIE9wZXJhdG9y IEMuDQo+Pg0KPj4gUGF1bA0KPj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ IEZyb206IExhdXJhIExpZXNzIFttYWlsdG86bGF1cmEubGllc3MuZHRAZ29vZ2xlbWFpbC5jb21d DQo+Pj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDI2LCAyMDEyIDk6NTAgQU0NCj4+PiBUbzogaW5z aXBpZEBpZXRmLm9yZzsgUGF1bCBKb25lczsgSGFkcmllbCBLYXBsYW4NCj4+PiBDYzogTWFydGlu IEjDvGxzZW1hbm4NCj4+PiBTdWJqZWN0OiBDb21tZW50IG9uIFJFUTEsIFJFUTYgYW5kIFJFUTcN Cj4+Pg0KPj4+IEhpLA0KPj4+DQo+Pj4gV2hhdCBpcyB0aGUgcmVhc29uIGZvciBoYXZpbmcgUkVR Nj8gwqBEbyB3ZSByZWFseSBuZWVkIGl0PyBJdCBzZWVtcyB0bw0KPj4+IG1lIHRoYXQgaXQgd2ls bCBiZSBkaWZmaWN1bHQgdG8gZnVsZmlsbCBhbGwgUkVRMSBhbmQgUkVRNiBhbmQgUkVRNyBhdA0K Pj4+IHRoZSBzYW1lIHRpbWUuDQo+Pj4NCj4+PiBUYWtlIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW86 DQo+Pj4NCj4+PiDCoCDCoCAtLS0tLS0tLS0tLQ0KPj4+IC0tLS0tLS0tLS0tLS0gwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAtLS0tLS0tLS0tLQ0K Pj4+IMKgIMKgfCDCoCDCoEEgwqAgwqAgfCAtLS0tLS0tLS1DYWxsLUlEIHgtLS0tLS0tLS0tLS0t LS0tLS0tLS0tPnwgQjJCVUENCj4+PiB8LS0tLS0tLS0tLS0tLUNhbGwtSUQgeS0tLS0tLS0+fCDC oCDCoEFTIMKgIHwtLS0tLS0tLQ0KPj4+IMKgIMKgIC0tLS0tLS0tLS0tDQo+Pj4gLS0tLS0tLS0t LS0tLSDCoCDCoCDCoCDCoCDCoCDCoCDCoFNlc3Npb24tSUQgeiDCoCDCoC0tLS0tLS0tLS0tDQo+ Pj4NCj4+PiBBIGlzIGFuIGVuZCBkZXZpY2UgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IFNlc3Npb24t SUQuIMKgQVMgaXMgYW4NCj4+PiBBcHBsaWNhdGlvbiBTZXJ2ZXIgYW5kIGluIHRoZSBjb250ZXh0 IG9mIFJFUTYgdGhlIHJlY2VpdmVyIG9mIHRoZQ0KPj4+IFNlc3Npb24tSUQuIFRoZSBCMkJVQSBj aGFuZ2VzIHRoZSBDYWxsLUlEIGZyb20geCB0byB5IGFuZCBjYWxjdWxhdGVzDQo+YSBTZXNzaW9u LUlEIHouDQo+Pj4gQnkgUkVRMSBhbmQgUkVRNywgYW4gZXh0ZXJuYWwgZGV2aWNlIG1vbml0b3Jp bmcgdGhlIFNJUC10cmFmZmljIG11c3QNCj4+PiBiZSBhYmxlIHRvIGZpbmQgb3V0IHRoYXQgbWVz c2FnZXMgd2l0aCB0aGUgQ2FsbC1JRCB4IGFuZCBtZXNzYWdlcw0KPj4+IHdpdGggdGhlIFNlc3Np b24tSUQgeiBiZWxvbmcgdG8gdGhlIHNhbWUgc2Vzc2lvbi4gU28gdGhlIEIyQlVBIG11c3QNCj4+ PiBidWlsZCB6IGFzIGEgZnVuY3Rpb24gb2YgeCwgbGV0J3Mgc2F5IHogPUYoeCkgYW5kIHRoZSBt b25pdG9yaW5nIHRoZQ0KPj4+IEIyQlVBIGFuZCB0aGUgbW9uaXRvcmluZyBzeXN0ZW0gaGF2ZSB0 byBrbm93IEYuDQo+Pj4gT3RoZXJ3aXNlLCDCoGJ5IFJFUTYsIHRoZSBBUyBpcyBub3QgYWxsb3dl ZCB0byBrbm93IEYsIG90aGVyd2lzZSBoZSBpcw0KPj4+IGFibGUgdG8gZmluZCBvdXQgdGhhdCB6 IC89IEYoeSkuDQo+Pj4gTWF5YmUgaXQgaXMgaW4gdGhlb3JldGljYWx5IHBvc3NpYmxlIGZvciBh IG5ldHdvcmsgdG8gaGF2ZSBhIGZvciBlYWNoDQo+Pj4gbm9kZSBhIGRpZmZlcmVudCBGIGFuZCB0 aGUgdGhlIG1vbml0b3Jpbmcgc3lzdGVtcyBrbm93aW5nIHdoaWNoIEYgdG8NCj4+PiB1c2UgZm9y IGEgY2FsbCBsZWcsIGJ1dCBpbiBwcmFjdGljZSB0aGlzIGlzIHByb2JhYmx5IHRvbyBjb21wbGV4 Lg0KPj4+DQo+Pj4gVGhhbmtzLA0KPj4+IExhdXJhDQo+Pg0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+aW5zaXBpZCBtYWlsaW5nIGxpc3QNCj5pbnNp cGlkQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnNp cGlkDQo= From paulej@packetizer.com Fri Apr 27 11:00:58 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 DC6C221F860D for ; Fri, 27 Apr 2012 11:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 NS36JteUb2kS for ; Fri, 27 Apr 2012 11:00:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C730321F85B7 for ; Fri, 27 Apr 2012 11:00:57 -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 q3RI0qFt017831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Apr 2012 14:00:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335549653; bh=gAe9Jx2ksoMkTv7LjKK13LrasUVS7Nh7uPpNMBjtVRU=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=mqagDlHOFoXGWTj3xnifr+h10dEuMAHTdso0OpN0ClySlFoYFuX0Q5QoFrUGHyjHF QhE0+oBU5eHAKQafq9w6u0VqjOb+quOt1jlRn3MlGURp60yaHiZeXQu3smiraizi5C 3B/H/EbKtwvv8iGWRLPLwiHvQPdWpHPMRlET9id4= From: "Paul E. Jones" To: "'Paul Kyzivat'" , References: <201204262006.q3QK6fTr027133@mtv-core-3.cisco.com> <4F99B713.1040503@alum.mit.edu> In-Reply-To: <4F99B713.1040503@alum.mit.edu> Date: Fri, 27 Apr 2012 14:01:04 -0400 Message-ID: <07aa01cd249f$b717c240$254746c0$@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: AQIcQ/D18aEZNoVzvcUWRb5iNg0fCgH4UaFrlgD0SMA= Content-Language: en-us Subject: Re: [Insipid] INSIPID Req#1 - comments? 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, 27 Apr 2012 18:00:59 -0000 > Re: "identify a set of dialogs which have ***a*** relationship" > > Does "a relationship" mean some particular relationship to be specified as > part of this process? Or does it mean any relationship of interest to the > administrator? Or what? Relationship, as in "dialog 1" is for the same call as "dialog 2" (which might look quite different after they pass through an SBC). Or, it might be that "dialog 1" and "dialog 2" are in the same conference. Suggested wording? Paul From pkyzivat@alum.mit.edu Fri Apr 27 12:07:21 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 0337C21F8655 for ; Fri, 27 Apr 2012 12:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 6xoSbbyij-MG for ; Fri, 27 Apr 2012 12:07:20 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id E2F9E21F8648 for ; Fri, 27 Apr 2012 12:07:10 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta15.westchester.pa.mail.comcast.net with comcast id 37621j0040QuhwU5F7782k; Fri, 27 Apr 2012 19:07:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta02.westchester.pa.mail.comcast.net with comcast id 377B1j00607duvL3N77Biw; Fri, 27 Apr 2012 19:07:12 +0000 Message-ID: <4F9AEE5D.5090703@alum.mit.edu> Date: Fri, 27 Apr 2012 15:07:09 -0400 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: <201204262006.q3QK6fTr027133@mtv-core-3.cisco.com> <4F99B713.1040503@alum.mit.edu> <07aa01cd249f$b717c240$254746c0$@packetizer.com> In-Reply-To: <07aa01cd249f$b717c240$254746c0$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: insipid@ietf.org Subject: Re: [Insipid] INSIPID Req#1 - comments? 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, 27 Apr 2012 19:07:21 -0000 On 4/27/12 2:01 PM, Paul E. Jones wrote: >> Re: "identify a set of dialogs which have ***a*** relationship" >> >> Does "a relationship" mean some particular relationship to be specified as >> part of this process? Or does it mean any relationship of interest to the >> administrator? Or what? > > Relationship, as in "dialog 1" is for the same call as "dialog 2" (which > might look quite different after they pass through an SBC). Or, it might be > that "dialog 1" and "dialog 2" are in the same conference. > > Suggested wording? Its difficult, because there is not good terminology for what is being defined. How about: REQ1: It must be possible for an administrator or an external device which monitors the SIP-traffic to use the identifier to identify those dialogs which were at some point in time components of a single end to end SIP session. (E.g. parts of the same call.) I'm not in love with this, but I think it gets closer. I left out the part about probability, because I don't think it adds anything. It is probably the case that this requirement will not be fully met by any mechanism. But the adequacy of the mechanism will be debated. Thanks, Paul From salvatore.loreto@ericsson.com Sat Apr 28 05:30:14 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 EC84A21F86AD for ; Sat, 28 Apr 2012 05:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.471 X-Spam-Level: X-Spam-Status: No, score=-106.471 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HELO_EQ_SE=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 hKgkbTKM3l17 for ; Sat, 28 Apr 2012 05:30:14 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AD56421F85C7 for ; Sat, 28 Apr 2012 05:30:13 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-47-4f9be2d30480 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 09.82.03534.3D2EB9F4; Sat, 28 Apr 2012 14:30:11 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Sat, 28 Apr 2012 14:30:11 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5B6872325 for ; Sat, 28 Apr 2012 15:30:11 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 64911529FA for ; Sat, 28 Apr 2012 15:30:11 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1E8885261F for ; Sat, 28 Apr 2012 15:30:11 +0300 (EEST) Message-ID: <4F9BE2D2.7000802@ericsson.com> Date: Sat, 28 Apr 2012 15:30:10 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <201204262006.q3QK6n7b027203@mtv-core-3.cisco.com> <4F99B8BA.5000602@alum.mit.edu> In-Reply-To: <4F99B8BA.5000602@alum.mit.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [Insipid] INSIPID Req#3 - comments? 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, 28 Apr 2012 12:30:15 -0000 On 4/27/12 12:06 AM, Paul Kyzivat wrote: > On 4/26/12 4:03 PM, James M. Polk wrote: > >> REQ3: It must be possible to identify all sessions >> participating in a multipoint or multi-party conference >> by observing the end-to-end session identifiers of each >> session. > What sorts of conference topologies does this apply to? > I expect it was written with a star topology in mind. yep, a star topology was in my mind when we discussed it... not sure if other had different one > Is it expected to > apply to other topologies as well - such as two connected stars? you mean a scenario where each star has at the center a MCU with its own subset of participants and MCU1 and MCU2 host two different conference session, but the MCU2 is also a participant for the conf at MCU1. From pkyzivat@alum.mit.edu Sat Apr 28 11:34: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 D643721F860D for ; Sat, 28 Apr 2012 11:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFPHSPGVrv4L for ; Sat, 28 Apr 2012 11:34:17 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7F121F85E1 for ; Sat, 28 Apr 2012 11:34:15 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta05.westchester.pa.mail.comcast.net with comcast id 3WY81j0010vyq2s55WaG0y; Sat, 28 Apr 2012 18:34:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta05.westchester.pa.mail.comcast.net with comcast id 3WaE1j01m07duvL3RWaEwe; Sat, 28 Apr 2012 18:34:14 +0000 Message-ID: <4F9C3826.7040205@alum.mit.edu> Date: Sat, 28 Apr 2012 14:34:14 -0400 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: insipid@ietf.org References: <201204262006.q3QK6n7b027203@mtv-core-3.cisco.com> <4F99B8BA.5000602@alum.mit.edu> <4F9BE2D2.7000802@ericsson.com> In-Reply-To: <4F9BE2D2.7000802@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] INSIPID Req#3 - comments? 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, 28 Apr 2012 18:34:18 -0000 On 4/28/12 8:30 AM, Salvatore Loreto wrote: > On 4/27/12 12:06 AM, Paul Kyzivat wrote: >> On 4/26/12 4:03 PM, James M. Polk wrote: >> >>> REQ3: It must be possible to identify all sessions >>> participating in a multipoint or multi-party conference >>> by observing the end-to-end session identifiers of each >>> session. >> What sorts of conference topologies does this apply to? >> I expect it was written with a star topology in mind. > yep, a star topology was in my mind when we discussed it... > not sure if other had different one > >> Is it expected to >> apply to other topologies as well - such as two connected stars? > you mean a scenario where each star has at the center a MCU with its own > subset of participants > and MCU1 and MCU2 host two different conference session, > but the MCU2 is also a participant for the conf at MCU1. yep. But that was just an example. My assumption is that you only had a star topology in mind, and anything else would be gravy. Thanks, Paul From jmpolk@cisco.com Sun Apr 29 14:54: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 7A9B721F85A4 for ; Sun, 29 Apr 2012 14:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.483 X-Spam-Level: X-Spam-Status: No, score=-110.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 wf6ma+5pyljS for ; Sun, 29 Apr 2012 14:54:10 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B77AC21F8546 for ; Sun, 29 Apr 2012 14:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1579; q=dns/txt; s=iport; t=1335736450; x=1336946050; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=dohkZfbmXurocO9FmDIKmGQ0zXVtowt/L8own7WLIFE=; b=WB1fjQrMzXaWDvvVDccfqdwBPLpzxBNm3ccuJY7Acta8J4ee/uMci07e riRMeisy+QTjfjI+CgYJ/PskpFU8Ksa7AhCcD+mI5F0gbK1BEQCTLEGQX 9wvnl6H+bxLkJ/7CFf6CuTW6iKDgLRdWnl2Jz8XEhbANANp9s1M+SmBVd 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAE64nU+rRDoJ/2dsb2JhbAA5Cg6yC4EHggkBAQEDAQEBAQ8BJQIuBhALBwQOCh4QGQ4wBgESIodmBAyZbp8PBIsDhh8EiGSbc4Fpgi9X X-IronPort-AV: E=Sophos;i="4.75,501,1330905600"; d="scan'208";a="42726389" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 29 Apr 2012 21:54:01 +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 q3TLs0Kq023375; Sun, 29 Apr 2012 21:54:00 GMT Message-Id: <201204292154.q3TLs0Kq023375@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 29 Apr 2012 16:54:00 -0500 To: Paul Kyzivat , insipid@ietf.org From: "James M. Polk" In-Reply-To: <4F9C3826.7040205@alum.mit.edu> References: <201204262006.q3QK6n7b027203@mtv-core-3.cisco.com> <4F99B8BA.5000602@alum.mit.edu> <4F9BE2D2.7000802@ericsson.com> <4F9C3826.7040205@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Insipid] INSIPID Req#3 - comments? 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: Sun, 29 Apr 2012 21:54:11 -0000 At 01:34 PM 4/28/2012, Paul Kyzivat wrote: >On 4/28/12 8:30 AM, Salvatore Loreto wrote: >>On 4/27/12 12:06 AM, Paul Kyzivat wrote: >>>On 4/26/12 4:03 PM, James M. Polk wrote: >>> >>>>REQ3: It must be possible to identify all sessions >>>>participating in a multipoint or multi-party conference >>>>by observing the end-to-end session identifiers of each >>>>session. >>>What sorts of conference topologies does this apply to? >>>I expect it was written with a star topology in mind. >>yep, a star topology was in my mind when we discussed it... >>not sure if other had different one >> >>>Is it expected to >>>apply to other topologies as well - such as two connected stars? >>you mean a scenario where each star has at the center a MCU with its own >>subset of participants >>and MCU1 and MCU2 host two different conference session, >>but the MCU2 is also a participant for the conf at MCU1. > >yep. > >But that was just an example. > >My assumption is that you only had a star topology in mind, and >anything else would be gravy. I had a star in mind, with the possibility of multiple stars in the initial call, where everyone has the original session-ID. I don't know about joining an MCU with its star after the original MCU brought the conference on-line (i.e., joining two independent star conferences that originally had their own session-IDs). James > Thanks, > Paul >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Mon Apr 30 03:31:26 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 993E821F85B5 for ; Mon, 30 Apr 2012 03:31:26 -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 QN1xAe7Gq8Mx for ; Mon, 30 Apr 2012 03:31:25 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9093921F8569 for ; Mon, 30 Apr 2012 03:31:25 -0700 (PDT) Received: from [156.106.216.93] ([156.106.216.93]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3UAVK3F024193 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Apr 2012 06:31:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335781883; bh=vSnK0ramTPoHTpapNTmKrt4wSMdgU4a5Ok1cMXPnRvw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=fvMfaA901efbRdwHm76lqSBbb66cclQVsrwWbiSkLb+y1GHPS6JvQPS+oVQRAjUal IElb9ufHR/4tbxEfO7/ATzMzqbRE08r96bz+1F1ccaCY0W7FXChCdj83AoxNHbZB2e L2/0Y2ZbuN//7WisyriMyjpByUACAPGdq60rrmtE= Message-ID: <4F9E69F9.1000107@packetizer.com> Date: Mon, 30 Apr 2012 06:31:21 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Paul Kyzivat References: <201204262006.q3QK6fTr027133@mtv-core-3.cisco.com> <4F99B713.1040503@alum.mit.edu> <07aa01cd249f$b717c240$254746c0$@packetizer.com> <4F9AEE5D.5090703@alum.mit.edu> In-Reply-To: <4F9AEE5D.5090703@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: insipid@ietf.org Subject: Re: [Insipid] INSIPID Req#1 - comments? 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, 30 Apr 2012 10:31:26 -0000 OK.. I changed REQ1 to read as you propose. Paul On 4/27/2012 3:07 PM, Paul Kyzivat wrote: > On 4/27/12 2:01 PM, Paul E. Jones wrote: >>> Re: "identify a set of dialogs which have ***a*** relationship" >>> >>> Does "a relationship" mean some particular relationship to be >>> specified as >>> part of this process? Or does it mean any relationship of interest >>> to the >>> administrator? Or what? >> >> Relationship, as in "dialog 1" is for the same call as "dialog 2" (which >> might look quite different after they pass through an SBC). Or, it >> might be >> that "dialog 1" and "dialog 2" are in the same conference. >> >> Suggested wording? > > Its difficult, because there is not good terminology for what is being > defined. How about: > > REQ1: It must be possible for an administrator or an > external device which monitors the SIP-traffic to use > the identifier to identify those dialogs which were > at some point in time components of a single end to > end SIP session. (E.g. parts of the same call.) > > I'm not in love with this, but I think it gets closer. > I left out the part about probability, because I don't think it adds > anything. It is probably the case that this requirement will not be > fully met by any mechanism. But the adequacy of the mechanism will be > debated. > > Thanks, > Paul From paulej@packetizer.com Mon Apr 30 04:29:59 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 8FAF221F85AF for ; Mon, 30 Apr 2012 04:29:59 -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 bArazNQ5pDWs for ; Mon, 30 Apr 2012 04:29:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8718E21F85A5 for ; Mon, 30 Apr 2012 04:29:58 -0700 (PDT) Received: from [156.106.216.93] ([156.106.216.93]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3UBTr7s025731 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Apr 2012 07:29:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335785396; bh=XJLt7mkZz0L7OY7X8ZvEM1357qIyzu4fTDOMqE4iWc0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=oyr3zAwLNFIg4E/lqwN2fP2VpmzqlnHu+/wZFKy3+ozViXcLRbk9/ec36255iBshy 5V4RBxsntb6sq6IJmEqfpN9Az6WJgubflexyh40SPG4frPaPEnxEgw8jYwFVW9eeM9 HQKHqFv+l1G2y2ZBQRY5fNeojIZc8T84le+2TWDQ= Message-ID: <4F9E77B1.4030201@packetizer.com> Date: Mon, 30 Apr 2012 07:29:53 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "VAN GEEL Jan (SDV/PSE)" References: <201204262006.q3QK6isF007654@mtv-core-4.cisco.com> <4F99B7D1.90207@alum.mit.edu> <1E97FFD1485F1142BC075FF145A53A1E0B3510@A04067.BGC.NET> In-Reply-To: <1E97FFD1485F1142BC075FF145A53A1E0B3510@A04067.BGC.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "insipid@ietf.org" Subject: Re: [Insipid] INSIPID Req#2 - comments? 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, 30 Apr 2012 11:29:59 -0000 The intent is the address transfer, whether that uses REFER messages or a "transfer" that happens via a B2BUA that causes a call between A and B to be between A and C, for example. Paul On 4/27/2012 2:43 AM, VAN GEEL Jan (SDV/PSE) wrote: > Question for my understanding: > > Does the word "transfer" in this requirement refer to a service known as "call transfer", or is it to be understood more generic, meaning any kind of "transfer" caused by services like call transfer, call forwarding, etc... ? > > Kind regards > > Jan Van Geel > IT and Network Specialist > Belgacom SDE/SDV/PSE/FVC > Tel: +32 2 202 1035 > Tel: +32 2 207 9032 > Email : jan.van.geel@belgacom.be > > > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 26 April 2012 23:02 > To: insipid@ietf.org > Subject: Re: [Insipid] INSIPID Req#2 - comments? > > On 4/26/12 4:02 PM, James M. Polk wrote: >> REQ2: It must be possible to identify the end-to-end session when a >> session is transferred or if two different sessions are joined >> together via an intermediary (e.g., a PBX). > This could be more precise about the transfer case: > > I presume this means something like: it must be possible to identify that the session prior to transfer is related to the session after transfer. > > Thanks, > Paul > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > > ________________________________ > > ***** Disclaimer ***** > http://www.belgacom.be/maildisclaimer > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Mon Apr 30 06:30:32 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 0CF4421F85F4 for ; Mon, 30 Apr 2012 06:30:32 -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 cz9n58UJ4ety for ; Mon, 30 Apr 2012 06:30:31 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C87F521F85D9 for ; Mon, 30 Apr 2012 06:30:30 -0700 (PDT) Received: from [156.106.233.62] ([156.106.233.62]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3UDUPZS030321 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Apr 2012 09:30:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335792627; bh=jf73TgFfNai9pamnlOh4ViXm1zEd5Yj33wOepyPN23E=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Ev5lo86xNmiZEWi6dBD0QIZd6nWYiRJaYySxzG91U3zy/pk7w+I71+12LftcdRCYR LOzshhWJHQzI6Q+PfhxoUucJYVfBzn4PHkL9f+ohgr4U5WDWpXG4dw5CLkFtdcgNsL GhxqLy4C4n7vXbYmxR4JbA0cirWBqlgDvowTi+AU= Message-ID: <4F9E93F1.9070803@packetizer.com> Date: Mon, 30 Apr 2012 09:30:25 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Laura Liess References: <201204262007.q3QK73AU007837@mtv-core-4.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "James M. Polk" , "insipid@ietf.org" , =?UTF-8?B?TWFydGluIEjDvGxzZW1hbm4=?= Subject: Re: [Insipid] INSIPID Req#6 - comments? 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, 30 Apr 2012 13:30:32 -0000 I thought somebody replied on this one. In any case, the intent is to not reveal to the world that a call has passed through an SBC. I assume this is to ensure topologies and peering relationships remain protected. Paul On 4/27/2012 9:07 AM, Laura Liess wrote: > Hi, > > The benefit of having this requirement is not clear to me. What may > happen if we do not have it? > We have REQ5, which ensure hiding of every kid of device identity, in > order to avoid B2BUAs to change the Session-ID. REQ5 is important. But > REQ6? If we can not find out what the reason for it is, I propose to > drop it, because having REQ6 may complicate the solution, I think. > > Thanks > Laura > > 2012/4/26 James M. Polk: >> Figure it is about time I sent these requirements out to the list. Comments, >> questions and wordsmithing are encouraged. Let's see if we can leave much of >> the wordsmithing till the end of the discussion, once we have agreed on the >> requirement's worthiness and contents. >> >> Let's also keep the discussion on *this* thread to just *this* requirement >> for tracking purposes. There are 9 current requirements. Therefore, there >> will be 9 different messages sent to this list. >> >> Here is REQ#6 as currently written in >> http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id-reqts-00.txt >> >> REQ6: The identifier must not reveal to the receiver of it >> that the Call-ID, tags, or any other SIP header or body >> portion have been changed by middleboxes, with as high a >> probability as possible. >> _______________________________________________ >> 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 laura.liess.dt@googlemail.com Mon Apr 30 07:12:07 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 4DECF21F84D2 for ; Mon, 30 Apr 2012 07:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 0R7MyJ24CivY for ; Mon, 30 Apr 2012 07:12:06 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42C7521F84CF for ; Mon, 30 Apr 2012 07:12:06 -0700 (PDT) Received: by iazz13 with SMTP id z13so5249845iaz.31 for ; Mon, 30 Apr 2012 07:12:05 -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=KoQrJC0OiURseh9tKkAE4CdrK+XjOeDgL8QBXIO8cJo=; b=NDlziJEoFTPHKwHNyBRWMI0tWhTNVyjyp5fyUFwImvodJ849nJOOpAQ4geqGc0q8JA MdAIibEMlWh1u0mVD29xtFlAgXZ8CkSUDe5y0l6fN4KEy9J+5tgYdy/uQn5he4JVhJ8+ PtnUvK4+YOvlUDXeV/uBkyK04eZukrKFFFEJ+JetkkD5zGB6y5UgHEuATDS8OYaQHqbX e5ANs+tWTtwT+GM/7SNRaoike2uRK2VMID4TVxMjzRTT5tal0F3vR1hNlg9cHY2uwg6u nhqP1uhKO2XnPCjTxrcVrefF9CGCOD4DtH/PunnmCrFw+u52QoanImL7Cs410U218cKq frtg== MIME-Version: 1.0 Received: by 10.42.173.133 with SMTP id r5mr2756275icz.54.1335795125775; Mon, 30 Apr 2012 07:12:05 -0700 (PDT) Received: by 10.231.40.197 with HTTP; Mon, 30 Apr 2012 07:12:05 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E23AC3B@inba-mail01.sonusnet.com> References: <06bb01cd23d4$bcd5a790$3680f6b0$@packetizer.com> <387F9047F55E8C42850AD6B3A7A03C6C0E23AC3B@inba-mail01.sonusnet.com> Date: Mon, 30 Apr 2012 16:12:05 +0200 Message-ID: From: Laura Liess To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Paul E. Jones" , "insipid@ietf.org" , =?UTF-8?Q?Martin_H=C3=BClsemann?= , Hadriel Kaplan Subject: Re: [Insipid] Comment on REQ1, REQ6 and REQ7 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, 30 Apr 2012 14:12:07 -0000 Hi Partha, > REQ-6 is important to avoid using Session-id being used as rathole for passing any information. IMO, it is important. If I understand your point correctly, you don't want User A being able to transmit some critical information to User B in the Session-ID-header without the B2BUA between them being able to filter out this critical information. Is this correct? If yes, I would propose to modify the requirement to 1. "REQ6: The identifier must not reveal to the receiver of it the Call-ID, tags, or any other SIP header or body portion. " or restrict the requirements to end devices: 2. "REQ6: The identifier must not reveal to end devices that the Call-ID, tags, or any other SIP header or body portion have been changed by middleboxes." Can you live with one of these alternatives? Kind regards Laura > > Thanks > Partha > >>-----Original Message----- >>From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>Behalf Of Laura Liess >>Sent: Friday, April 27, 2012 6:48 PM >>To: Paul E. Jones >>Cc: insipid@ietf.org; Martin H=C3=BClsemann; Hadriel Kaplan >>Subject: Re: [Insipid] Comment on REQ1, REQ6 and REQ7 >> >>Paul, >> >>What I tried to say was that I think we can drop REQ6. REQ5 and REC1 are >>important for us. >> >>(Unfortunately, the was drawing which arrived at the mailing list was >>not what I intended to send. So the example is quite difficult to >>understand.) >> >>Kind regards >>Laura >> >> >>2012/4/26 Paul E. Jones : >>> Laura, >>> >>> I assume the desire for REQ6 relates to ensuring the kind of privacy >>that is afforded by SBCs. =C2=A0They can hide network topologies, peering >>relations, etc. =C2=A0This requirements suggests that we do not want thos= e >>things disclosed via the Session-ID. >>> >>> REQ7 is a means of assigning an ID when the endpoint does not. =C2=A0Th= at >>would perhaps mean one cannot inspect all the way to the endpoint, but >>one can at least track sessions to the assigning element. >>> >>> REQ1 seems conflicting on the surface, but one may not always have >>access into every segment everywhere. =C2=A0Those topologies and business >>relationships remain hidden. =C2=A0Even so, it's possible to perhaps have >>multiple people and organizations talking about the same Session-ID, >>regardless of what other data is changed. >>> >>> In short, I don't think it matters if something can determine changes >>made by the B2BUA if it's that something is in a position to do so >>(e.g., has physical access to all network segments), but the AS should >>not be able to see that Carrier A peered with Carrier B or some such or >>that the caller is using Mobile Operator C. >>> >>> Paul >>> >>>> -----Original Message----- >>>> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >>>> Sent: Thursday, April 26, 2012 9:50 AM >>>> To: insipid@ietf.org; Paul Jones; Hadriel Kaplan >>>> Cc: Martin H=C3=BClsemann >>>> Subject: Comment on REQ1, REQ6 and REQ7 >>>> >>>> Hi, >>>> >>>> What is the reason for having REQ6? =C2=A0Do we realy need it? It seem= s to >>>> me that it will be difficult to fulfill all REQ1 and REQ6 and REQ7 at >>>> the same time. >>>> >>>> Take the following scenario: >>>> >>>> =C2=A0 =C2=A0 ----------- >>>> ------------- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0------= ----- >>>> =C2=A0 =C2=A0| =C2=A0 =C2=A0A =C2=A0 =C2=A0 | ---------Call-ID x------= ---------------->| B2BUA >>>> |-------------Call-ID y------->| =C2=A0 =C2=A0AS =C2=A0 |-------- >>>> =C2=A0 =C2=A0 ----------- >>>> ------------- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Session-= ID z =C2=A0 =C2=A0----------- >>>> >>>> A is an end device that does not support Session-ID. =C2=A0AS is an >>>> Application Server and in the context of REQ6 the receiver of the >>>> Session-ID. The B2BUA changes the Call-ID from x to y and calculates >>a Session-ID z. >>>> By REQ1 and REQ7, an external device monitoring the SIP-traffic must >>>> be able to find out that messages with the Call-ID x and messages >>>> with the Session-ID z belong to the same session. So the B2BUA must >>>> build z as a function of x, let's say z =3DF(x) and the monitoring the >>>> B2BUA and the monitoring system have to know F. >>>> Otherwise, =C2=A0by REQ6, the AS is not allowed to know F, otherwise h= e is >>>> able to find out that z /=3D F(y). >>>> Maybe it is in theoreticaly possible for a network to have a for each >>>> node a different F and the the monitoring systems knowing which F to >>>> use for a call leg, but in practice this is probably too complex. >>>> >>>> Thanks, >>>> Laura >>> >>_______________________________________________ >>insipid mailing list >>insipid@ietf.org >>https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Mon Apr 30 10:33:37 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 82AE621F8862 for ; Mon, 30 Apr 2012 10:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 OlibQpKYOvD0 for ; Mon, 30 Apr 2012 10:33:36 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7418021F8855 for ; Mon, 30 Apr 2012 10:33:29 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta05.westchester.pa.mail.comcast.net with comcast id 4HPY1j0070vyq2s55HZVl0; Mon, 30 Apr 2012 17:33:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta05.westchester.pa.mail.comcast.net with comcast id 4HZV1j00l07duvL3RHZVxB; Mon, 30 Apr 2012 17:33:29 +0000 Message-ID: <4F9ECCE7.6020505@alum.mit.edu> Date: Mon, 30 Apr 2012 13:33:27 -0400 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: "insipid@ietf.org" References: <201204262006.q3QK6tXa007754@mtv-core-4.cisco.com> <4F99BA1E.4030406@alum.mit.edu> <4F9E7736.7050504@packetizer.com> In-Reply-To: <4F9E7736.7050504@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] INSIPID Req#4 - comments? 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, 30 Apr 2012 17:33:37 -0000 On 4/30/12 7:27 AM, Paul E. Jones wrote: > This is nothing more than an attempt to say that the identifier must not > be changed. We cannot send a "self destruct" messages to non-compliant > SBCs, of course, but we can say it is not supposed to be modified and we > certainly want to ensure it is possible to build a compliant device. So you are looking for a mechanism that has normative language that this not be changed? If so, then lets say so. Note that its going to be some work to figure out how to make such a normative statement. The problem is that we don't currently standardize the behavior of B2BUAs regarding how they connect the two sides. What you are calling for here would do that. I see no reason why we *can't* do that, but it will be new. But lets hear from Hadriel here, because I'm sure he will have a pragmatic opinion on this. Thanks, Paul > Paul > > On 4/26/2012 5:11 PM, Paul Kyzivat wrote: >> On 4/26/12 4:03 PM, James M. Polk wrote: >>> >>> REQ4: It must be possible to pass the identifier unchanged >>> through SIP B2BUAs or other intermediaries. >> >> I'm struggling with "possible" here. >> Its *possible* to pass the callid through unmodified. >> The problem is that it isn't guaranteed that it will go through >> unmodified. So ideally this would say something stronger, like: >> >> "the identifier MUST NOT be changed when passing through ..." >> >> But I think we all know it will be impossible to meet that. So we must >> be looking for something else. I think it is that the form of the >> identifier should not contain anything that can be easily correlated >> to the identity of either endpoint or to the topology of the network >> connecting them. >> >> Thanks, >> Paul >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > >