Re: [Stox] Mapping for media signaling: still about the scope

Emil Ivov <emcho@jitsi.org> Wed, 19 June 2013 18:00 UTC

Return-Path: <emil@sip-communicator.org>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3388A21F9DD1 for <stox@ietfa.amsl.com>; Wed, 19 Jun 2013 11:00:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 FWdDs-v4GYjY for <stox@ietfa.amsl.com>; Wed, 19 Jun 2013 11:00:16 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D85BB21F9DCF for <stox@ietf.org>; Wed, 19 Jun 2013 11:00:15 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id m6so994556wiv.2 for <stox@ietf.org>; Wed, 19 Jun 2013 11:00: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=hXFNMO/nCHjCdwsQb8o2BKjHp/1j+T6/LT6bVG08nTw=; b=nWOdPW9wxH1pIYWaCVV3UThPYji9d/peN/dSn87iffbaX3Ag3H3zy2f6NS0jtkbthA 06BN4eDe1PJNMa9xsxmKon06qJApRJwQ/1d8QM3eP17fI6DYx/Uh2wmJ/HNvzgyxw+u1 YmRqV1kKG1yftk2QZtXCHXG7RvLSVNYj0gtakuYp0AyF4TGoHkYbrVuvwfR7A0zhlt61 JioblU9I/O38/B45QUOWZYzCV3Q7WXHyxK61NMQ0Lz5jf9A/vwWEBc4lXoZYSBDaoP/m PRefWr8lLypacF6KsjN0L3ng62pXYeOgF97+sRQmTMWpsIKISEwBNT+nBKI7JU7Ujflx MDlA==
X-Received: by 10.194.63.229 with SMTP id j5mr3044922wjs.79.1371664814880; Wed, 19 Jun 2013 11:00:14 -0700 (PDT)
Received: from camionet.local ([2a01:e35:2e2c:f600:a929:df1f:bef6:68ec]) by mx.google.com with ESMTPSA id b11sm10818462wiv.10.2013.06.19.11.00.13 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 11:00:14 -0700 (PDT)
Message-ID: <51C1F1AB.1040701@jitsi.org>
Date: Wed, 19 Jun 2013 20:00:11 +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/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Markus.Isomaki@nokia.com
References: <E44893DD4E290745BB608EB23FDDB7620A01C877@008-AM1MPN1-042.mgdnok.nokia.com>
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620A01C877@008-AM1MPN1-042.mgdnok.nokia.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkMuw5jYysOFbauMRwyQmlGDV6xPLFivc7F830lGpVlbIXzHFT17xcXERNiRQlEUgZFXsfu
Cc: stox@ietf.org, saul@ag-projects.com, stpeter@stpeter.im
Subject: Re: [Stox] Mapping for media signaling: still about the scope
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2013 18:00:17 -0000

Hey Markus

On 19.06.13, 13:56, Markus.Isomaki@nokia.com wrote:
> Hi Emil, Saul, Peter, and others,
>
> Recently I raised some questions about the scope of the ‘sip-xmpp-media’
> and the related deliverable on the ‘mapping for media signaling’:
> http://www.ietf.org/mail-archive/web/stox/current/msg00025.html
>
> Now that STOX is officially up and running I’d like us to make an actual
> plan on what the scope of this document should be, i.e. what features
> are explicitly going to be part of this mapping spec. Although people
> have successfully implemented SIP-to-XMPP media signaling gateways, I at
> least see this topic to have some complexity due to:
>
> -SDP offer/answer is a moving target as new features are being added as
> we speak,

Well ... it is and it isn't. 3264 isn't really changing and all 
extensions are supposed to keep backward compatibility with it.

> including “bundle” and “trickle-ICE”. We can’t know about what
> features will be added later on.

No, but we could include some that we know of ... like "bundle" and 
"trickle-ICE" :).

Trickle ICE would be easier because we already have it in Jingle and the 
SIP version shouldn't take long.

> -There are features currently supported in XMPP that are not currently
>   supported in SIP (and perhaps vice versa?), such as the trickle-ICE
> support in Jingle.

As mentioned. I don't think trickle-ICE would be a problem. I believe 
separating transport and encoding information would be a bigger hurdle 
but if we accept that urn:ietf:rfc:3264 means one shouldn't do this.

> -Regardless of what is supported in each protocol in general, the actual
> SIP and XMPP clients will support different sets of features.

Right.

> Ideally, some things might be mapped transparently in the gateway in an
> “algorithmic” manner.

I don't believe this would be possible.

> And ideally, the clients supporting different
> feature sets can negotiate end-to-end without needing for the gateway to
> mediate. However, I’m not sure how easy this will be in practice.
>
> Actually one reason why I see these complications may be that I don’t
> have a very good overall understanding about how SDP O/A (as in RFC 3264
> syntax and semantics) is mapped to XMPP/Jingle (as in its XML based
> syntax) are in general kept “in synch”. For instance, if IETF extends
> SDP O/A in some way, will that always require an explicit corresponding
> extension XEP by the XSF, or is there some more straightforward
> “algorithmic” way to convey something new on the SIP/SDP side to the
> XMPP/Jingle side.

Well, the good thing about O/A extensions is that they generally 
preserve backward compatibility. This is valid for things like ICE, 
trickle ICE, rtcp-mux, bundle. So as long as we support 3264 we should 
be OK. I think :)

> In the earlier discussion the following proposal by Saul got some support:
>
>  > Could we perhaps have sip-xmpp-media be the base spec which uses the
> RFC3264 model and later extend it with ICE trickle and friends
>
> This also sounds fine to me on the high level. As people have already
> implemented these gateways, writing a document about how they do their
> work should be doable. However, we should elaborate this plan a bit
> beyond the one line of text.
>
> Emil, Saul: You have agreed to work as co-authors of this document.
> Thanks ;-) Would you be able to write a short proposal about:

Sure!

> -What end-to-end media setup features should the mapping spec explicitly
> cover.

OK, so how about starting with 3261, 3264, 4585, 5285, 5761.

I think we can also add trickle ICE since I don't believe we have much 
work left for SIP.

Personally I wouldn't even mind having BUNDLE, we'd just need to have 
the feature in Jingle.

> -What will happen to features supported on one or either side of the
> gateway that the gateway is not aware of– can some things be
> “transparently” mapped or will the gateway become the “blocking factor”
> in the middle. (I.e., will the session setup be limited to the features
> the gateway explicitly needs to “understand”.)

I don't think the gateway could just forward anything because this would 
imply a straightforward mapping from any SDP attribute to a Jingle element.

Maybe gateways could behave as regular SIP B2BUAs: they forward the 
things that they understand and they remove those that they don't 
understand or support.

Thoughts?

> -How will we extend the mapping spec in the future and how should the
> initial spec take this into account.

As in administratively?

Emil

> This would be very useful so we can set the expectations about what we
> can/should deliver in October, and what is possibly left for the future.
> Let me know if this sounds reasonable.
>
> Thanks,
>
>                  Markus
>

-- 
https://jitsi.org