Subject: [Stox] sip-xmpp-media: scope, transparency, extensibility?

From: <[email-masked]>
Date: Tue, 4 Jun 2013 12:00:30 +0000

Hi,

A high-level comment about sip-xmpp-media [1]:

SDP/Jingle Offer/Answer and ICE are moving targets by themselves. For instance right now MMUSIC WG is working on new features such as "trickle-ICE" (adding new candidates on the fly - I know this is already supported in Jingle) and "bundle" (multiplexing several RTP sessions/streams into a single transport-level packet flow).

We need to ensure that the sip-xmpp-media RFC-to-become is generic enough to stay valid even when such extensions are developed, and we have a story on how and where the SIP-XMPP mappings to various extensions can be developed if needed.

For instance "bundle", AFAIK, is going to be entirely SDP/Jingle level issue, so presumably it will be enough that after the MMUSIC SDP spec is done, a mapping spec to Jingle is written in XSF? On the other hand, trickle-ICE, AFAIK, will require the use of SIP INFO (gasp! ;-) method to carry the new candidates. That seems like something that would require an extension (" a new RFC") to sip-xmpp-media in the IETF, explaining how Jingle's trickle is mapped to SIP's trickle.

Regards,
                Markus

[1] http://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-media/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 05 Jun 2013 15:29:56 -0600

On 6/4/13 6:00 AM, [email-masked] wrote:
> SDP/Jingle Offer/Answer and ICE are moving targets by themselves. For
> instance right now MMUSIC WG is working on new features such as
> “trickle-ICE” (adding new candidates on the fly – I know this is already
> supported in Jingle) and “bundle” (multiplexing several RTP
> sessions/streams into a single transport-level packet flow).
> 
> We need to ensure that the sip-xmpp-media RFC-to-become is generic
> enough to stay valid even when such extensions are developed, and we
> have a story on how and where the SIP-XMPP mappings to various
> extensions can be developed if needed.
> 
> For instance “bundle”, AFAIK, is going to be entirely SDP/Jingle level
> issue, so presumably it will be enough that after the MMUSIC SDP spec is
> done, a mapping spec to Jingle is written in XSF? On the other hand,
> trickle-ICE, AFAIK, will require the use of SIP INFO (gasp! ;-) method
> to carry the new candidates. That seems like something that would
> require an extension (“ a new RFC”) to sip-xmpp-media in the IETF,
> explaining how Jingle’s trickle is mapped to SIP’s trickle.  

Markus, thanks for your comments.

I've been thinking about this recently, too. I am now thinking that we
might want to remove the media signaling translation from the charter.
There's quite a bit of flux in this area these days, and tracking that
won't be easy (e.g., do we perhaps just need a way to send SDP over
XMPP?). I think we can finish all of the other charter items quickly.
I'm not as convinced about "sip-xmpp-media".

Peter

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

---

From: Emil Ivov <[email-masked]>
Date: Wed, 05 Jun 2013 23:45:51 +0200

Hey Markus,

On 04.06.13, 14:00, [email-masked] wrote:
> On the other hand, trickle-ICE, AFAIK, will require the use of SIP INFO
> (gasp! ;-) method to carry the new candidates.

Yes, but no one seems to mind and we actually seem to have rough 
consensus on the INFO. So I think this could be mapped relatively easily 
to transport-info-s

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Wed, 05 Jun 2013 23:49:08 +0200

> I'm not as convinced about "sip-xmpp-media".

Couldn't we maybe just leave this for a later milestone rather than 
completely dropping it? People are already working on different gateways 
to SIP/SDP and WebRTC and I believe that once the RTCWEB and CLUE cases 
have been addressed, there wouldn't be that much work.

Also, depending on the plan that gets chosen by RTCWEB/MMUSIC things 
could be really simple. This would be the case with Plan B or No Plan.

Cheers,
Emil

-- 
https://jitsi.org

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 05 Jun 2013 15:59:03 -0600

> could be really simple. This would be the case with Plan B or No Plan.

That's one approach. The other approach is to drop it for now, blast
through the easy stuff on the charter, then recharter.

Peter

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

---

From: Emil Ivov <[email-masked]>
Date: Thu, 06 Jun 2013 00:06:27 +0200

> through the easy stuff on the charter, then recharter.

I'd appreciate a couple of pointers about IETF best practices here.

Is there something wrong with a dormant WG? Is this considered bad 
practice and generally avoided?

Because if not, wouldn't it be easier to blast through the easy 
milestones then wait until ready to start work on the SDP translation. 
This way, once we are ready we won't have to go through the hassle of 
mustering consensus, finding victims for chairs, rechartering and most 
importantly: thinking of a new name!

Emil

-- 
https://jitsi.org

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 05 Jun 2013 16:15:48 -0600

> importantly: thinking of a new name!

The IESG likes to see progress. If the WG quickly finishes its other
milestones, then rechartering to do the media mapping would be fairly
straightforward.

Peter

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

---

From: Emil Ivov <[email-masked]>
Date: Thu, 06 Jun 2013 00:20:34 +0200

> milestones, then rechartering to do the media mapping would be fairly

OK, I see.

Emil

-- 
https://jitsi.org

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 6 Jun 2013 09:28:39 +0200

Hi,

> I'm not as convinced about "sip-xmpp-media".

Those are all new things mainly pushed by WebRTC which is also a moving target at this point IMHO.

