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

From: <[email-masked]>
Date: Wed, 19 Jun 2013 11:56:24 +0000

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, including "bundle" and "trickle-ICE". We can't know about what features will be added later on.

-          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.

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

Ideally, some things might be mapped transparently in the gateway in an "algorithmic" manner. 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.

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:

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

-          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".)

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

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

---

From: Emil Ivov <[email-masked]>
Date: Wed, 19 Jun 2013 20:00:11 +0200

Hey Markus

On 19.06.13, 13:56, [email-masked] wrote:
> 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 :)

>  > 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

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 19 Jun 2013 20:15:50 +0200

Am 19.06.2013 20:00, schrieb Emil Ivov: [...]
> OK, so how about starting with 3261, 3264, 4585, 5285, 5761.

That is the core i'm using in my sdp<->jingle mapping for webrtc 
purposes. Add 4568 (sdes, a=crypto), 5763 (a=fingerprint for dtls-srtp) 
and possibly 5576 (a=ssrc) to that list.

> Personally I wouldn't even mind having BUNDLE, we'd just need to have

You can exploit the same-icepwd/ufrag property from 
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-04#section-8.1 
-- I haven't checked for backward compability issues though. That way it 
seems we'd only need to have a disco feature for it along with a 
paragraph in XEP-0176.

cheers

philipp

---

From: <[email-masked]>
Date: Thu, 20 Jun 2013 11:12:47 +0000

Hi Emil,

See inline.

Emil Ivov [mailto:[email-masked]] wrote:

> > 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
> 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 :-)

> 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.
> 

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 ;-)

...

> > 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".)
> 

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 ;-)

> > initial spec take this into account.

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". 

Markus