From internet-drafts@ietf.org Wed Jan 9 16:55:47 2013 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 4785C21F843A; Wed, 9 Jan 2013 16:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxFqW9KP1Lj4; Wed, 9 Jan 2013 16:55:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D50311E8097; Wed, 9 Jan 2013 16:55:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130110005518.20150.72719.idtracker@ietfa.amsl.com> Date: Wed, 09 Jan 2013 16:55:18 -0800 Cc: insipid@ietf.org Subject: [Insipid] I-D Action: draft-ietf-insipid-session-id-reqts-04.txt 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, 10 Jan 2013 00:55:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the INtermediary-safe SIP session ID Working = Group of the IETF. Title : Requirements for an End-to-End Session Identification in= IP-Based Multimedia Communication Networks Author(s) : Paul E. Jones Gonzalo Salgueiro James Polk Laura Liess Hadriel Kaplan Filename : draft-ietf-insipid-session-id-reqts-04.txt Pages : 11 Date : 2013-01-09 Abstract: This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id-reqts There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-insipid-session-id-reqts-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paulej@packetizer.com Wed Jan 9 18:23:25 2013 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 7541111E80DF for ; Wed, 9 Jan 2013 18:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbFsnM54kORq for ; Wed, 9 Jan 2013 18:23:24 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4D811E80D7 for ; Wed, 9 Jan 2013 18:23:24 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r0A2NMx1029641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 9 Jan 2013 21:23:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1357784603; bh=vrU9DTjoJxaAk5yBhi6QjgoXG4v+zadyEyEUupf90y0=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=HFpqYLsQomrzhSD7LhMuT2tcLYEDy1zMw3hAGfiPdsTkTs2KDZFw0BT37lqcSmQR0 qo0kf0yvw2QbM1B5RGkCfwwN0wE+zoqira/hlweSUbYkJIo6eeYH3cpclJl3ufLD70 uCESH0IKF5ncLNyjTHBb21+x2brleh2r3rfDoh4c= From: "Paul E. Jones" To: Date: Wed, 9 Jan 2013 21:23:55 -0500 Message-ID: <055801cdeed9$8b441060$a1cc3120$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0559_01CDEEAF.A26E5680" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3u2V1je1EsWv/sSryODfwvl+oqSw== Content-Language: en-us Subject: [Insipid] Are we ready to LC on the requirements? 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, 10 Jan 2013 02:23:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0559_01CDEEAF.A26E5680 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Folks, Dialog has been extremely light on the requirements document. Do people feel generally OK with it as it is now? Can we move on to the solution document now or are there other changes needed in the requirements document? I just posted the -04 version with changes proposed on the list over the past month or so. Paul ------=_NextPart_000_0559_01CDEEAF.A26E5680 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Folks,

 

Dialog has = been extremely light on the requirements document.  Do people feel = generally OK with it as it is now?  Can we move on to the solution = document now or are there other changes needed in the requirements = document?

 

I just posted the -04 version with changes proposed on = the list over the past month or so.

 

Paul

 

