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

[Peter Saint-Andre <[e-mail]>]

On 6/20/13 1:12 PM, [e-mail] 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:[e-mail]] wrote:
> 
>> On 19.06.13, 13:56, [e-mail] 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/