Re: [splices] draft-loreto-splices-disaggregated-media-02: competing protocol analysis

"Worley, Dale R (Dale)" <> Mon, 08 August 2011 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A82E21F8B4B for <>; Mon, 8 Aug 2011 09:34:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.959
X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nVYe1xbJoGga for <>; Mon, 8 Aug 2011 09:34:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DA8A321F8B47 for <>; Mon, 8 Aug 2011 09:34:44 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.67,338,1309752000"; d="scan'208";a="200725155"
Received: from unknown (HELO ([]) by with ESMTP; 08 Aug 2011 12:35:10 -0400
Received: from (HELO ([]) by with ESMTP; 08 Aug 2011 12:32:05 -0400
Received: from ([]) by ([::1]) with mapi; Mon, 8 Aug 2011 12:35:10 -0400
From: "Worley, Dale R (Dale)" <>
To: Salvatore Loreto <>, "" <>
Date: Mon, 8 Aug 2011 12:35:08 -0400
Thread-Topic: [splices] draft-loreto-splices-disaggregated-media-02: competing protocol analysis
Thread-Index: AcxRuCacSsx876BFTdOlGayTHtrxcgEMBV5C
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] draft-loreto-splices-disaggregated-media-02: competing protocol analysis
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: Mon, 08 Aug 2011 16:34:45 -0000

> From: Salvatore Loreto []

> > As section 4.1.4 notes, this can be done even if the old controller
> > has died, as long as the new controller has obtained all the dialog
> > identifiers beforehand.  (Although the dialog event package does not
> > have any way of indicating "This dialog is to control an additional UA
> > for dialog XXX." -- We should define appropriate extensions.)
> Dale, do we really need it?
> we can derive the information from the fact that a dialog is between
> a UA and the Controller
> and we can guess which is the Controller as the common UA endpoint
> among all the existing dialogs.

In principle, we need it:  Sippose I dial from my phone
( to Alice, then put Alice on hold, then on
another appearance of 123, I dial Bob, and then attach to Bob's call
the video UA on my PC.  At that point, a dialog event from will report (1) a dialog from 123 to Alice, (2) a
dialog from 123 to Bob, and (3) a dialog from 123 to my PC.  But (1)
isn't part of the aggregation.  It's even more complicated if I attach
a *different* video UA to call (1); then there are two groups of two

> > We don't have any mechanism for one controller to tell another
> > controller to take over the coordination role.  We should define that.

> at moment only the controller can decide to pass the role to another one,
> the Controller role can not be take over.
> More we do not have an algorithm to decide who among all the UAs
> has to take over the role.

It would be helpful if each secondary UA can declare whether or not it
can be an aggregation controller.  Although it is sufficient if, when
the current controller attempts to pass the controller role to another
UA, the second UA can reject the request.