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

Paul Kyzivat <> Mon, 06 June 2011 19:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0FDD71F0C5B for <>; Mon, 6 Jun 2011 12:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.199
X-Spam-Status: No, score=-110.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8j3XDrGe0Wpx for <>; Mon, 6 Jun 2011 12:48:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8D8D21F0C44 for <>; Mon, 6 Jun 2011 12:48:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2503; q=dns/txt; s=iport; t=1307389691; x=1308599291; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=xiX3fZcer6OAS3WlWcEzWuSQTS/go5mQ8LITmuR+zEc=; b=RwC2u/ioL63k3bcPxnf4WvAdO0uXfUJ42NQB+S+9Xgx1xQiTzv1cK26/ S+gFA65rnrwI7BzesLzWYogI/wKZXksbN6lR5K2+BF5SLqA0nlqerMquM XuSN76xYdZ+e5xfFAwFPhJhSdIBSyYPvA2s9l5ds3OQAIvfIWTCmIAjRj 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjkHAGUu7U2tJXG9/2dsb2JhbABTl36OIXerSp4BhiEEkHmESIQxhl0
X-IronPort-AV: E=Sophos;i="4.65,327,1304294400"; d="scan'208";a="460629411"
Received: from ([]) by with ESMTP; 06 Jun 2011 19:48:11 +0000
Received: from [] ( []) by (8.14.3/8.14.3) with ESMTP id p56JmAJ8000544 for <>; Mon, 6 Jun 2011 19:48:10 GMT
Message-ID: <>
Date: Mon, 06 Jun 2011 15:48:10 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
References: <AcwcBjEKPHRsQSI9R9CEF7Om5nHptA==> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 19:48:12 -0000

On 6/6/2011 3:35 PM, Alan Johnston wrote:
> If I understand correctly, there will be two separate RTP streams, two m= lines?
> If this is the case, then two separate NAT traversal mechanisms will be used (i.e. ICE rubs twice or two relays used). As far as ZRTP or other media path keying protocols, each session will be keyed separately. With ZRTP the endpoint will see two different ZIDs.  This does unfortunately mean two Diffie Hellman calculations.
> Since these are separate sessions, each will have an RTCP session as well, and these may need NAT traversal as well.
> So this will work, but things like logging and quality reporting will be quite complicated.

As Dale mentioned, this also depends on the other end doing the "right 
thing" with this case. It is a leap of faith to assume it will realize 
it should accept both streams and use one for input and the other for 

ISTM its at least as likely that it would accept the first stream, 
reject the second, and then have only a one-way "conversation".


> - Alan -
> On Jun 6, 2011, at 2:07 PM, "Worley, Dale R (Dale)"<>  wrote:
>> ________________________________________
>> From: [] On Behalf Of Peter Musgrave []
>> I have concerns about this approach. Fundamentally the RTP stream is not symmetric (in the sense of RFC4961). This has consequences for NAT traversal, general interoperability and media path security schemes like ZRTP.
>> _______________________________________________
>> I have to agree and disagree...  As Rifaat diagrammed it, the call should work, as it uses already-defined SIP facilities.  Indeed, it's rather clever, I'd never thought of joining a sendonly dialog with a recvonly dialog.  There are some limitations, in that we depend on the far-end UA to execute the join in the way we want.
>> The problems you raise, those of asymmetric RTP, already exist -- One can make a sendonly audio call, or a recvonly audio call.  We need to ensure that NAT traversal and ZRTP work correctly when  media stream is set up to be one-way.
>> Dale
>> _______________________________________________
>> splices mailing list
> _______________________________________________
> splices mailing list