IETF Logo Mail Archive

Re: [MMUSIC] Trickle ICE for SIP Questions

Emil Ivov <emcho@jitsi.org> Wed, 24 July 2013 20:49 UTC

Return-Path: <emil@sip-communicator.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233DE11E8137 for <mmusic@ietfa.amsl.com>; Wed, 24 Jul 2013 13:49:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.389
X-Spam-Level:
X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTvRmwRmoHIz for <mmusic@ietfa.amsl.com>; Wed, 24 Jul 2013 13:49:18 -0700 (PDT)
Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8B69211E8241 for <mmusic@ietf.org>; Wed, 24 Jul 2013 13:49:16 -0700 (PDT)
Received: by mail-we0-f171.google.com with SMTP id q55so4819456wes.16 for <mmusic@ietf.org>; Wed, 24 Jul 2013 13:49:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=1xtRkDoy12mHZc6x9hvIMSBQirMwH5BhSsopEBGTVaY=; b=jRP5WMjAHkjtHwn05tkYXY7pJULqV7CuMWAYQujnUSLJ/MBp/YtJahQtitzQxo2S1m 4NbV2TEPIiZQmMTLwji4YtpKGlDAa7vClxkHekhJ6HMCyku4th9OfmZ7dBvRXbfnYCTU WYN5KtuZWAOj7bak4dmgE0PHCF4zwDmPywAxCxgHcKHQswK5FTEYi47D0eAzc6bMwE8a dH2YOc0+JhNe71KAyP5CF4R3us2LVLidwLLQaqEW85xr8O71I1wlZP67q9RNnCIFXv/9 McIBRs8L4AFqGuZuA5L1/ErYDFyusKLtavSNuRAhR1OycnlF0Kv/e5fmt9AHxosmZ51B xgEQ==
X-Received: by 10.194.78.42 with SMTP id y10mr27717601wjw.93.1374698955412; Wed, 24 Jul 2013 13:49:15 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:dd4c:7a03:b3a7:c01c]) by mx.google.com with ESMTPSA id iz8sm7927545wic.3.2013.07.24.13.49.13 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 13:49:14 -0700 (PDT)
Message-ID: <51F03DC8.70908@jitsi.org>
Date: Wed, 24 Jul 2013 22:49:12 +0200
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
References: <1CDFD781608D924094E43F573C351961BDE2DC@xmb-rcd-x13.cisco.com> <C5E08FE080ACFD4DAE31E4BDBF944EB11360D0D2@xmb-aln-x02.cisco.com>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB11360D0D2@xmb-aln-x02.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQm3KcRhGBRwcJiYZVjkDUW2UKZWoPnFkQLPvFAjxoaU7uewietTYnV3BQ1XeJLvytXL10Cr
Cc: Alan Johnston <alan.b.johnston@gmail.com>, MMUSIC IETF WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 20:49:23 -0000

On 24.07.13, 21:56, Cullen Jennings (fluffy) wrote:
>
> On Jul 24, 2013, at 12:22 PM, Vijaya Mandava (vimandav) <vimandav@cisco.com> wrote:
>
>> 180 with different to-tag would mean call is forked.
>> If uac side do not support call forking, then we cannot use this 180
>> response to collect trickled candidates.
>
> If it is a UAC, it supports this so I don't see the problem.

One problem is that the UAC could support it to the extent of making it 
visible to the user:

   "Your contact is being alerted on these N locations"

And of course there's also the fact that we would be creating several 
dialogs per call, that we'd then need to clean and garbage collect.

Why would we want to go there?

Emil

-- 
https://jitsi.org

v2.28.0 | Report a Bug | By Email | System Status