Re: [splices] Initiate an A/V Call Using Two Separate Devices proposal

"Worley, Dale R (Dale)" <> Tue, 07 June 2011 15:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C505111E815A for <>; Tue, 7 Jun 2011 08:56:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.099
X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H5A1iy3oKYKv for <>; Tue, 7 Jun 2011 08:56:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0F57A11E818E for <>; Tue, 7 Jun 2011 08:56:27 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAPZJ7k3GmAcF/2dsb2JhbABSph53rloCm2eGIQSVc4p4
X-IronPort-AV: E=Sophos;i="4.65,333,1304308800"; d="scan'208";a="192187406"
Received: from unknown (HELO ([]) by with ESMTP; 07 Jun 2011 11:56:07 -0400
X-IronPort-AV: E=Sophos;i="4.65,333,1304308800"; d="scan'208";a="630276487"
Received: from (HELO ([]) by with ESMTP; 07 Jun 2011 11:56:07 -0400
Received: from ([]) by ([2002:870b:3414::870b:3414]) with mapi; Tue, 7 Jun 2011 11:56:06 -0400
From: "Worley, Dale R (Dale)" <>
To: "Shekh-Yusef, Rifaat (Rifaat)" <>, "" <>
Date: Tue, 7 Jun 2011 11:56:06 -0400
Thread-Topic: [splices] Initiate an A/V Call Using Two Separate Devices proposal
Thread-Index: AcwcA9ICWlHJ0iFSQrC3DgLgYMzGCQJJsIlI
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [splices] Initiate an A/V Call Using Two Separate Devices proposal
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Jun 2011 15:56:30 -0000

These are interesting call flows, and seem to be based on the idea of having a 3PCC-style aggregation controller in the call.

I think that the INVOKE URNs could be made simpler and more systematic.  The problem with the ones shown is that they depend on particular media types implicitly triggering the desired behavior; I envision an ever-expanding list of URNs for specific circumstances.  Instead, how about constructing one URN whose purpose is to tell the target to initiate a call, but to specify one or more other UAs as "aggregation slaves":  <urn:invoke:call:initiate;aggregate=[my URI];target=sip:bob@whatever>.  Or we may want to add a parameter meaning "only accept a particular media type from this aggregation slave":  <urn:invoke:call:initiate;aggregate=[my URI];media=video;target=sip:bob@whatever>.

Both of the given examples seem to have the same pattern:  The device from which the user is initiating the call isn't the one that is the aggregation controller.  Shouldn't there be one example where it is and one where it isn't?