------=_NextPart_000_0559_01CDEEAF.A26E5680-- From gsalguei@cisco.com Thu Jan 10 12:38:37 2013 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 7C84D21F8835 for ; Thu, 10 Jan 2013 12:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ul7KEceNNGSs for ; Thu, 10 Jan 2013 12:38:36 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 4534D21F8716 for ; Thu, 10 Jan 2013 12:38:36 -0800 (PST) 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 r0AKcZCL023724 for ; Thu, 10 Jan 2013 15:38:35 -0500 (EST) Received: from rtp-gsalguei-8915.cisco.com (rtp-gsalguei-8915.cisco.com [10.116.132.54]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0AKcZSJ006151; Thu, 10 Jan 2013 15:38:35 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: <055801cdeed9$8b441060$a1cc3120$@packetizer.com> Date: Thu, 10 Jan 2013 15:38:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5F864ABC-E17F-44C9-8CDE-D6C5A32BF214@cisco.com> References: <055801cdeed9$8b441060$a1cc3120$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1283) Cc: insipid@ietf.org Subject: Re: [Insipid] Are we ready to LC on the requirements? 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, 10 Jan 2013 20:38:37 -0000 Thanks for submitting this, Paul. The biggest open issue in regards to = the requirements document was to clearly define what it is we are = identifying (i.e., "communication session") within the scope of this = document and ensure that clearly defined language is used consistently = throughout the document. Prior to any consensus on moving to WGLC, the = chairs would appreciate hearing the group's thoughts on where we are on = this issue in the current version.=20 Cheers, Gonzalo & Keith On Jan 9, 2013, at 9:23 PM, Paul E. Jones wrote: > Folks, > =20 > Dialog has been extremely light on the requirements document. Do = people feel generally OK with it as it is now? Can we move on to the = solution document now or are there other changes needed in the = requirements document? > =20 > I just posted the -04 version with changes proposed on the list over = the past month or so. > =20 > Paul > =20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From eckelcu@cisco.com Thu Jan 10 15:04:27 2013 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 E490721F8510 for ; Thu, 10 Jan 2013 15:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.379 X-Spam-Level: X-Spam-Status: No, score=-9.379 tagged_above=-999 required=5 tests=[AWL=1.220, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQs6Op-XDEFR for ; Thu, 10 Jan 2013 15:04:27 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7CE21F84F8 for ; Thu, 10 Jan 2013 15:04:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1743; q=dns/txt; s=iport; t=1357859067; x=1359068667; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BTH1gGlSw6hOF7fTvPFTau5F0vszxIEdI4q2SUquKBg=; b=PUZSmz9Opr+tzaKGdsRkvmTb4n5AzXYLAxAGHW2moJZ9CLbnM/VPtpPX cQ+vfEh2xsxGxYH8Q9/G7twV8w63D05BRB8w2X0qwuY3YooCi2AyyXjAz Z3OG2YSBDl791NlDONWl0N7HvKt801tDTndtMdtNmlYu3kSZXujqwlJ8z c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAExI71CtJV2Y/2dsb2JhbABEvXUWc4IeAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgBAQQBDQUIE4d9AQy0WASQPmEDplOCdYIk X-IronPort-AV: E=Sophos;i="4.84,447,1355097600"; d="scan'208,223";a="161164879" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 10 Jan 2013 23:04:23 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0AN4Ng3025578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jan 2013 23:04:23 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.224]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 10 Jan 2013 17:04:23 -0600 From: "Charles Eckel (eckelcu)" To: "Gonzalo Salgueiro (gsalguei)" , "Paul E. Jones" Thread-Topic: [Insipid] Are we ready to LC on the requirements? Thread-Index: Ac3u2V1je1EsWv/sSryODfwvl+oqSwAy2DqAAAeXbmA= Date: Thu, 10 Jan 2013 23:04:22 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882804728936@xmb-aln-x08.cisco.com> References: <055801cdeed9$8b441060$a1cc3120$@packetizer.com> <5F864ABC-E17F-44C9-8CDE-D6C5A32BF214@cisco.com> In-Reply-To: <5F864ABC-E17F-44C9-8CDE-D6C5A32BF214@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "insipid@ietf.org" Subject: Re: [Insipid] Are we ready to LC on the requirements? 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, 10 Jan 2013 23:04:28 -0000 >From my point of view, the draft looks good. The changes incorporated in th= is updated version directly address this open issue.=20 Cheers, Charles > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Gonzalo Salgueiro (gsalguei) > Sent: Thursday, January 10, 2013 12:39 PM > To: Paul E. Jones > Cc: insipid@ietf.org > Subject: Re: [Insipid] Are we ready to LC on the requirements? >=20 > Thanks for submitting this, Paul. The biggest open issue in regards to t= he > requirements document was to clearly define what it is we are identifying > (i.e., "communication session") within the scope of this document and > ensure that clearly defined language is used consistently throughout the > document. Prior to any consensus on moving to WGLC, the chairs would > appreciate hearing the group's thoughts on where we are on this issue in > the current version. >=20 > Cheers, >=20 > Gonzalo & Keith >=20 >=20 >=20 > On Jan 9, 2013, at 9:23 PM, Paul E. Jones wrote: >=20 > > Folks, > > > > Dialog has been extremely light on the requirements document. Do > people feel generally OK with it as it is now? Can we move on to the > solution document now or are there other changes needed in the > requirements document? > > > > I just posted the -04 version with changes proposed on the list over th= e > past month or so. > > > > Paul > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Fri Jan 11 12:34:13 2013 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 78CD021F873D for ; Fri, 11 Jan 2013 12:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.115 X-Spam-Level: X-Spam-Status: No, score=-0.115 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnJxMXlvewSz for ; Fri, 11 Jan 2013 12:34:12 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 5E59E21F892B for ; Fri, 11 Jan 2013 12:34:12 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id mcDL1k00D0cZkys53kaBsq; Fri, 11 Jan 2013 20:34:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id mkaB1k00Z3ZTu2S3WkaBBZ; Fri, 11 Jan 2013 20:34:11 +0000 Message-ID: <50F07742.3030601@alum.mit.edu> Date: Fri, 11 Jan 2013 15:34:10 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: insipid@ietf.org References: <055801cdeed9$8b441060$a1cc3120$@packetizer.com> <5F864ABC-E17F-44C9-8CDE-D6C5A32BF214@cisco.com> <92B7E61ADAC1BB4F941F943788C0882804728936@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882804728936@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357936451; bh=d7UD4bLaskuv2TgO2UMbfc6NRgwSZGRxntHDrpZfGtA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QbhtsWENXpVVL1MSs/jdMzKRgpQOC8e3xrBxtBE043xu/qTc5OhXLSJQqwW6gcOlw //jM2GALVnxEDaS86iDtOETdt7qEdStqmePRU4CH0Yzt49S4aDOvBl5XEet2eTXgQW 7wThtzVSvKwf3+hBT3NNBTKICKnzu7yFJWBKRNjmvVbr+2zmWMXXJtVs/vr9VZ1/w9 mTVxG9WYv5w89ziInhPhW+t+LjZZYQiDsuse3IbHOx52Aw8zWO7jlDJ1Ux4Of43u3T 9BmPnzwCFnBGECc4/nbUdGOuOH/GA+u9bGG6R5oeyXfCQlHrJUqDNUP2nGvuQRCup4 16wGQhFuu8FmQ== Subject: Re: [Insipid] Are we ready to LC on the requirements? 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, 11 Jan 2013 20:34:13 -0000 (Sorry that this is long. I don't know how to make it short.) Are we ready to LC? I don't think so. Specifically I don't think we yet have an unambiguous definition of what is being identified. This version added some new text: In this document, the word "session" refers to a "communication session" that may exist between two SIP user agents and that may pass through one or more intermediary devices, including B2BUAs or SIP proxies. A communication session consists of one of more SIP transactions. A very simple communication session may be a single out-of-dialog SIP transaction (e.g., MESSAGE/200). In the case of a SIP dialog, the SIP message exchange includes a dialog creating INVITE transaction, and zero of more subsequent SIP transactions within the same dialog (e.g., ACK, re-INVITE, BYE). Due to the existence of middle boxes, there may be multiple related SIP transactions or dialogs chained together along the path from one end of the communication session to the other. For example: A Middlebox B SIP trans1 -----------------> SIP trans 2 SIP dialog 1 <-------------- SIP dialog 2 Figure 1 - Communication Session through a Middlebox In such cases, the two SIP transactions or dialogs are part of a single communication session. The term "end-to-end" in this document means the communication session from the point of origin, passing through any number of intermediaries, to the ultimate point of termination. It is recognized that legacy devices may not support the "end-to-end" session identifier, though an identifier might be created by an intermediary when it is absent from the session signaling. IMO this is a big improvement. But it still isn't as precise as I would like. What I find lacking in the above is: o parsing the above, the properties of a communication session are: - connects *two* UAs - optionally includes one or more intermediary devices - one or more transactions - one out-of-dialog transaction, OR a dialog including the dialog establishing transaction and some transactions within the dialog. - middle boxes may result in chaining dialogs or transactions. Exactly how all these properties "plug together" fuzzy. I'm not at all certain that all readers would reach the same conclusion about which cases meet these criteria and which don't. o I'm also not certain that these criteria match all the cases people expect, and exclude all the cases people think should be excluded. - I think people expect that a conference is *not* a single communications session. But a conference with only two participants would seem to qualify according to all of the above criteria. So that suggests that another criterion is needed to exclude that case. - A topologically similar case to the conference is a click-to-dial case where a web server makes outward INVITEs to two UAs and connects them. I think people believe this case *should* be a communications session. - Another case is described in http://www.ietf.org/mail-archive/web/insipid/current/msg00429.html and debated in the replies to that. Arguments are made for different answers to what should get a common session id and what should not. For this case I think we need to decide: . do we mandate exactly how this should be treated? . or do we leave it to the discretion of the B2BUA to decide? Either way we need to decide what the criteria are that lead to the decision. o IIRC Hadriel suggested (in a meeting?) that where media originates and terminates has something to do with this. That doesn't work all the time (e.g. MESSAGE), but it might help in some cases. I think he used this to justify that: - the Conference Bridge Transcoding Model (RFC5369 section 3.2) is a single communications session. - the 3PCC Transcoding Model (RFC5369 section 3.1) is *not* a single communications session. (I'm not convinced - this seems like a distinction without a difference.) Fundamentally we should be able to classify all cases into: - those that *should* be communications sessions, - those that *shouldn't* be communication sessions, - those we don't care about - could be either way. When we are done, we should be able to apply the definition of communication session to any case. When applied to the cases we explicitly care about it should deliver the answer we expect. The more weird cases we care about, the more complex and unintuitive the criteria will be. I suspect that the path we are on will lead to complex criteria. (We can have a really crisp definition of communications session if we don't care much about which cases qualify.) One idea I considered is to define some new terms that build on normal sip concepts but extend them to allow B2BUA intermediaries where sip allows proxies. E.g. - Transaction++ is either a sip transaction, or a series of sip transactions linked by B2BUA intermediaries. - Dialog++ is either a sip dialog, or a series of sip dialogs linked by B2BUA intermediaries. Then would need to define the behavior of a B2BUA intermediary. It needs to relay transactions from one "side" to the other, preserving certain invariants (TBD). Presumably it can also originate certain transactions, but there must be constraints on what it can do. There must also be some rules on how media is handled across one of these intermediaries. If that was done, then a communication session could be defined as a Transaction++ for an out-of-dialog request, or a Dialog++. But that makes the definition of communication session the first priority and the cases that happen to qualify as a communication session a consequence. It probably won't match people's intuitive feelings about what *should* be a communication session. So it might not satisfy people. Thanks, Paul On 1/10/13 6:04 PM, Charles Eckel (eckelcu) wrote: >>From my point of view, the draft looks good. The changes incorporated in this updated version directly address this open issue. > > Cheers, > Charles > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf Of Gonzalo Salgueiro (gsalguei) >> Sent: Thursday, January 10, 2013 12:39 PM >> To: Paul E. Jones >> Cc: insipid@ietf.org >> Subject: Re: [Insipid] Are we ready to LC on the requirements? >> >> Thanks for submitting this, Paul. The biggest open issue in regards to the >> requirements document was to clearly define what it is we are identifying >> (i.e., "communication session") within the scope of this document and >> ensure that clearly defined language is used consistently throughout the >> document. Prior to any consensus on moving to WGLC, the chairs would >> appreciate hearing the group's thoughts on where we are on this issue in >> the current version. >> >> Cheers, >> >> Gonzalo & Keith >> >> >> >> On Jan 9, 2013, at 9:23 PM, Paul E. Jones wrote: >> >>> Folks, >>> >>> Dialog has been extremely light on the requirements document. Do >> people feel generally OK with it as it is now? Can we move on to the >> solution document now or are there other changes needed in the >> requirements document? >>> >>> I just posted the -04 version with changes proposed on the list over the >> past month or so. >>> >>> Paul >>> >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From jmpolk@cisco.com Fri Jan 11 13:55:09 2013 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 4AE9C21F8A52 for ; Fri, 11 Jan 2013 13:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SNx+OpiUj3v for ; Fri, 11 Jan 2013 13:55:07 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C8B6221F86C9 for ; Fri, 11 Jan 2013 13:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6629; q=dns/txt; s=iport; t=1357941307; x=1359150907; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=guAx53buCvhdC38A1iBB3mAdgJnC7Ot736lx8UzvqLU=; b=fj8UbjSbw/Bh3mx/t0tYNP8c7ClZ4qw/czTeG8UJsArX+FbEiOe41mvG wcbFEZu5rfYvFzylqBo3jlpTORoVwOtU42bNux5Q+TtSIgRYnR+3e4xjw cW281wt0tSpY0LIE85IS1pVCNxrGzsE3Bs0EP0bftElXsoiAICNMqePHj g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAN6J8FCtJXHA/2dsb2JhbABEvgIWc4IeAQEBAwEBAQEkEQIuBgsFBwQHBBEEAQEBCRUJBw8KDh8JCAYBEhuHeAYMtkcEjGMLhDgDiGGdc4MUgVA X-IronPort-AV: E=Sophos;i="4.84,453,1355097600"; d="scan'208";a="161542704" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 11 Jan 2013 21:55:05 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) (authenticated bits=0) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0BLt5Ss001896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jan 2013 21:55:05 GMT Message-Id: <201301112155.r0BLt5Ss001896@rcdn-core2-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 11 Jan 2013 15:55:04 -0600 To: "'Brett Tate'" , From: James Polk In-Reply-To: <002101cdc7af$4a892ac0$df9b8040$@packetizer.com> References: <576A8B541C219D4E9CEB1DF8C19C7B880239BA@MBX06.citservers.local> <002101cdc7af$4a892ac0$df9b8040$@packetizer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: "Paul E. Jones" Subject: Re: [Insipid] Session-ID when B2BUA forks INVITE for audio and video to different locations 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, 11 Jan 2013 21:55:09 -0000 Brett Not trying to compound this scenario you have (and sorry for being late to the party, but PK's message pointed me towards yours - and I realized I had missed it while out on PTO), but I have a different angle/take on Paul Jones's series of questions (that have not been answered yet, BTW). In your diagram, which I'll recreate here > Session-ID > ---- Alice B2BUA Bob-phone Bob-computer > {A} |---INVITE--->| | | > {A} | |---INVITE-->| | > {A} | |---INVITE------------->| > {Bp,A} | |<--200 OK---| | > {Bc,A} | |<--200 OK--------------| > {Bp,A} |<--200 OK----| | | > {A,Bp} |-----ACK---->| | | > {A,Bp} | |---ACK----->| | > {A,Bc} | |---ACK---------------->| Why is there a Bp and not a B? I mean, B is all Alice is every going to see, and the B2BUA has to be in charge of this recording by transmitting a nearly replicative INVITE to Bob's computer, right? What header-values are changed in the INVITE transaction to and from Bob's computer relative to that of the transaction to and from the phone? - The R-URI can't be the same. - the Via can't be the same. - the To can't be the same. - the From can't be the same? - is the CSeq the same? - the Contact can't be the same. - is the SDP the same, given that the media packets are to be going through the B2BUA? I suspect that this is an entirely new transaction with new/different header-values, and not merely a different Session-ID header-value. Not knowing SIPREC as well as I should, does this INVITE to Bob's computer need to be in parallel like the call flow shows? For example could it be like this instead? > Session-ID > ---- Alice B2BUA Bob-phone Bob-computer > {A} |---INVITE--->| | | > {A} | |---INVITE-->| | > {B,A} | |<--200 OK---| | > {B,A} |<--200 OK----| | | > {A,B} |-----ACK---->| | | > {A,B} | |---ACK----->| | > {A} | |---INVITE------------->| > {Bc,A} | |<--200 OK--------------| > {A,Bc} | |---ACK---------------->| James At 12:13 AM 11/21/2012, Paul E. Jones wrote: >Brett, > >Well, this is certainly different. Does the phone ring? Does the computer >ring? Does the user independently answer each one of those devices? And >what would happen if the PC has only audio? I assume only the B2BUA knows >the capabilities of devices in advance? > >Basically, what we have on the right-hand side of the B2BUA is two >completely independent SIP sessions that are more-or-less "conferenced" via >the B2BUA. The media might be going directly to the endpoints, but it is >still very much like a conference server where there is Alice, Bob, and >Carol all in a conference. > >So, given that, I would expect to see these three Session-IDs: >{A,F} - Session ID between Alice and the B2BUA (F) >{F,Bp} - Session ID between the B2BUA and Bob's phone >{F,Bc} - Session ID between the B2BUA and Bob's computer > >This means there are three unique identifiers, but there still exists the >possibility to correlate the calls since F is in common across all sessions. > >There are limits to the utility of having F in all sessions. For example, A >is not present anywhere on the right-hand side. If A happened to be an MCU >that had 100 calls in conference, it might be possible to relate all the >sessions on the left side of the B2BUA, but the diagnostic / monitoring >equipment looking at the right side would never see A. Thus, it's not >perfect. Even so, I think that approach would provide a "better than >nothing" solution. > >Paul > > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf Of Brett Tate > > Sent: Tuesday, November 13, 2012 3:20 PM > > To: insipid@ietf.org > > Subject: [Insipid] Session-ID when B2BUA forks INVITE for audio and > > video to different locations > > > > Hi, > > > > What Session-ID should be communicated when a B2BUA forks a video call > > so INVITE for audio and INVITE for video go to different locations? For > > instance, the INVITE for video is sent the computer and INVITE for audio > > is sent to the phone. > > > > The concept is mentioned within draft-ietf-straw-b2bua-taxonomy-00 > > section 3.1.3. > > > > The following uses draft-jones-insipid-session-id-01 to indicate > > Session-ID. Hopefully the picture doesn't get too corrupted. > > > > Session-ID > > ---- Alice B2BUA Bob-phone Bob-computer > > {A} |---INVITE--->| | | > > {A} | |---INVITE-->| | > > {A} | |---INVITE------------->| > > {Bp,A} | |<--200 OK---| | > > {Bc,A} | |<--200 OK--------------| > > {Bp,A} |<--200 OK----| | | > > {A,Bp} |-----ACK---->| | | > > {A,Bp} | |---ACK----->| | > > {A,Bc} | |---ACK---------------->| > > > > Is this the expected use of draft-jones-insipid-session-id-01? Note: Bc > > does not get communicated to Alice and the B2BUA adjusts the Session-ID > > before sending ACK to Bob-computer. > > > > There is a similar call flow when Bob-phone originates a call to Alice. > > Bob-computer is pulled into the call setup so both audio and video can > > be offered to Alice. However, I will ask about that one later. > > > > Thanks, > > Brett > > > > This email is intended solely for the person or entity to which it is > > addressed and may contain confidential and/or privileged information. If > > you are not the intended recipient and have received this email in error, > > please notify BroadSoft, Inc. immediately by replying to this message, > > or by sending an email to helpdesk@broadsoft.com, and destroy all copies > > of this message, along with any attachment, prior to reading, > > distributing or copying it. > > _______________________________________________ > > 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 keith.drage@alcatel-lucent.com Fri Jan 11 15:00:07 2013 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 E4BED21F892B for ; Fri, 11 Jan 2013 15:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.799 X-Spam-Level: X-Spam-Status: No, score=-106.799 tagged_above=-999 required=5 tests=[AWL=-2.850, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df6YfLnqV6Lp for ; Fri, 11 Jan 2013 15:00:05 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 43B8821F8855 for ; Fri, 11 Jan 2013 15:00:04 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0BN00fV004833 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 12 Jan 2013 00:00:00 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sat, 12 Jan 2013 00:00:00 +0100 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Fri, 11 Jan 2013 23:59:59 +0100 Thread-Topic: Belated IETF 85 INSIPID meeting notes Thread-Index: Ac3wT2FaWyuEfm+pRVSJWxh5f7nsXw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [Insipid] Belated IETF 85 INSIPID meeting notes 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, 11 Jan 2013 23:00:07 -0000 The following are the notes for the INSIPID meeting held at IETF 85. Apologies for the lateness of producing these. Thanks to both Roland Jesske and Alan Johnson for being scribes in the meet= ing. Regards Keith -------------------------------------------- IETF-85, Atlanta, GA, USA INtermediary-safe SIP session ID (INSIPID) WG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Chairs: Gonzalo Salgueiro (gsalguei@cisco.com) Keith Drage (keith.drage@alcatel-lucent.com) =20 MONDAY, November 5, 2012, 15:20-17:20 (Room 209) Introduction and Status Update ------------------------------ - Agenda bash, Note Well, notetakers and jabber scribes, etc. - WG status since IETF84 in Vancouver - Action items, milestone dates, etc. Discussion of requirements draft -------------------------------- (Paul Jones) draft-ietf-insipid-session-id-reqts-02.txt - Changes since IETF84 in Vancouver - Dealing with transfer requirement (chairs to lead this) - Other open issues? - Ready for WGLC? Paul presented the changes of draft since the -00 version and planned edito= rials for version -03 and use cases 1-7 Robert: We need a definition of what the session-id should solve. discussion about definition of communication session discussion about other terminology in draft Functional description could be used for definition what session-id is. Polk: he has the same problem Robert: Don't define session define the thing what you want to have. Keith: why not in real document, i.e. the solution document. Robert: needed to be in the requirements document due to the fact that here= it is needed to be clear what should be solved. Christer: All the terms used (e.g. dialog, session ect) needs consolidation= and correction. =20 Hadriel: Commenting on what the Id should be used for. It is not just sessi= on it is more dialog because of the use in REFER or REGISTER. Paul J.: Problem known, and corrected description needed. - Paul wants to allow inclusion in RTCP, but not define how to do it Gonzalo: Asked for RTCP/RVPT Keith: Was agreed to be in the scope. Gonzalo: Ask for opinion now.=20 Robert wants requirement for identifier to be small enough to include in da= tagrams Keith: Asks now if Requirement 9c (which reflects this option) needs to be = removed (as Gonzalo requested). Gonzalo: This WG was founded under the circumstances to have at least a min= imal solution that works. Hadriel: Clarified that Requirement 9c is about explicit as a syntactical r= equirement. So this must be covered by the text. This was agreed. Decision of meeting: Requirement 9c must be reworded to reflect the syntact= ical requirement. Chairs: Gonzalo and Paul work on text to replace REQ-9C and post to list. Paul Jones: All other requirements are stable. Discussion on Call Transfer-3 Slide Chairs described outcome of virtual interim discussion and list discussion = on this topic. Gonzalo: Middle two bullets needs at least the definition what we want to h= ave. (As already discussed earlier) Robert: With that proposed text it is not intended to be a session. Paul J.: Yes that will be a Session. Robert: Then we need more text to describe this explicitly. Because it is n= ot covered now by the text. Paul K.: Call Transfer is splicing two half Calls together. We are talking = about call legs. If we have a path of multiple B2BUA. So we have to splice = a couple of dialogs together. Hadriel: Assumes that you want to have to track the media. So in case of tr= ansferring the call is not an issue of the signalling but more an issue of = the media. So the signalling is not in interest. Paul J.: We want to look on the signalling in such cases of transfer. That = it could be tracked. We want to see the correlation of the signalling. We w= ant to see the call from A to B to C to D ect. Hadriel: A-B and A-C a Call will be transferred to B-C. But you want to tra= ck the media. Keith: But that is not in the requirements. So this is only needed for sign= alling. James Polk: The B2BUA are not to be supposed to change the UUID / Session-I= d. Session-Id should correlate two sessions seen from each end. Christer: Proposes that this is the solution that correlates dialogs. Keith: Which entities need to know that? Christer: Issue of operator / service provider. Paul K.: We are talking about structures, stars and meshes. So we do not kn= ow how to solve such constructions. We need to define what is needed also t= o such kind of scenarios. Example PBX-A and PBX-B are connected and each PB= X can transfer that call. Gonzalo: Distinguish between scenarios where the identifier needs to be the= same and where it needs to be different. Robert: Asks the A-B / A-C transfer to B-C scenario. Which identifiers are = needed? James: We want to correlate in transfer cases. He want to see the id to be = used to see how the transfer happens. Keith: Who needs to know about the transfer. The magic in the middle that i= s neither A/B or C? Hadriel: What is in cases when you do conferences instead of transfer? What= is needed? Paul-J: Session-id A-B, A-C is needed in that case. Hadriel: Session-id will not be passed by SBC then? Robert: Do we have a Requirement that the ID is to be unspoofable? Paul-J: The use of UUID was chosen to be unique. Are we using the id for charging purposes? Answer: NO Hadriel: It is not for billing so seen from this point of view there are no= security concerns. Mary: Asked if this is an idea to be used for billing.=20 Conclusion: It should be forbidden. Robert: Can I use this to do a bad thing that somebody else can be treated.= =20 Answer: No Paul K.: The endpoints want to care about the ID. (This concludes: As long = as it is used and inserted by end devices). Keith/James: Please sent text to improve that Call Transfer case. Also to h= ave the text what we want to do. Chairs: no conclusion. Need to focus on actual requirement. Please send re= al text to the list. Chairs: -03 will be issued with changes discussed including Gonzalo's text = about syntax. Review and discussion of proposed solution ------------------------------------------ draft-jones-insipid-session-id-01.txt - Summary of changes since -00 version (Paul) - Backwards compatibility update in latest version (Christer) - Review and Discussion of session id call flows - Ready to adopt text as WG doc? James Polk presenting. James: presents changes of 00 to 01. Robert: You do not explore what happens if one of the entities middle/end d= oes not understand the ID. James: Proposes an open section to work on that. Robert: You have used a MUST NOT for adding the ID and in other sections to= mandate that ID. So here a correlation and clarification in the text is ne= eded. Christer Holmberg presenting. Christer: Presents the need to have a backward compatibility mechanism. Syn= tax must be backward compatible. Usage: What happens when a version 1 UAC interacts with a UAS Version 2 and= vice versa. James: Aggress on the approach. Paul-K: The old version should be released as an historical document. Robert: Make it as a company document. Marry: Asking for checking the old implementations if they do not crash. Keith: Concludes to update that the draft will be updated to be backwards c= ompatible. Nobody in the room objected against that the draft-jones-insipid-session-id= -01.txt describes backward compatibility to the session-id as defined in th= e Kaplan draft (draft-kaplan-dispatch-session-id). Chairs - Any objections to the backwards compatibility as described in -01 version - No objections noted. Decision: to keep the new draft backwards compatible with regard to draft-k= aplan-dispatch-session-id James Polk presenting the changes within the draft ABNF presentation was discussed on the list and seems to be OK. Andrew: What was the reasoning to change the ordering in consideration of b= ackward compatibility? James: The order is not important. What is needed is appearing as two value= s. Gonzalo: It is not really clear what the re-INVITES are doing. So clarifica= tion is needed. Conclusion/Decision: Call Flow of presentation will be put into the draft. Gonzalo: differentiate about the entities which correlate and which are put= ting in the ID (UUID) Paul-K: Questions in which cases the values should flip? Conclusion was that this appears in Requests equivalent to the mechanism us= ed for "from" and "to" header. Christer: Asked for documentation of the reasoning of rowing of the ID's. Christer: Asked for keeping the rowing in the Response: =E0 Keith: Take thi= s to the list. Christer: Asked for consistency. New document is promised one week after meeting. Decision: After that it will be asked for adoption of draft on the mailing = list. Wrap-up ------- (Chairs) - Next steps, action items, etc. - Are more virtual interims needed? Chairs: Authors will revise solution draft Chairs: We will have a call for adoption of the revised draft by end of November From brett@broadsoft.com Sun Jan 13 11:27:32 2013 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 0060521F86AE for ; Sun, 13 Jan 2013 11:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAmvrNaaHDvj for ; Sun, 13 Jan 2013 11:27:31 -0800 (PST) Received: from smtpout01.partnerhosted.com (unknown [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id 5267521F86A1 for ; Sun, 13 Jan 2013 11:27:31 -0800 (PST) Received: from CASUMHUB04.citservers.local (172.16.98.225) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 13 Jan 2013 11:28:47 -0800 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Sun, 13 Jan 2013 11:28:47 -0800 From: Brett Tate To: James Polk , "insipid@ietf.org" , "Paul E. Jones" Thread-Topic: [Insipid] Session-ID when B2BUA forks INVITE for audio and video to different locations Thread-Index: AQHN8EZ/IefJuOgnJEGM18xq2iKFLZhHku9A Date: Sun, 13 Jan 2013 19:28:46 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88032779@MBX06.citservers.local> References: <576A8B541C219D4E9CEB1DF8C19C7B880239BA@MBX06.citservers.local> <002101cdc7af$4a892ac0$df9b8040$@packetizer.com> <201301112155.r0BLt5Ss001896@rcdn-core2-5.cisco.com> In-Reply-To: <201301112155.r0BLt5Ss001896@rcdn-core2-5.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] Session-ID when B2BUA forks INVITE for audio and video to different locations 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, 13 Jan 2013 19:27:32 -0000 Thanks for responses. Reply is inline. > Paul Jones's series of questions (that have not been > answered yet, BTW). My apologies. The reply is also inline. > In your diagram, which I'll recreate here >=20 > > Session-ID > > ---- Alice B2BUA Bob-phone Bob-computer > > {A} |---INVITE--->| | | > > {A} | |---INVITE-->| | > > {A} | |---INVITE------------->| > > {Bp,A} | |<--200 OK---| | > > {Bc,A} | |<--200 OK--------------| > > {Bp,A} |<--200 OK----| | | > > {A,Bp} |-----ACK---->| | | > > {A,Bp} | |---ACK----->| | > > {A,Bc} | |---ACK---------------->| >=20 > Why is there a Bp and not a B? I didn't think that the draft provided the B2BUA the flexibility to reclass= ify the service to fall into a conferencing classification so that it would= n't need to relay Bp or Bc. More specifically, this B2BUA service modifies= the SDP; however it does not send/receive media. > I mean, B is all Alice is every going to see,=20 > and the B2BUA has to be in charge of this recording=20 > by transmitting a nearly replicative INVITE to=20 > Bob's computer, right? This isn't a recording service; the B2BUA does not see the media. It is a = service to break apart the SDP so that audio is offered to the phone and vi= deo is offered to the computer. > What header-values are changed in the INVITE=20 > transaction to and from Bob's computer relative=20 > to that of the transaction to and from the phone? Excluding any current/future restrictions placed upon B2BUAs, it is mostly = at the discretion of the B2BUA. > - The R-URI can't be the same. > - the Via can't be the same. > - the To can't be the same. > - the From can't be the same? > - is the CSeq the same? It at the discretion of the B2BUA. > - the Contact can't be the same. > - is the SDP the same, given that the media packets > are to be going through the B2BUA? The media packets do not go through the B2BUA. The SDP is different. > I suspect that this is an entirely new transaction with new/different > header-values, and not merely a different Session-ID header-value. > Not knowing SIPREC as well as I should, does this INVITE to Bob's > computer need to be in parallel like the call flow shows? It is not required; however it simplifies the SDP offer/answer exchanges. > For example could it be like this instead? Not exactly; the B2BUA will need to provide Bob's video answer SDP to Alice= . > > Session-ID > > ---- Alice B2BUA Bob-phone Bob-computer > > {A} |---INVITE--->| | | > > {A} | |---INVITE-->| | > > {B,A} | |<--200 OK---| | > > {B,A} |<--200 OK----| | | > > {A,B} |-----ACK---->| | | > > {A,B} | |---ACK----->| | > > {A} | |---INVITE------------->| > > {Bc,A} | |<--200 OK--------------| > > {A,Bc} | |---ACK---------------->| >=20 > James >=20 > At 12:13 AM 11/21/2012, Paul E. Jones wrote: > > Brett, > > > > Well, this is certainly different. Does the phone ring? Yes; however I guess that it actually depends upon other services and confi= guration. > > Does the computer ring? =20 Yes; however I guess that it actually depends upon other services and confi= guration. > > Does the user independently answer each one of those devices? Yes; however I guess that it actually depends upon other services and confi= guration. > > And what would happen if the PC has only audio? It would reject the offer with 488 or 606. > > I assume only the B2BUA knows the capabilities of=20 > > devices in advance? It can know the capabilities; however the B2BUA is mostly just acting per s= ervice configuration. From jmpolk@cisco.com Mon Jan 14 16:37:23 2013 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 95F5421F8B38 for ; Mon, 14 Jan 2013 16:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUMmFkgLbpxk for ; Mon, 14 Jan 2013 16:37:22 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABCE21F8B2F for ; Mon, 14 Jan 2013 16:37:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5772; q=dns/txt; s=iport; t=1358210242; x=1359419842; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=aFDxxjpKXJQTh82EleKqE+HtgFqZoFJdFHs9ymEpqww=; b=F39ZeuwPMRgfXMu/2uDNxmzw98kdDwLWoZpa5nff7qMrrVoxE1M3Px5q EIoSs/KuI0Viv7ZJbTQfTKW3xI/FwPTEwv7vso7FwKFCZqOXXp+EXbnl6 SfAD1VJqMCK3gzPNI2zWP1K5v3zOUXWZCj01GnDFGNvlahu+Kh5WgmMnP Q=; X-IronPort-AV: E=Sophos;i="4.84,469,1355097600"; d="scan'208";a="162407003" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 15 Jan 2013 00:37:22 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) (authenticated bits=0) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0F0bLlC000647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jan 2013 00:37:21 GMT Message-Id: <201301150037.r0F0bLlC000647@rcdn-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Jan 2013 18:37:20 -0600 To: Brett Tate , James Polk , "insipid@ietf.org" , "Paul E. Jones" From: James Polk In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88032779@MBX06.citservers.lo cal> References: <576A8B541C219D4E9CEB1DF8C19C7B880239BA@MBX06.citservers.local> <002101cdc7af$4a892ac0$df9b8040$@packetizer.com> <201301112155.r0BLt5Ss001896@rcdn-core2-5.cisco.com> <576A8B541C219D4E9CEB1DF8C19C7B88032779@MBX06.citservers.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [Insipid] Session-ID when B2BUA forks INVITE for audio and video to different locations X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 00:37:23 -0000 At 01:28 PM 1/13/2013, Brett Tate wrote: >Thanks for responses. Reply is inline. > > > Paul Jones's series of questions (that have not been > > answered yet, BTW). > >My apologies. The reply is also inline. > > > In your diagram, which I'll recreate here > > > > > Session-ID > > > ---- Alice B2BUA Bob-phone Bob-computer > > > {A} |---INVITE--->| | | > > > {A} | |---INVITE-->| | > > > {A} | |---INVITE------------->| > > > {Bp,A} | |<--200 OK---| | > > > {Bc,A} | |<--200 OK--------------| > > > {Bp,A} |<--200 OK----| | | > > > {A,Bp} |-----ACK---->| | | > > > {A,Bp} | |---ACK----->| | > > > {A,Bc} | |---ACK---------------->| > > > > Why is there a Bp and not a B? > >I didn't think that the draft provided the B2BUA the flexibility to >reclassify the service to fall into a conferencing classification so >that it wouldn't need to relay Bp or Bc. More specifically, this >B2BUA service modifies the SDP; however it does not send/receive media. > > > I mean, B is all Alice is every going to see, > > and the B2BUA has to be in charge of this recording > > by transmitting a nearly replicative INVITE to > > Bob's computer, right? > >This isn't a recording service; the B2BUA does not see the media. I obviously misinterpreted the flow's intent. >It is a service to break apart the SDP so that audio is offered to >the phone and video is offered to the computer. What if one endpoint is available and the other is not? I'm sure folks can imagine audio without video, but is video without audio acceptable? > > What header-values are changed in the INVITE > > transaction to and from Bob's computer relative > > to that of the transaction to and from the phone? > >Excluding any current/future restrictions placed upon B2BUAs, it is >mostly at the discretion of the B2BUA. If the B2BUA isn't in the media path, this is taking one INVITE and turning into two INVITE's, one of which doesn't get the benefit of having any feedback. Imagine an INVITE from Alice with two audio codecs and two video codecs. This INVITE is split how you say it is. The B2BUA cannot return a second "final response" (200 OK) with Bob's computer UA's "answer". That presents an unworkable offer/answer exchange. > > - The R-URI can't be the same. > > - the Via can't be the same. > > - the To can't be the same. > > - the From can't be the same? > > - is the CSeq the same? > >It at the discretion of the B2BUA. I'm thinking that this second INVITE is a whole new INVITE with new header-values in each header in the request. > > - the Contact can't be the same. > > - is the SDP the same, given that the media packets > > are to be going through the B2BUA? > >The media packets do not go through the B2BUA. The SDP is different. > > > I suspect that this is an entirely new transaction with new/different > > header-values, and not merely a different Session-ID header-value. > > Not knowing SIPREC as well as I should, does this INVITE to Bob's > > computer need to be in parallel like the call flow shows? > >It is not required; however it simplifies the SDP offer/answer exchanges. > > > For example could it be like this instead? > >Not exactly; the B2BUA will need to provide Bob's video answer SDP to Alice. For every SIP request, there can be only one final response, therefore this B2BUA (in the signaling path only) will have to eat/consume/terminate/'not send on' any additional final responses received within this transaction. While I agree the message flow below isn't right (I thought you were describing a SIPREC flow), you're gonna have a hard time reconciling this 'alice has to receive a second SDP from bob's computer' issue. In SIP, there's forking and then there's conferencing. What you're describing is a hybrid, and not standard. IMHO, we here in INSIPID shouldn't take on the additional scope that this would entail. However, I've been wrong about what Brett's tried to convey once before. I could be wrong again. James > > > Session-ID > > > ---- Alice B2BUA Bob-phone Bob-computer > > > {A} |---INVITE--->| | | > > > {A} | |---INVITE-->| | > > > {B,A} | |<--200 OK---| | > > > {B,A} |<--200 OK----| | | > > > {A,B} |-----ACK---->| | | > > > {A,B} | |---ACK----->| | > > > {A} | |---INVITE------------->| > > > {Bc,A} | |<--200 OK--------------| > > > {A,Bc} | |---ACK---------------->| > > > > James > > > > At 12:13 AM 11/21/2012, Paul E. Jones wrote: > > > Brett, > > > > > > Well, this is certainly different. Does the phone ring? > >Yes; however I guess that it actually depends upon other services >and configuration. > > > > Does the computer ring? > >Yes; however I guess that it actually depends upon other services >and configuration. > > > > Does the user independently answer each one of those devices? > >Yes; however I guess that it actually depends upon other services >and configuration. > > > > And what would happen if the PC has only audio? > >It would reject the offer with 488 or 606. > > > > I assume only the B2BUA knows the capabilities of > > > devices in advance? > >It can know the capabilities; however the B2BUA is mostly just >acting per service configuration. From pkyzivat@alum.mit.edu Mon Jan 14 18:19:46 2013 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 015CE11E809A for ; Mon, 14 Jan 2013 18:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aaeTA3ZxQWB for ; Mon, 14 Jan 2013 18:19:45 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id B5E8921F8B94 for ; Mon, 14 Jan 2013 18:19:44 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta05.westchester.pa.mail.comcast.net with comcast id o1bJ1k0050cZkys552KkYM; Tue, 15 Jan 2013 02:19:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id o2Kj1k00j3ZTu2S3W2Kjb2; Tue, 15 Jan 2013 02:19:44 +0000 Message-ID: <50F4BCBE.7010300@alum.mit.edu> Date: Mon, 14 Jan 2013 21:19:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: insipid@ietf.org References: <576A8B541C219D4E9CEB1DF8C19C7B880239BA@MBX06.citservers.local> <002101cdc7af$4a892ac0$df9b8040$@packetizer.com> <201301112155.r0BLt5Ss001896@rcdn-core2-5.cisco.com> <576A8B541C219D4E9CEB1DF8C19C7B88032779@MBX06.citservers.local> <201301150037.r0F0bLlC000647@rcdn-core-3.cisco.com> In-Reply-To: <201301150037.r0F0bLlC000647@rcdn-core-3.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1358216384; bh=OHDfAQGTKhc52+ReGdv48ulVdzy9/n//1wxN5+9ozUs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=d/0udSFfEbGOz0Ee+NmFJZFAgCTpj3ucN6PpFrcbE4DiyB/6CnzIOpQVXv8IRg2TQ PNCf7OlPijujgId74DeB5uRsDUvSZY7Yh0HWZcWePQeEdLxlabRvjf3hnPpKniMEJ7 rbbiBh3ccusJRDsSmfcXH+UgmBl6QCtJRHn+KuR3d++OMvzPJhKTvT17hzAv7RgoEp 6amSAWsoJ7JqMztUYhzaqWmhiTSgCEezWAUe/xhHb2vUACwLLEgUu/NT4SI5exEjva PGABYs09vCEn/ccjGQv4fxzhDwCIOly2htmJITw5M0cAfsdWJXrhIZ44YddTTXciB+ VaNiyj39WTZ5A== Subject: Re: [Insipid] Session-ID when B2BUA forks INVITE for audio and video to different locations X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 02:19:46 -0000 James, We should try to separate the general principle from the engineering details required to produce a reasonable product. There are many possible variations on this design pattern, some of which could be reasonable products, and some of which would be unusable. Some plausible variants: - Instead of Bob-computer, it is Bob-TV. The TV can do both audio and video, but the audio is then via speakerphone, and isn't very good. So the phone is involved in order to provide an audio handset. The offer to the TV is both audio/video, and to the phone is just audio. If the phone answers first, then an audio-only answer is sent to Alice, and a revised offer is sent to the TV, removing audio. (Assumes the TV sent a 183 with an answer.) If the TV refuses the call, then the call stays audio only with the phone. If the TV answers (with video), then the B2BUA does a reinvite and adds video back into the call with Alice. If the TV answers first (audio/video) then the B2BUA cancels the call to the phone, and completes the call to Alice with the answer from the TV. If the TV answers first, then an answer is sent to Alice with the audio and video from the TV. If the TV answered with active audio, then the call to the phone is canceled. If the TV refused the audio, or with it set to recvonly or inactive, then the B2BUA lets the phone continue to ring. If it is eventually answered, then the B2BUA reinvites the TV to disable audio, and Alice to move the audio to the phone. - The B2BUA is in Bob's computer. It *can* handle both audio and video. But Bob prefers his desk phone for audio. The B2BUA generates a call with just the audio to the phone, and also alerts on the PC (via a popup). If Bob answers on the phone, then the PC handles just the video part of the call itself, and makes a merged answer back to alice. If Bob answers on the PC, then the PC cancels the call to the phone, and handles both audio and video on the PC. So, does the "leg" to the phone get the same session-id? The point is that "pieces" of the call with Alice are spread around. My team (at Cisco) had a proto of this kind for thing running about 10 years ago. Thanks, Paul On 1/14/13 7:37 PM, James Polk wrote: > At 01:28 PM 1/13/2013, Brett Tate wrote: >> Thanks for responses. Reply is inline. >> >> > Paul Jones's series of questions (that have not been >> > answered yet, BTW). >> >> My apologies. The reply is also inline. >> >> > In your diagram, which I'll recreate here >> > >> > > Session-ID >> > > ---- Alice B2BUA Bob-phone Bob-computer >> > > {A} |---INVITE--->| | | >> > > {A} | |---INVITE-->| | >> > > {A} | |---INVITE------------->| >> > > {Bp,A} | |<--200 OK---| | >> > > {Bc,A} | |<--200 OK--------------| >> > > {Bp,A} |<--200 OK----| | | >> > > {A,Bp} |-----ACK---->| | | >> > > {A,Bp} | |---ACK----->| | >> > > {A,Bc} | |---ACK---------------->| >> > >> > Why is there a Bp and not a B? >> >> I didn't think that the draft provided the B2BUA the flexibility to >> reclassify the service to fall into a conferencing classification so >> that it wouldn't need to relay Bp or Bc. More specifically, this >> B2BUA service modifies the SDP; however it does not send/receive media. >> >> > I mean, B is all Alice is every going to see, >> > and the B2BUA has to be in charge of this recording >> > by transmitting a nearly replicative INVITE to >> > Bob's computer, right? >> >> This isn't a recording service; the B2BUA does not see the media. > > I obviously misinterpreted the flow's intent. > >> It is a service to break apart the SDP so that audio is offered to the >> phone and video is offered to the computer. > > What if one endpoint is available and the other is not? I'm sure folks > can imagine audio without video, but is video without audio acceptable? > > >> > What header-values are changed in the INVITE >> > transaction to and from Bob's computer relative >> > to that of the transaction to and from the phone? >> >> Excluding any current/future restrictions placed upon B2BUAs, it is >> mostly at the discretion of the B2BUA. > > If the B2BUA isn't in the media path, this is taking one INVITE and > turning into two INVITE's, one of which doesn't get the benefit of > having any feedback. Imagine an INVITE from Alice with two audio codecs > and two video codecs. This INVITE is split how you say it is. The B2BUA > cannot return a second "final response" (200 OK) with Bob's computer > UA's "answer". That presents an unworkable offer/answer exchange. > > >> > - The R-URI can't be the same. >> > - the Via can't be the same. >> > - the To can't be the same. >> > - the From can't be the same? >> > - is the CSeq the same? >> >> It at the discretion of the B2BUA. > > I'm thinking that this second INVITE is a whole new INVITE with new > header-values in each header in the request. > > >> > - the Contact can't be the same. >> > - is the SDP the same, given that the media packets >> > are to be going through the B2BUA? >> >> The media packets do not go through the B2BUA. The SDP is different. >> >> > I suspect that this is an entirely new transaction with new/different >> > header-values, and not merely a different Session-ID header-value. >> > Not knowing SIPREC as well as I should, does this INVITE to Bob's >> > computer need to be in parallel like the call flow shows? >> >> It is not required; however it simplifies the SDP offer/answer exchanges. >> >> > For example could it be like this instead? >> >> Not exactly; the B2BUA will need to provide Bob's video answer SDP to >> Alice. > > For every SIP request, there can be only one final response, therefore > this B2BUA (in the signaling path only) will have to > eat/consume/terminate/'not send on' any additional final responses > received within this transaction. While I agree the message flow below > isn't right (I thought you were describing a SIPREC flow), you're gonna > have a hard time reconciling this 'alice has to receive a second SDP > from bob's computer' issue. > > In SIP, there's forking and then there's conferencing. What you're > describing is a hybrid, and not standard. > > IMHO, we here in INSIPID shouldn't take on the additional scope that > this would entail. > > However, I've been wrong about what Brett's tried to convey once before. > I could be wrong again. > > James > > >> > > Session-ID >> > > ---- Alice B2BUA Bob-phone Bob-computer >> > > {A} |---INVITE--->| | | >> > > {A} | |---INVITE-->| | >> > > {B,A} | |<--200 OK---| | >> > > {B,A} |<--200 OK----| | | >> > > {A,B} |-----ACK---->| | | >> > > {A,B} | |---ACK----->| | >> > > {A} | |---INVITE------------->| >> > > {Bc,A} | |<--200 OK--------------| >> > > {A,Bc} | |---ACK---------------->| >> > >> > James >> > >> > At 12:13 AM 11/21/2012, Paul E. Jones wrote: >> > > Brett, >> > > >> > > Well, this is certainly different. Does the phone ring? >> >> Yes; however I guess that it actually depends upon other services and >> configuration. >> >> > > Does the computer ring? >> >> Yes; however I guess that it actually depends upon other services and >> configuration. >> >> > > Does the user independently answer each one of those devices? >> >> Yes; however I guess that it actually depends upon other services and >> configuration. >> >> > > And what would happen if the PC has only audio? >> >> It would reject the offer with 488 or 606. >> >> > > I assume only the B2BUA knows the capabilities of >> > > devices in advance? >> >> It can know the capabilities; however the B2BUA is mostly just acting >> per service configuration. > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From jmpolk@cisco.com Mon Jan 14 19:16:46 2013 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 34AEE11E80A3 for ; Mon, 14 Jan 2013 19:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdAov1CbeSbt for ; Mon, 14 Jan 2013 19:16:45 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EBDEC11E8099 for ; Mon, 14 Jan 2013 19:16:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9349; q=dns/txt; s=iport; t=1358219805; x=1359429405; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=L0i8QYWNxEpSJg+I/8GJ73ZNaEr+5boJw6Yn7ZzG7gs=; b=G1aJlD3l4EnMySo4AwyeZDXKbCInTCc4WFZGbxecaFckmAqtLLruBTHT JqL89+zg+3CL2ZWsq/BdA/niLaBbjIn0XEAuo2lmwItS28H0qkxq6GcTV M5HGusBSaghbWch3Ev7iu0uuXcwrW2W+XBtREDOKXZAKV0p5LucH52jGr I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogFALHI9FCtJV2Z/2dsb2JhbABEDrovgzgWc4IaBAEBAQQBAQEkEQI0GwcEDgoJFRAPCg4wBgEShUkHgiseDLYXBIxrhEMDiGGJd5N8gjddgUcE X-IronPort-AV: E=Sophos;i="4.84,469,1355097600"; d="scan'208";a="159404731" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 15 Jan 2013 03:16:44 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) (authenticated bits=0) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0F3GhRv002226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jan 2013 03:16:43 GMT Message-Id: <201301150316.r0F3GhRv002226@rcdn-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Jan 2013 21:16:42 -0600 To: Paul Kyzivat , From: James Polk In-Reply-To: <50F4BCBE.7010300@alum.mit.edu> References: <576A8B541C219D4E9CEB1DF8C19C7B880239BA@MBX06.citservers.local> <002101cdc7af$4a892ac0$df9b8040$@packetizer.com> <201301112155.r0BLt5Ss001896@rcdn-core2-5.cisco.com> <576A8B541C219D4E9CEB1DF8C19C7B88032779@MBX06.citservers.local> <201301150037.r0F0bLlC000647@rcdn-core-3.cisco.com> <50F4BCBE.7010300@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [Insipid] Session-ID when B2BUA forks INVITE for audio and video to different locations X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 03:16:46 -0000 Paul Just to clarify, both your scenarios Alice wouldn't be sent any SIP response until eveything's decided which way which stream is going to which UA, right? If that's the case, you have put forth an interesting set-up. One I'm not going to kneejerk in a quick response - rather I'm going to ponder for a day or two (because it could have interesting outcome(s)). At 08:19 PM 1/14/2013, Paul Kyzivat wrote: >James, > >We should try to separate the general principle from the engineering >details required to produce a reasonable product. notice I stayed in the SIP world, and didn't talk about the Session-ID in my response. I guess I couldn't get past a few things in the former. James >There are many possible variations on this design pattern, some of >which could be reasonable products, and some of which would be unusable. > >Some plausible variants: > >- Instead of Bob-computer, it is Bob-TV. The TV can do both audio > and video, but the audio is then via speakerphone, and isn't very > good. So the phone is involved in order to provide an audio handset. > The offer to the TV is both audio/video, and to the phone is just > audio. > > If the phone answers first, then an audio-only answer is sent to > Alice, and a revised offer is sent to the TV, removing audio. > (Assumes the TV sent a 183 with an answer.) If the TV refuses the > call, then the call stays audio only with the phone. If the TV > answers (with video), then the B2BUA does a reinvite and adds > video back into the call with Alice. > > If the TV answers first (audio/video) then the B2BUA cancels > the call to the phone, and completes the call to Alice with the > answer from the TV. > > If the TV answers first, then an answer is sent to Alice with > the audio and video from the TV. If the TV answered with > active audio, then the call to the phone is canceled. If the > TV refused the audio, or with it set to recvonly or inactive, > then the B2BUA lets the phone continue to ring. If it is > eventually answered, then the B2BUA reinvites the TV to disable > audio, and Alice to move the audio to the phone. > >- The B2BUA is in Bob's computer. It *can* handle both audio and > video. But Bob prefers his desk phone for audio. The B2BUA > generates a call with just the audio to the phone, and also > alerts on the PC (via a popup). If Bob answers on the phone, > then the PC handles just the video part of the call itself, > and makes a merged answer back to alice. If Bob answers on > the PC, then the PC cancels the call to the phone, and handles > both audio and video on the PC. > So, does the "leg" to the phone get the same session-id? > >The point is that "pieces" of the call with Alice are spread around. > >My team (at Cisco) had a proto of this kind for thing running about >10 years ago. > > Thanks, > Paul > >On 1/14/13 7:37 PM, James Polk wrote: >>At 01:28 PM 1/13/2013, Brett Tate wrote: >>>Thanks for responses. Reply is inline. >>> >>> > Paul Jones's series of questions (that have not been >>> > answered yet, BTW). >>> >>>My apologies. The reply is also inline. >>> >>> > In your diagram, which I'll recreate here >>> > >>> > > Session-ID >>> > > ---- Alice B2BUA Bob-phone Bob-computer >>> > > {A} |---INVITE--->| | | >>> > > {A} | |---INVITE-->| | >>> > > {A} | |---INVITE------------->| >>> > > {Bp,A} | |<--200 OK---| | >>> > > {Bc,A} | |<--200 OK--------------| >>> > > {Bp,A} |<--200 OK----| | | >>> > > {A,Bp} |-----ACK---->| | | >>> > > {A,Bp} | |---ACK----->| | >>> > > {A,Bc} | |---ACK---------------->| >>> > >>> > Why is there a Bp and not a B? >>> >>>I didn't think that the draft provided the B2BUA the flexibility to >>>reclassify the service to fall into a conferencing classification so >>>that it wouldn't need to relay Bp or Bc. More specifically, this >>>B2BUA service modifies the SDP; however it does not send/receive media. >>> >>> > I mean, B is all Alice is every going to see, >>> > and the B2BUA has to be in charge of this recording >>> > by transmitting a nearly replicative INVITE to >>> > Bob's computer, right? >>> >>>This isn't a recording service; the B2BUA does not see the media. >> >>I obviously misinterpreted the flow's intent. >> >>>It is a service to break apart the SDP so that audio is offered to the >>>phone and video is offered to the computer. >> >>What if one endpoint is available and the other is not? I'm sure folks >>can imagine audio without video, but is video without audio acceptable? >> >> >>> > What header-values are changed in the INVITE >>> > transaction to and from Bob's computer relative >>> > to that of the transaction to and from the phone? >>> >>>Excluding any current/future restrictions placed upon B2BUAs, it is >>>mostly at the discretion of the B2BUA. >> >>If the B2BUA isn't in the media path, this is taking one INVITE and >>turning into two INVITE's, one of which doesn't get the benefit of >>having any feedback. Imagine an INVITE from Alice with two audio codecs >>and two video codecs. This INVITE is split how you say it is. The B2BUA >>cannot return a second "final response" (200 OK) with Bob's computer >>UA's "answer". That presents an unworkable offer/answer exchange. >> >> >>> > - The R-URI can't be the same. >>> > - the Via can't be the same. >>> > - the To can't be the same. >>> > - the From can't be the same? >>> > - is the CSeq the same? >>> >>>It at the discretion of the B2BUA. >> >>I'm thinking that this second INVITE is a whole new INVITE with new >>header-values in each header in the request. >> >> >>> > - the Contact can't be the same. >>> > - is the SDP the same, given that the media packets >>> > are to be going through the B2BUA? >>> >>>The media packets do not go through the B2BUA. The SDP is different. >>> >>> > I suspect that this is an entirely new transaction with new/different >>> > header-values, and not merely a different Session-ID header-value. >>> > Not knowing SIPREC as well as I should, does this INVITE to Bob's >>> > computer need to be in parallel like the call flow shows? >>> >>>It is not required; however it simplifies the SDP offer/answer exchanges. >>> >>> > For example could it be like this instead? >>> >>>Not exactly; the B2BUA will need to provide Bob's video answer SDP to >>>Alice. >> >>For every SIP request, there can be only one final response, therefore >>this B2BUA (in the signaling path only) will have to >>eat/consume/terminate/'not send on' any additional final responses >>received within this transaction. While I agree the message flow below >>isn't right (I thought you were describing a SIPREC flow), you're gonna >>have a hard time reconciling this 'alice has to receive a second SDP >>from bob's computer' issue. >> >>In SIP, there's forking and then there's conferencing. What you're >>describing is a hybrid, and not standard. >> >>IMHO, we here in INSIPID shouldn't take on the additional scope that >>this would entail. >> >>However, I've been wrong about what Brett's tried to convey once before. >>I could be wrong again. >> >>James >> >> >>> > > Session-ID >>> > > ---- Alice B2BUA Bob-phone Bob-computer >>> > > {A} |---INVITE--->| | | >>> > > {A} | |---INVITE-->| | >>> > > {B,A} | |<--200 OK---| | >>> > > {B,A} |<--200 OK----| | | >>> > > {A,B} |-----ACK---->| | | >>> > > {A,B} | |---ACK----->| | >>> > > {A} | |---INVITE------------->| >>> > > {Bc,A} | |<--200 OK--------------| >>> > > {A,Bc} | |---ACK---------------->| >>> > >>> > James >>> > >>> > At 12:13 AM 11/21/2012, Paul E. Jones wrote: >>> > > Brett, >>> > > >>> > > Well, this is certainly different. Does the phone ring? >>> >>>Yes; however I guess that it actually depends upon other services and >>>configuration. >>> >>> > > Does the computer ring? >>> >>>Yes; however I guess that it actually depends upon other services and >>>configuration. >>> >>> > > Does the user independently answer each one of those devices? >>> >>>Yes; however I guess that it actually depends upon other services and >>>configuration. >>> >>> > > And what would happen if the PC has only audio? >>> >>>It would reject the offer with 488 or 606. >>> >>> > > I assume only the B2BUA knows the capabilities of >>> > > devices in advance? >>> >>>It can know the capabilities; however the B2BUA is mostly just acting >>>per service configuration. >> >>_______________________________________________ >>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 brett@broadsoft.com Tue Jan 15 05:45:36 2013 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 C584621F8775 for ; Tue, 15 Jan 2013 05:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A423YEBBlJol for ; Tue, 15 Jan 2013 05:45:36 -0800 (PST) Received: from smtpout01.partnerhosted.com (unknown [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id 01EEA21F86CA for ; Tue, 15 Jan 2013 05:45:36 -0800 (PST) Received: from CASUMHUB04.citservers.local (172.16.98.225) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 15 Jan 2013 05:46:53 -0800 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Tue, 15 Jan 2013 05:46:53 -0800 From: Brett Tate To: James Polk , "insipid@ietf.org" Thread-Topic: [Insipid] Session-ID when B2BUA forks INVITE for audio and video to different locations Thread-Index: AQHN8rir5lBAMFz2Wk6lqjGaYIjh5phKOpWw Date: Tue, 15 Jan 2013 13:46:52 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88032B13@MBX06.citservers.local> References: <576A8B541C219D4E9CEB1DF8C19C7B880239BA@MBX06.citservers.local> <002101cdc7af$4a892ac0$df9b8040$@packetizer.com> <201301112155.r0BLt5Ss001896@rcdn-core2-5.cisco.com> <576A8B541C219D4E9CEB1DF8C19C7B88032779@MBX06.citservers.local> <201301150037.r0F0bLlC000647@rcdn-core-3.cisco.com> In-Reply-To: <201301150037.r0F0bLlC000647@rcdn-core-3.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] Session-ID when B2BUA forks INVITE for audio and video to different locations X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 13:45:36 -0000 > >It is a service to break apart the SDP so that audio is offered to > >the phone and video is offered to the computer. >=20 > What if one endpoint is available and the other is not? I'm sure > folks can imagine audio without video, but is video without audio > acceptable? The behavior would be per configuration or vendor's decision. =20 > > > What header-values are changed in the INVITE > > > transaction to and from Bob's computer relative > > > to that of the transaction to and from the phone? > > > >Excluding any current/future restrictions placed upon B2BUAs, it is > >mostly at the discretion of the B2BUA. >=20 > If the B2BUA isn't in the media path, this is taking one INVITE and > turning into two INVITE's, one of which doesn't get the benefit of > having any feedback. Imagine an INVITE from Alice with two audio > codecs and two video codecs. This INVITE is split how you say it is. > The B2BUA cannot return a second "final response" (200 OK) with Bob's > computer UA's "answer". That presents an unworkable offer/answer > exchange. Similar to the B2BUA splitting the offer SDP for two INVITEs, it can also m= erge two answer SDPs into a single answer SDP. However, there are obviousl= y some limitations associated such a service. For instance if the SDPs can= not be merged without conflicts, the B2BUA would likely release one of the = dialogs. =20 > For every SIP request, there can be only one final response, There can be many 2xx responses for an INVITE. However, that is not what I= 'm attempting to describe. > therefore this B2BUA (in the signaling path only) will have to > eat/consume/terminate/'not send on' any additional final responses > received within this transaction. While I agree the message flow > below isn't right (I thought you were describing a SIPREC flow), > you're gonna have a hard time reconciling this 'alice has to receive > a second SDP from bob's computer' issue. The B2BUA isn't sending the full SDP from bob's computer. The answer SDP s= ent by the B2BUA is basically the merge of the audio answer SDP received fr= om bob's phone and video answer SDP received from bob's computer. > In SIP, there's forking and then there's conferencing. What you're > describing is a hybrid, and not standard. I'm describing a B2BUA type service/callflow. And I'm attempting to unders= tand how to apply the INSIPID mandate to the callflow. Thanks, Brett From pkyzivat@alum.mit.edu Tue Jan 15 08:48:43 2013 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 1B57421F85D6 for ; Tue, 15 Jan 2013 08:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Y6DCH+3mcuB for ; Tue, 15 Jan 2013 08:48:42 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 50FB121F8585 for ; Tue, 15 Jan 2013 08:48:37 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id oBn41k0090cZkys53GocEe; Tue, 15 Jan 2013 16:48:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id oGoc1k00G3ZTu2S3WGocHd; Tue, 15 Jan 2013 16:48:36 +0000 Message-ID: <50F58863.1020405@alum.mit.edu> Date: Tue, 15 Jan 2013 11:48:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: James Polk References: <576A8B541C219D4E9CEB1DF8C19C7B880239BA@MBX06.citservers.local> <002101cdc7af$4a892ac0$df9b8040$@packetizer.com> <201301112155.r0BLt5Ss001896@rcdn-core2-5.cisco.com> <576A8B541C219D4E9CEB1DF8C19C7B88032779@MBX06.citservers.local> <201301150037.r0F0bLlC000647@rcdn-core-3.cisco.com> <50F4BCBE.7010300@alum.mit.edu> <201301150316.r0F3GhRv002226@rcdn-core-2.cisco.com> In-Reply-To: <201301150316.r0F3GhRv002226@rcdn-core-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1358268516; bh=8x01yD5CrNsllpfC9gH5RzJOurt1TtsjHnUne6oqv/o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=k89WMEFjmST0dAeZWa5MOgSwLiG/hX7m3V586aJPBbm0DV9P7EBQx/zEhf3ozqUKw YzHqCy0TySvnUmiRCqLTnEFAvIH+CFOpL5qrRCBV78/1djL4s9b68rvVro3Sr1BBA6 5yv8Cin7605qrFUBSPRH0ZK4a8p4uMeKWATIB5+ngvYqNaGYvIY7i5nNFd9T71li7k IbcZ4SMTz8XX0FPpfPXtQ5z7PIc8cwn9ZL0oPx7U1NsSrI9MQGnkCYn5fypMTfXEAx x5NcpOCM+DvYTDLZmH6FUEo5H8PjDMrroagaP8leW2vGoXW6gcuT1QpIVeHHYJW+h/ ol7Ac5F7487PQ== Cc: insipid@ietf.org Subject: Re: [Insipid] Session-ID when B2BUA forks INVITE for audio and video to different locations X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 16:48:43 -0000 On 1/14/13 10:16 PM, James Polk wrote: > Paul > > Just to clarify, both your scenarios Alice wouldn't be sent any SIP > response until eveything's decided which way which stream is going to > which UA, right? I tried to indicate. This can vary depending on the strategy the B2BUA is following. > If that's the case, you have put forth an interesting set-up. One I'm > not going to kneejerk in a quick response - rather I'm going to ponder > for a day or two (because it could have interesting outcome(s)). There are many ways to implement this, and to think about it. They may lead to different answers about the session id. And that may be ok. But I hope the choice about when to preserve the session id is not entirely subjective. There ought to be some criteria to apply that say whether to preserve the session id in each case. Thanks, Paul > At 08:19 PM 1/14/2013, Paul Kyzivat wrote: >> James, >> >> We should try to separate the general principle from the engineering >> details required to produce a reasonable product. > > notice I stayed in the SIP world, and didn't talk about the Session-ID > in my response. I guess I couldn't get past a few things in the former. > > James > > >> There are many possible variations on this design pattern, some of >> which could be reasonable products, and some of which would be unusable. >> >> Some plausible variants: >> >> - Instead of Bob-computer, it is Bob-TV. The TV can do both audio >> and video, but the audio is then via speakerphone, and isn't very >> good. So the phone is involved in order to provide an audio handset. >> The offer to the TV is both audio/video, and to the phone is just >> audio. >> >> If the phone answers first, then an audio-only answer is sent to >> Alice, and a revised offer is sent to the TV, removing audio. >> (Assumes the TV sent a 183 with an answer.) If the TV refuses the >> call, then the call stays audio only with the phone. If the TV >> answers (with video), then the B2BUA does a reinvite and adds >> video back into the call with Alice. >> >> If the TV answers first (audio/video) then the B2BUA cancels >> the call to the phone, and completes the call to Alice with the >> answer from the TV. >> >> If the TV answers first, then an answer is sent to Alice with >> the audio and video from the TV. If the TV answered with >> active audio, then the call to the phone is canceled. If the >> TV refused the audio, or with it set to recvonly or inactive, >> then the B2BUA lets the phone continue to ring. If it is >> eventually answered, then the B2BUA reinvites the TV to disable >> audio, and Alice to move the audio to the phone. >> >> - The B2BUA is in Bob's computer. It *can* handle both audio and >> video. But Bob prefers his desk phone for audio. The B2BUA >> generates a call with just the audio to the phone, and also >> alerts on the PC (via a popup). If Bob answers on the phone, >> then the PC handles just the video part of the call itself, >> and makes a merged answer back to alice. If Bob answers on >> the PC, then the PC cancels the call to the phone, and handles >> both audio and video on the PC. >> So, does the "leg" to the phone get the same session-id? >> >> The point is that "pieces" of the call with Alice are spread around. >> >> My team (at Cisco) had a proto of this kind for thing running about 10 >> years ago. >> >> Thanks, >> Paul >> >> On 1/14/13 7:37 PM, James Polk wrote: >>> At 01:28 PM 1/13/2013, Brett Tate wrote: >>>> Thanks for responses. Reply is inline. >>>> >>>> > Paul Jones's series of questions (that have not been >>>> > answered yet, BTW). >>>> >>>> My apologies. The reply is also inline. >>>> >>>> > In your diagram, which I'll recreate here >>>> > >>>> > > Session-ID >>>> > > ---- Alice B2BUA Bob-phone Bob-computer >>>> > > {A} |---INVITE--->| | | >>>> > > {A} | |---INVITE-->| | >>>> > > {A} | |---INVITE------------->| >>>> > > {Bp,A} | |<--200 OK---| | >>>> > > {Bc,A} | |<--200 OK--------------| >>>> > > {Bp,A} |<--200 OK----| | | >>>> > > {A,Bp} |-----ACK---->| | | >>>> > > {A,Bp} | |---ACK----->| | >>>> > > {A,Bc} | |---ACK---------------->| >>>> > >>>> > Why is there a Bp and not a B? >>>> >>>> I didn't think that the draft provided the B2BUA the flexibility to >>>> reclassify the service to fall into a conferencing classification so >>>> that it wouldn't need to relay Bp or Bc. More specifically, this >>>> B2BUA service modifies the SDP; however it does not send/receive media. >>>> >>>> > I mean, B is all Alice is every going to see, >>>> > and the B2BUA has to be in charge of this recording >>>> > by transmitting a nearly replicative INVITE to >>>> > Bob's computer, right? >>>> >>>> This isn't a recording service; the B2BUA does not see the media. >>> >>> I obviously misinterpreted the flow's intent. >>> >>>> It is a service to break apart the SDP so that audio is offered to the >>>> phone and video is offered to the computer. >>> >>> What if one endpoint is available and the other is not? I'm sure folks >>> can imagine audio without video, but is video without audio acceptable? >>> >>> >>>> > What header-values are changed in the INVITE >>>> > transaction to and from Bob's computer relative >>>> > to that of the transaction to and from the phone? >>>> >>>> Excluding any current/future restrictions placed upon B2BUAs, it is >>>> mostly at the discretion of the B2BUA. >>> >>> If the B2BUA isn't in the media path, this is taking one INVITE and >>> turning into two INVITE's, one of which doesn't get the benefit of >>> having any feedback. Imagine an INVITE from Alice with two audio codecs >>> and two video codecs. This INVITE is split how you say it is. The B2BUA >>> cannot return a second "final response" (200 OK) with Bob's computer >>> UA's "answer". That presents an unworkable offer/answer exchange. >>> >>> >>>> > - The R-URI can't be the same. >>>> > - the Via can't be the same. >>>> > - the To can't be the same. >>>> > - the From can't be the same? >>>> > - is the CSeq the same? >>>> >>>> It at the discretion of the B2BUA. >>> >>> I'm thinking that this second INVITE is a whole new INVITE with new >>> header-values in each header in the request. >>> >>> >>>> > - the Contact can't be the same. >>>> > - is the SDP the same, given that the media packets >>>> > are to be going through the B2BUA? >>>> >>>> The media packets do not go through the B2BUA. The SDP is different. >>>> >>>> > I suspect that this is an entirely new transaction with new/different >>>> > header-values, and not merely a different Session-ID header-value. >>>> > Not knowing SIPREC as well as I should, does this INVITE to Bob's >>>> > computer need to be in parallel like the call flow shows? >>>> >>>> It is not required; however it simplifies the SDP offer/answer >>>> exchanges. >>>> >>>> > For example could it be like this instead? >>>> >>>> Not exactly; the B2BUA will need to provide Bob's video answer SDP to >>>> Alice. >>> >>> For every SIP request, there can be only one final response, therefore >>> this B2BUA (in the signaling path only) will have to >>> eat/consume/terminate/'not send on' any additional final responses >>> received within this transaction. While I agree the message flow below >>> isn't right (I thought you were describing a SIPREC flow), you're gonna >>> have a hard time reconciling this 'alice has to receive a second SDP >>> from bob's computer' issue. >>> >>> In SIP, there's forking and then there's conferencing. What you're >>> describing is a hybrid, and not standard. >>> >>> IMHO, we here in INSIPID shouldn't take on the additional scope that >>> this would entail. >>> >>> However, I've been wrong about what Brett's tried to convey once before. >>> I could be wrong again. >>> >>> James >>> >>> >>>> > > Session-ID >>>> > > ---- Alice B2BUA Bob-phone Bob-computer >>>> > > {A} |---INVITE--->| | | >>>> > > {A} | |---INVITE-->| | >>>> > > {B,A} | |<--200 OK---| | >>>> > > {B,A} |<--200 OK----| | | >>>> > > {A,B} |-----ACK---->| | | >>>> > > {A,B} | |---ACK----->| | >>>> > > {A} | |---INVITE------------->| >>>> > > {Bc,A} | |<--200 OK--------------| >>>> > > {A,Bc} | |---ACK---------------->| >>>> > >>>> > James >>>> > >>>> > At 12:13 AM 11/21/2012, Paul E. Jones wrote: >>>> > > Brett, >>>> > > >>>> > > Well, this is certainly different. Does the phone ring? >>>> >>>> Yes; however I guess that it actually depends upon other services and >>>> configuration. >>>> >>>> > > Does the computer ring? >>>> >>>> Yes; however I guess that it actually depends upon other services and >>>> configuration. >>>> >>>> > > Does the user independently answer each one of those devices? >>>> >>>> Yes; however I guess that it actually depends upon other services and >>>> configuration. >>>> >>>> > > And what would happen if the PC has only audio? >>>> >>>> It would reject the offer with 488 or 606. >>>> >>>> > > I assume only the B2BUA knows the capabilities of >>>> > > devices in advance? >>>> >>>> It can know the capabilities; however the B2BUA is mostly just acting >>>> per service configuration. >>> >>> _______________________________________________ >>> 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 jmpolk@cisco.com Tue Jan 15 10:22:26 2013 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 F143D11E809C for ; Tue, 15 Jan 2013 10:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g053A+UhS8NM for ; Tue, 15 Jan 2013 10:22:24 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DCC4B11E80A6 for ; Tue, 15 Jan 2013 10:22:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11812; q=dns/txt; s=iport; t=1358274144; x=1359483744; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=7hqOKyYCNt/nsag0k02UPaLVy56GMc5DYyu/EW4rq+I=; b=DlvgG3FL5Nq337OoIgwn9nZPy7+y59iCmdW+VhTY8mc6+GOUuadmClRO SlA0/rtn1+jwpI9hB6BhVT/yJZZpMHITIZFVsesca14wVEqCA01WaPPu/ wJuGyVdluKgaMx/oiJRuJmH63p2Bwg0pNu8sPrI9sjHrJZdCOlyLnCG0U 0=; X-IronPort-AV: E=Sophos;i="4.84,475,1355097600"; d="scan'208";a="162709175" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 15 Jan 2013 18:22:23 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) (authenticated bits=0) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0FIMMok015319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jan 2013 18:22:22 GMT Message-Id: <201301151822.r0FIMMok015319@rcdn-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 15 Jan 2013 12:22:21 -0600 To: Paul Kyzivat , James Polk From: James Polk In-Reply-To: <50F58863.1020405@alum.mit.edu> References: <576A8B541C219D4E9CEB1DF8C19C7B880239BA@MBX06.citservers.local> <002101cdc7af$4a892ac0$df9b8040$@packetizer.com> <201301112155.r0BLt5Ss001896@rcdn-core2-5.cisco.com> <576A8B541C219D4E9CEB1DF8C19C7B88032779@MBX06.citservers.local> <201301150037.r0F0bLlC000647@rcdn-core-3.cisco.com> <50F4BCBE.7010300@alum.mit.edu> <201301150316.r0F3GhRv002226@rcdn-core-2.cisco.com> <50F58863.1020405@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: insipid@ietf.org Subject: Re: [Insipid] Session-ID when B2BUA forks INVITE for audio and video to different locations X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:22:26 -0000 At 10:48 AM 1/15/2013, Paul Kyzivat wrote: >On 1/14/13 10:16 PM, James Polk wrote: >>Paul >> >>Just to clarify, both your scenarios Alice wouldn't be sent any SIP >>response until eveything's decided which way which stream is going to >>which UA, right? > >I tried to indicate. This can vary depending on the strategy the >B2BUA is following. > >>If that's the case, you have put forth an interesting set-up. One I'm >>not going to kneejerk in a quick response - rather I'm going to ponder >>for a day or two (because it could have interesting outcome(s)). > >There are many ways to implement this, and to think about it. They >may lead to different answers about the session id. And that may be >ok. But I hope the choice about when to preserve the session id is >not entirely subjective. There ought to be some criteria to apply >that say whether to preserve the session id in each case. Paul From a Session-ID point of view, I believe if you are wanting the service Brett is describing, then it'll look something like this *logically* Bob's Phone / / leg 'a' / Alice ======= B2BUA \ \ leg 'b' \ Bob's computer Where it is the case that the B2BUA merges the two responses from Bob's 2 UAs into a single one response, unless there are conflicts; then Brett's right, some choices will need to be made, including dropping one signaling leg. A Session-ID can (right now) only have two parts, and I believe from Alice's point of view, she ought to see a consistent other UUID making up the full Session-ID. However, - from the B2BUA to Bob's phone, the Session-ID should be (A,Bp) and - from the B2BUA to Bob's computer, the Session-ID should be (A,Bc) Just as the B2BUA merges the SDPs together (and at least changes header-values), it also maintains a single Session-ID towards Alice. Now, how does the B2BUA pick which of Bob's UAs to send towards Alice... do we want to make that uniform? Can we make that uniform? Answers: probably and probably can't, and the 'can't' wins. caveat: someone clever might come up with a way, but for every scenario of Bob's UAs... James > Thanks, > Paul > >>At 08:19 PM 1/14/2013, Paul Kyzivat wrote: >>>James, >>> >>>We should try to separate the general principle from the engineering >>>details required to produce a reasonable product. >> >>notice I stayed in the SIP world, and didn't talk about the Session-ID >>in my response. I guess I couldn't get past a few things in the former. >> >>James >> >> >>>There are many possible variations on this design pattern, some of >>>which could be reasonable products, and some of which would be unusable. >>> >>>Some plausible variants: >>> >>>- Instead of Bob-computer, it is Bob-TV. The TV can do both audio >>> and video, but the audio is then via speakerphone, and isn't very >>> good. So the phone is involved in order to provide an audio handset. >>> The offer to the TV is both audio/video, and to the phone is just >>> audio. >>> >>> If the phone answers first, then an audio-only answer is sent to >>> Alice, and a revised offer is sent to the TV, removing audio. >>> (Assumes the TV sent a 183 with an answer.) If the TV refuses the >>> call, then the call stays audio only with the phone. If the TV >>> answers (with video), then the B2BUA does a reinvite and adds >>> video back into the call with Alice. >>> >>> If the TV answers first (audio/video) then the B2BUA cancels >>> the call to the phone, and completes the call to Alice with the >>> answer from the TV. >>> >>> If the TV answers first, then an answer is sent to Alice with >>> the audio and video from the TV. If the TV answered with >>> active audio, then the call to the phone is canceled. If the >>> TV refused the audio, or with it set to recvonly or inactive, >>> then the B2BUA lets the phone continue to ring. If it is >>> eventually answered, then the B2BUA reinvites the TV to disable >>> audio, and Alice to move the audio to the phone. >>> >>>- The B2BUA is in Bob's computer. It *can* handle both audio and >>> video. But Bob prefers his desk phone for audio. The B2BUA >>> generates a call with just the audio to the phone, and also >>> alerts on the PC (via a popup). If Bob answers on the phone, >>> then the PC handles just the video part of the call itself, >>> and makes a merged answer back to alice. If Bob answers on >>> the PC, then the PC cancels the call to the phone, and handles >>> both audio and video on the PC. >>> So, does the "leg" to the phone get the same session-id? >>> >>>The point is that "pieces" of the call with Alice are spread around. >>> >>>My team (at Cisco) had a proto of this kind for thing running about 10 >>>years ago. >>> >>> Thanks, >>> Paul >>> >>>On 1/14/13 7:37 PM, James Polk wrote: >>>>At 01:28 PM 1/13/2013, Brett Tate wrote: >>>>>Thanks for responses. Reply is inline. >>>>> >>>>> > Paul Jones's series of questions (that have not been >>>>> > answered yet, BTW). >>>>> >>>>>My apologies. The reply is also inline. >>>>> >>>>> > In your diagram, which I'll recreate here >>>>> > >>>>> > > Session-ID >>>>> > > ---- Alice B2BUA Bob-phone Bob-computer >>>>> > > {A} |---INVITE--->| | | >>>>> > > {A} | |---INVITE-->| | >>>>> > > {A} | |---INVITE------------->| >>>>> > > {Bp,A} | |<--200 OK---| | >>>>> > > {Bc,A} | |<--200 OK--------------| >>>>> > > {Bp,A} |<--200 OK----| | | >>>>> > > {A,Bp} |-----ACK---->| | | >>>>> > > {A,Bp} | |---ACK----->| | >>>>> > > {A,Bc} | |---ACK---------------->| >>>>> > >>>>> > Why is there a Bp and not a B? >>>>> >>>>>I didn't think that the draft provided the B2BUA the flexibility to >>>>>reclassify the service to fall into a conferencing classification so >>>>>that it wouldn't need to relay Bp or Bc. More specifically, this >>>>>B2BUA service modifies the SDP; however it does not send/receive media. >>>>> >>>>> > I mean, B is all Alice is every going to see, >>>>> > and the B2BUA has to be in charge of this recording >>>>> > by transmitting a nearly replicative INVITE to >>>>> > Bob's computer, right? >>>>> >>>>>This isn't a recording service; the B2BUA does not see the media. >>>> >>>>I obviously misinterpreted the flow's intent. >>>> >>>>>It is a service to break apart the SDP so that audio is offered to the >>>>>phone and video is offered to the computer. >>>> >>>>What if one endpoint is available and the other is not? I'm sure folks >>>>can imagine audio without video, but is video without audio acceptable? >>>> >>>> >>>>> > What header-values are changed in the INVITE >>>>> > transaction to and from Bob's computer relative >>>>> > to that of the transaction to and from the phone? >>>>> >>>>>Excluding any current/future restrictions placed upon B2BUAs, it is >>>>>mostly at the discretion of the B2BUA. >>>> >>>>If the B2BUA isn't in the media path, this is taking one INVITE and >>>>turning into two INVITE's, one of which doesn't get the benefit of >>>>having any feedback. Imagine an INVITE from Alice with two audio codecs >>>>and two video codecs. This INVITE is split how you say it is. The B2BUA >>>>cannot return a second "final response" (200 OK) with Bob's computer >>>>UA's "answer". That presents an unworkable offer/answer exchange. >>>> >>>> >>>>> > - The R-URI can't be the same. >>>>> > - the Via can't be the same. >>>>> > - the To can't be the same. >>>>> > - the From can't be the same? >>>>> > - is the CSeq the same? >>>>> >>>>>It at the discretion of the B2BUA. >>>> >>>>I'm thinking that this second INVITE is a whole new INVITE with new >>>>header-values in each header in the request. >>>> >>>> >>>>> > - the Contact can't be the same. >>>>> > - is the SDP the same, given that the media packets >>>>> > are to be going through the B2BUA? >>>>> >>>>>The media packets do not go through the B2BUA. The SDP is different. >>>>> >>>>> > I suspect that this is an entirely new transaction with new/different >>>>> > header-values, and not merely a different Session-ID header-value. >>>>> > Not knowing SIPREC as well as I should, does this INVITE to Bob's >>>>> > computer need to be in parallel like the call flow shows? >>>>> >>>>>It is not required; however it simplifies the SDP offer/answer >>>>>exchanges. >>>>> >>>>> > For example could it be like this instead? >>>>> >>>>>Not exactly; the B2BUA will need to provide Bob's video answer SDP to >>>>>Alice. >>>> >>>>For every SIP request, there can be only one final response, therefore >>>>this B2BUA (in the signaling path only) will have to >>>>eat/consume/terminate/'not send on' any additional final responses >>>>received within this transaction. While I agree the message flow below >>>>isn't right (I thought you were describing a SIPREC flow), you're gonna >>>>have a hard time reconciling this 'alice has to receive a second SDP >>>>from bob's computer' issue. >>>> >>>>In SIP, there's forking and then there's conferencing. What you're >>>>describing is a hybrid, and not standard. >>>> >>>>IMHO, we here in INSIPID shouldn't take on the additional scope that >>>>this would entail. >>>> >>>>However, I've been wrong about what Brett's tried to convey once before. >>>>I could be wrong again. >>>> >>>>James >>>> >>>> >>>>> > > Session-ID >>>>> > > ---- Alice B2BUA Bob-phone Bob-computer >>>>> > > {A} |---INVITE--->| | | >>>>> > > {A} | |---INVITE-->| | >>>>> > > {B,A} | |<--200 OK---| | >>>>> > > {B,A} |<--200 OK----| | | >>>>> > > {A,B} |-----ACK---->| | | >>>>> > > {A,B} | |---ACK----->| | >>>>> > > {A} | |---INVITE------------->| >>>>> > > {Bc,A} | |<--200 OK--------------| >>>>> > > {A,Bc} | |---ACK---------------->| >>>>> > >>>>> > James >>>>> > >>>>> > At 12:13 AM 11/21/2012, Paul E. Jones wrote: >>>>> > > Brett, >>>>> > > >>>>> > > Well, this is certainly different. Does the phone ring? >>>>> >>>>>Yes; however I guess that it actually depends upon other services and >>>>>configuration. >>>>> >>>>> > > Does the computer ring? >>>>> >>>>>Yes; however I guess that it actually depends upon other services and >>>>>configuration. >>>>> >>>>> > > Does the user independently answer each one of those devices? >>>>> >>>>>Yes; however I guess that it actually depends upon other services and >>>>>configuration. >>>>> >>>>> > > And what would happen if the PC has only audio? >>>>> >>>>>It would reject the offer with 488 or 606. >>>>> >>>>> > > I assume only the B2BUA knows the capabilities of >>>>> > > devices in advance? >>>>> >>>>>It can know the capabilities; however the B2BUA is mostly just acting >>>>>per service configuration. >>>> >>>>_______________________________________________ >>>>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 >>