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

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 28 Jul 2013 12:20:00 +0200

On 6/20/13 1:12 PM, [email-masked] 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 [mailto:[email-masked]] wrote:
> 
>> On 19.06.13, 13:56, [email-masked] 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.
>> 
> 
> 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

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Philipp Hancke <[email-masked]>
Date: Sun, 28 Jul 2013 12:56:36 +0200

Am 28.07.2013 12:20, schrieb Peter Saint-Andre:
[...]
> (trickle-ICE, BUNDLE, multistream, etc.) then we can specify those in

Right. The problem on the XSF side is that this mapping is currently 
spread over (from the top of my head) XEPs 0166, 0167, 0176, (0177 
doesn't bother mapping), 0293, 0294 and 0320. This is something that 
needs to be more centralized anyway and the stox-media draft might be 
the normative place to do this.

---

From: <[email-masked]>
Date: Sun, 28 Jul 2013 14:15:17 +0000

Hi Peter, Philipp,

Philipp Hancke wrote,
> Right. The problem on the XSF side is that this mapping is currently spread
> over (from the top of my head) XEPs 0166, 0167, 0176, (0177 doesn't bother
> mapping), 0293, 0294 and 0320. This is something that needs to be more
> centralized anyway and the stox-media draft might be the normative place to
> do this.
>

It sounds to me then that the STOX WG should:
- Consolidate the mappings for all stable specs and features into the current -media document and aim to publish it as an RFC according to the current charter, i.e. deliver it to the IESG (hopefully) already before IETF 88. The value of stabilizing and publishing that document would be that the mappings would be found in one place.
- Start, first as individual (non-WG) drafts, incremental extensions for the relevant new features (mentioned above). Perhaps one draft is enough for all of the listed ones if their timeline is roughly identical and there is interest to cover all of them. That draft would evolve as the actual extensions in IETF and XSF develop, and would get published as an RFC around the same time as them (next year?). If things progress well, we could adopt that draft as a STOX WG item around IETF 88. I believe it does fit content-wise ("mapping for media signaling") to our charter, we just need to create an additional milestone for it. I don't know if we should keep the WG active for just one document, but given the overhead of creating new WGs etc., I think that would make sense.

Saul's slides for next Thursday (https://dl.dropboxusercontent.com/u/2243619/stox-ietf87.pdf) seem to assume that approach. The chairs can perhaps create one-slider to be more explicit about the plan and scope. 

Markus

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 28 Jul 2013 16:47:51 +0200

On 7/28/13 4:15 PM, [email-masked] wrote:
> Hi Peter, Philipp,
> 
> Philipp Hancke wrote,
>> 
>> Am 28.07.2013 12:20, schrieb Peter Saint-Andre: [...]
>>> 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.
>> 
>> Right. The problem on the XSF side is that this mapping is
>> currently spread over (from the top of my head) XEPs 0166, 0167,
>> 0176, (0177 doesn't bother mapping), 0293, 0294 and 0320. This is
>> something that needs to be more centralized anyway and the
>> stox-media draft might be the normative place to do this.
>> 
> 
> It sounds to me then that the STOX WG should: - Consolidate the
> mappings for all stable specs and features into the current -media
> document and aim to publish it as an RFC according to the current
> charter, i.e. deliver it to the IESG (hopefully) already before IETF
> 88. The value of stabilizing and publishing that document would be
> that the mappings would be found in one place. - Start, first as
> individual (non-WG) drafts, incremental extensions for the relevant
> new features (mentioned above). Perhaps one draft is enough for all
> of the listed ones if their timeline is roughly identical and there
> is interest to cover all of them. That draft would evolve as the
> actual extensions in IETF and XSF develop, and would get published as
> an RFC around the same time as them (next year?). 

I think that is a reasonable approach.

> If things progress
> well, we could adopt that draft as a STOX WG item around IETF 88. I
> believe it does fit content-wise ("mapping for media signaling") to
> our charter, we just need to create an additional milestone for it. I
> don't know if we should keep the WG active for just one document, but
> given the overhead of creating new WGs etc., I think that would make
> sense.

I am not fully sure about keeping the WG around, but I leave such
decisions up to the chairs and ADs. ;-)

> Saul's slides for next Thursday
> (https://dl.dropboxusercontent.com/u/2243619/stox-ietf87.pdf) seem to
> assume that approach. The chairs can perhaps create one-slider to be
> more explicit about the plan and scope.

That sounds helpful!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Sun, 28 Jul 2013 23:38:11 +0200

> - Start, first as individual (non-WG) drafts, incremental extensions for the relevant new features (mentioned above). Perhaps one draft is enough for all of the listed ones if their timeline is rou…

That sounds good to me!

> Saul's slides for next Thursday (https://dl.dropboxusercontent.com/u/2243619/stox-ietf87.pdf) seem to assume that approach. The chairs can perhaps create one-slider to be more explicit about the pl…

Yeah, I somewhat assumed that,but it's definitely up for discussion. Since I'm not all that familiar with all the process, please do let me know if you rather have some extra items added to the slides and I'll gladly do so.

Cheers,

--
Saúl Ibarra Corretgé
AG Projects