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
- [Stox] Mapping for media signaling: still about t… Markus.Isomaki
- Re: [Stox] Mapping for media signaling: still abo… Emil Ivov
- Re: [Stox] Mapping for media signaling: still abo… Philipp Hancke
- Re: [Stox] Mapping for media signaling: still abo… Markus.Isomaki
- Re: [Stox] Mapping for media signaling: still abo… Peter Saint-Andre
- Re: [Stox] Mapping for media signaling: still abo… Philipp Hancke
- Re: [Stox] Mapping for media signaling: still abo… Markus.Isomaki
- Re: [Stox] Mapping for media signaling: still abo… Peter Saint-Andre
- Re: [Stox] Mapping for media signaling: still abo… Saúl Ibarra Corretgé