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

Peter Saint-Andre <> Sun, 28 July 2013 10:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20BA521F9D4C for <>; Sun, 28 Jul 2013 03:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.729
X-Spam-Status: No, score=-101.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZxH6HtNPibX9 for <>; Sun, 28 Jul 2013 03:20:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C384E21F9DA1 for <>; Sun, 28 Jul 2013 03:20:03 -0700 (PDT)
Received: from ergon.local (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id DB23240049; Sun, 28 Jul 2013 04:22:06 -0600 (MDT)
Message-ID: <>
Date: Sun, 28 Jul 2013 12:20:00 +0200
From: Peter Saint-Andre <>
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
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [Stox] Mapping for media signaling: still about the scope
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 28 Jul 2013 10:20:37 -0000

On 6/20/13 1:12 PM, wrote:
> Hi Emil,

Hi Markus, at the XMPP hackfest yesterday I chatted about related issues
with Philipp Hancke, which triggered a few thoughts...

> See inline.
> Emil Ivov [] wrote:
>> On 19.06.13, 13:56, 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': 
>>> 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.
> Right. That's good.
>>> 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.
> That's one of the "administrative" decisions we should make about the
> "first release" of the media signaling mapping *RFC*. Do we only take
> in features/extensions that are completed RFCs or XSF XEPs, so that
> we for quite big certainty can get a mature document to IESG in
> October. And then extend it with new features once they complete,
> perhaps one or two years later, perhaps in multiple small steps. Or,
> do we already take features like "bundle" and "trickle-ICE" in, and
> aim to get the document to IESG at some later point, for instance
> March 2014. Trickle-ICE for SIP may not take long, but I bet it will
> at least take longer than this WG is supposed to live ;-)
> I don't have an opinion about this as a co-chair. This is a question
> to people implementing and deploying the gateways or relying on them.
> What is the most useful initial scope for you? How important it is to
> have an RFC out this year vs. covering as many features as possible?
> I mean technically a draft might be as useful to an implementer as an
> RFC on those parts that are stable while others are developed, but
> would there be some
> interoperability/technical/political/marketing/getting-actually-something-completed
> reason to get an RFC out ASAP?
> The only guidance we have at this point is that our charter expects
> us to complete in October, and in this case, unlike the normal IETF
> WG process, I at least as a co-chair intend to take that seriously
> :-)
>>> -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.
> Good, then my understanding seems to be correct.
>>> 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 :)
> Yes, let's stick to that theory ;-)
> ...
>>> -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.
> OK, that simplifies things as well. (Again was just checking I'm not
> missing any end-to-end magic that might exist. But apparently not
> ;-)
>> Thoughts?
>>> -How will we extend the mapping spec in the future and how should
>>> the initial spec take this into account.
>> As in administratively?
> In some sense yes. I would expect perhaps some brief section that
> gives guidelines to the authors who in the future want to extend this
> mapping spec with some new feature.
> And would be rather do a full-fledged '-bis' spec at some point or a
> bunch or incremental extension drafts on top of the baseline. As an
> example "An extension to SIP-XMPP media signaling mapping to support
> trickle-ICE".

I like that approach. The Jingle XEPs already define SDP mappings for
the base use cases, and that content could be moved to the stox-media
I-D. If additional features are defined in SIP, SDP, or Jingle
(trickle-ICE, BUNDLE, multistream, etc.) then we can specify those in
incremental extensions.


Peter Saint-Andre