XEP-0176 already specifies a way to tell endpoints that they should use the "legacy" offer/answer model and not send candidates in a session-info [0]. The XEP actually mentions it in the context of a SIP - XMPP gateway. Moreover, Emil and I already have working and interoperable implementations using this mechanism, FWIW.

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, or is that a no go?

[0]: http://xmpp.org/extensions/xep-0176.html#support-sdp

--
Saúl Ibarra Corretgé
AG Projects

---

From: Emil Ivov <[email-masked]>
Date: Thu, 6 Jun 2013 09:35:28 +0200

+1

On Thu, Jun 6, 2013 at 9:28 AM, Saúl Ibarra Corretgé
<[email-masked]> wrote:
> _______________________________________________
> stox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stox

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]                        PHONE: +33.1.77.62.43.30
http://jitsi.org                       FAX:   +33.1.77.62.47.31

---

From: <[email-masked]>
Date: Thu, 6 Jun 2013 14:25:44 +0000

Hi Saul,

> 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, or is that a no go?

Yes, that could be a good approach, and that was what I was also initially thinking. We just need to make sure that the scope of the baseline sip-xmpp-media is clear, and have a clean enough extensibility model for it, and good enough guidance on how the gateways can deal with a) feature disparity between SIP and XMPP clients they serve and b) features unknown to the gateway itself. I suppose it would be anyway a good idea to write somewhere something about the transparency or non-transparency of SIP-XMPP gateways wrt. new features. For instance a SIP proxy can - in theory - be fairly transparent to many types of new features (new headers, new header parameters, new payloads), but it is much harder to do that in a gateway. 

Markus  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Saúl Ibarra Corretgé
Sent: 06 June, 2013 10:29
To: Peter Saint-Andre
Cc: [email-masked]
Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility?

Hi,

On Jun 5, 2013, at 11:29 PM, Peter Saint-Andre <[email-masked]> wrote:

>> "trickle-ICE" (adding new candidates on the fly - I know this is 
>> already supported in Jingle) and "bundle" (multiplexing several RTP 
>> For instance "bundle", AFAIK, is going to be entirely SDP/Jingle 
>> level issue, so presumably it will be enough that after the MMUSIC 
>> SDP spec is done, a mapping spec to Jingle is written in XSF? On the 
>> other hand, trickle-ICE, AFAIK, will require the use of SIP INFO 
>> (gasp! ;-) method to carry the new candidates. That seems like 
>> something that would require an extension (" a new RFC") to 
>> sip-xmpp-media in the IETF, explaining how Jingle's trickle is mapped to SIP's trickle.
> 

--
Saúl Ibarra Corretgé
AG Projects

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 07 Jun 2013 13:31:29 -0600

> Yes, that could be a good approach, and that was what I was also initially thinking. We just need to make sure that the scope of the baseline sip-xmpp-media is clear, and have a clean enough extens…

Maybe I'll leave it up to Saúl and Emil to write that I-D. :-)

Peter

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

---

From: Emil Ivov <[email-masked]>
Date: Fri, 07 Jun 2013 21:37:28 +0200

> Maybe I'll leave it up to Saúl and Emil to write that I-D. :-)

Yeah, that should teach them! ;)

Personally I don't mind helping up, so sure, count me in! Saúl already 
has implemented a Jingle gateway, so we should probably be fine if we 
just documented that.

Emil

-- 
https://jitsi.org

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 07 Jun 2013 13:40:48 -0600

On 6/7/13 1:37 PM, Emil Ivov wrote:
>>>> 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, or
>>>> is that a no go?
>>>
>>> Yes, that could be a good approach, and that was what I was also
>>> initially thinking. We just need to make sure that the scope of the
>>> baseline sip-xmpp-media is clear, and have a clean enough
>>> extensibility model for it, and good enough guidance on how the
>>> gateways can deal with a) feature disparity between SIP and XMPP
>>> clients they serve and b) features unknown to the gateway itself. I
>>> suppose it would be anyway a good idea to write somewhere something
>>> about the transparency or non-transparency of SIP-XMPP gateways wrt.
>>> new features. For instance a SIP proxy can - in theory - be fairly
>>> transparent to many types of new features (new headers, new header
>>> parameters, new payloads), but it is much harder to do that in a
>>> gateway.
>>

Sure, these mapping specs are mostly just documenting what folks are
already doing in their gateway implementations.

Peter

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

---

From: <[email-masked]>
Date: Thu, 13 Jun 2013 06:56:49 +0000

Hi,

Peter Saint-Andre [mailto:[email-masked]] wrote: 
>Sure, these mapping specs are mostly just documenting what folks are already doing in their gateway implementations.
>

And I don't think either it needs to be more complicated than that. Just try to document the scope of the gateway's mapping capabilities as well as possible, and think about how we can later on extend them to support new features. The real-time media is the most interesting part in this sense.

And indeed, it's good to have volunteer co-authors for STOX documents. 

Markus

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 14 Jun 2013 09:36:32 +0200

> Maybe I'll leave it up to Saúl and Emil to write that I-D. :-)

Sorry, catching up... Sure, I already volunteered to do this and I still plan to :-)

Basically, as Emil said down below it would start as a description of what we ended up implementing and then try to iron out (some of) the problems we found along the way.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 14 Jun 2013 06:28:12 -0600

> Basically, as Emil said down below it would start as a description of what we ended up implementing and then try to iron out (some of) the problems we found along the way.

Great. If you're able to use parts of draft-saintandre-sip-xmpp-media as
a starting point, feel free!

Peter

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