Re: [splices] Using Two Separate Devices to Start a Conversation proposal

Peter Musgrave <> Mon, 06 June 2011 23:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF12A1F0C4E for <>; Mon, 6 Jun 2011 16:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.428
X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.570, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id idvHSKaIrGKN for <>; Mon, 6 Jun 2011 16:27:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C45E81F0C44 for <>; Mon, 6 Jun 2011 16:27:58 -0700 (PDT)
Received: by fxm15 with SMTP id 15so3177519fxm.31 for <>; Mon, 06 Jun 2011 16:27:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8imESN9X+fZaIhnjCtuKQJqN5Z9KJy07ZUOvvA8WmpU=; b=MtTVQoIwCLGzcfc4qrMhn4BrCQGajbJuzPj9nfJr+uHAP8mldbKklPM4QlaZxvSooM cIzh+65T/OyjHfyYDr5EkVsRbNmjyLuc5F+EPTcqQQHpXapsvTYOzq6ihlOlx7LGaUds wJL6xquLXYWWQV70rn3D0hF3gUvgJNVqSd9GQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=M2cUKU5Dkjz6WdBbogho1uniDagXT1wTY1LpE8auA71J60uP6PeDX4gov9aYbaw/nQ O1wEPXQsDhsjCReSRqpPiwfGtV7BvYLZ/rXQZDyEwhp8LZVGDmQO1nYwl8f+++BTz9K0 ChwgMPxlinlH8aPjyCmPASHO1CwS7c89C3ICw=
MIME-Version: 1.0
Received: by with SMTP id h18mr1736646fas.46.1307402877923; Mon, 06 Jun 2011 16:27:57 -0700 (PDT)
Received: by with HTTP; Mon, 6 Jun 2011 16:27:57 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Mon, 6 Jun 2011 19:27:57 -0400
Message-ID: <>
From: Peter Musgrave <>
To: Alan Johnston <>
Content-Type: multipart/alternative; boundary=0023545309701df23c04a513744a
Cc: "" <>
Subject: Re: [splices] Using Two Separate Devices to Start a Conversation 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: Mon, 06 Jun 2011 23:28:00 -0000

Hi all,

My assumptions were that:
- Alice's desk phone is doing the media aggregation and creating a reINVITE
for Bob with a=sendrecv and asymmetric media:
  * media is sent from Bob to Alice desk phone
  * media is sent from Alice Computer to Bob

As far as Bob knows this is a dialog only with Alice's deskphone. Bob does
not have to support SPLICES or do anything special.

Bob must handle asymmetric RTP from Alice.


I agree that requiring media relay does become a bad idea when the relaying
element is e.g a cellphone.

Do we think that having asymmetric RTP will be ok? A lot of implementation
have worked toward symmetric RTP (and some will only play RTP arriving from
the place they are sending to! [1 implementation at SIPIT28, 3 at SIPIT27 -
so maybe not worth worrying about]). Are there any issues with ZRTP or use
of ICE? [I am not an ICE expert so I can't recall if symmetric RTP was baked
into ICE, umm "frozen in" to ICE maybe?]



On Mon, Jun 6, 2011 at 5:45 PM, Alan Johnston <>wrote;wrote:

> But isn't the INVITE Join received at Alice's Desk Phone?  If so, then
> a normal Join will result in Alice's Desk Phone performing mixing of
> audio streams from Alice's PC, Alice's Desk Phone, and Bob.  I thought
> what was desired (and shown by Rifaat's flow) was that Alice's Desk
> phone did not mix the media, but instead inserted/spliced the media
> from Alice's PC into the dialog with Bob, resulting in a re-INVITE to
> Bob with two m= lines.
> - Alan -
> On Mon, Jun 6, 2011 at 4:15 PM, Worley, Dale R (Dale) <>
> wrote:
> > No, surely it is an ordinary join.  At the far UA, there are two incoming
> dialogs, each with one audio m= line.  The only oddity is that one dialog is
> recvonly (at the far UA), and so is never sent media.  The other dialog is
> sendonly (at the far UA) and so never provides audio to the mixing, but is
> only sent the result of the mixing.  The effect is that the far UA's input
> audio is sent only to the second dialog, and the far UA's output audio is
> driven only by the first dialog.
> >
> > Dale
> >
> _______________________________________________
> splices mailing list