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

[<[e-mail]>]

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