Subject: [MMUSIC] Future of SDPCapNeg and SDPMedCapNeg (and MMUSIC ?)

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 25 Jan 2010 13:55:46 +0100

Hi folks

I am currently working on an update to the image attribute draft after a longer break. In this draft I reference to both SDPCapNeg and SDPMedCapNeg. I am however a bit concerned about the two drafts. The progress is really slow, will these drafts get an RFC number ?

In addition. MMUSIC as a whole is also quite slow these days, I guess this is one key reason why a lot of work here has stalled, the group wakes up for a few weeks three times a year but is otherwise asleep.

/Ingemar
=================================
INGEMAR JOHANSSON  M.Sc. 
Senior Research Engineer 

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com 
Visit http://labs.ericsson.com !
=================================

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Mon, 25 Jan 2010 07:11:30 -0600

> In addition. MMUSIC as a whole is also quite slow these days, I guess this is one key reason why a lot of work here has stalled, the group wakes up for a few weeks three times a year but is otherwi…

This is also relevant to the work that the SIP Forum is doing to try to
improve the ITU's T.38 recommendation this year; the ability to
negotiate media stream capabilities would be very, very welcome in the
next version of T.38, but the ITU won't include normative references to
IETF drafts for obvious reasons.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: "Roni Even" <[email-masked]>
Date: Mon, 25 Jan 2010 16:50:29 +0200

Hi,
The SDPCapNeg is waiting for update from Flemming.
The  SDPMedCapNeg was ready for WGLC since the latest revision addressed the
open comments
Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ingemar Johansson S
> Sent: Monday, January 25, 2010 2:56 PM
> To: [email-masked]
> Subject: [MMUSIC] Future of SDPCapNeg and SDPMedCapNeg (and MMUSIC ?)
> 
> Hi folks
> 
> I am currently working on an update to the image attribute draft after
> a longer break. In this draft I reference to both SDPCapNeg and
> SDPMedCapNeg. I am however a bit concerned about the two drafts. The
> progress is really slow, will these drafts get an RFC number ?
> 
> In addition. MMUSIC as a whole is also quite slow these days, I guess
> this is one key reason why a lot of work here has stalled, the group
> wakes up for a few weeks three times a year but is otherwise asleep.
> 
> /Ingemar
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Tue, 26 Jan 2010 20:43:35 +0100

Like to add that SDPCapNeg is referred by 

1) 3GPP 24.229 (and SDPMedCapNeg is proposed too)

and SDPCapNeg and SDPMedCapNeg both are referred by 

2) ITU-T Draft Revised V.152

3) ITU-T Draft Revised T.38

4) ETSI TISPAN TR WI-03215

besides the
5) SIP Forum activities mentioned by Kevin.

The industry is thus waiting on RFC numbers and publication by IETF 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin P. Fleming
Sent: Montag, 25. Januar 2010 14:12
To: Ingemar Johansson S
Cc: [email-masked]
Subject: Re: [MMUSIC] Future of SDPCapNeg and SDPMedCapNeg (and MMUSIC ?)

> In addition. MMUSIC as a whole is also quite slow these days, I guess this is one key reason why a lot of work here has stalled, the group wakes up for a few weeks three times a year but is otherwi…

This is also relevant to the work that the SIP Forum is doing to try to improve the ITU's T.38 recommendation this year; the ability to negotiate media stream capabilities would be very, very welcome in the next version of T.38, but the ITU won't include normative references to IETF drafts for obvious reasons.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked] Check us out at www.digium.com & www.asterisk.org  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: Montag, 25. Januar 2010 15:50
> To: 'Ingemar Johansson S'; [email-masked]
> Subject: Re: [MMUSIC] Future of SDPCapNeg and SDPMedCapNeg 
> (and MMUSIC ?)
> 
> Hi,
> The  SDPMedCapNeg was ready for WGLC since the latest 
> revision addressed the open comments Roni Even
>

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 27 Jan 2010 09:28:46 +0100

Hi

I can understand the desire to see reference implementations. This is however, I believe, one area where IETF and other standards foras differ. 
While IETF is much in favor of the "running code" principle it is not quite the same e.g in 3GPP. Instead there is a preference to write a spec and then implement from it. There are of course examples of "running code", one example is the development of media codecs where normative implementations of encoder+decoder or just the decoder exist. 
In the majority of cases however the specifications have to do, proprietary implementations of specifications exists but for varius reasons they stay proprietary.

/Ingemar

> From: Jean-Francois Mule [mailto:[email-masked]] 
> Sent: den 26 januari 2010 21:50
> To: Schwarz Albrecht; Ingemar Johansson S; [email-masked]
> Subject: RE: [MMUSIC] Future of SDPCapNeg and SDPMedCapNeg 
> (and MMUSIC ?)
> 
> More than the other SDO spec references, personally I am more 
> interested in reference implementations and folks who need it 
> in deployments. Real-time fax has been an issue some folks 
> have raised for some time and some pb statements are being 
> discussed in dispatch.
> 
> Of course those people would send reviews based on their 
> running code and field experience.  That has somewhat been 
> lacking on SDP capneg and certainly on SDP media capneg.
> 
> Not to say that we should not move this work forward as fast 
> as possible but if this is so important, we should see more 
> constructive feedback on these on the list.
> 
> Jean-Francois.
> 
> > Behalf Of Schwarz Albrecht
> > Sent: Tuesday, January 26, 2010 12:44 PM
> > To: Ingemar Johansson S; [email-masked]
> (and MMUSIC 
> > ?)
> > Behalf Of Kevin P. Fleming
> (and MMUSIC 
> > ?)
> > > I am currently working on an update to the image attribute draft
> > after a longer break. In this draft I reference to both 
> SDPCapNeg and 
> > > In addition. MMUSIC as a whole is also quite slow these days, I
> > guess this is one key reason why a lot of work here has 
> stalled, the 
> > group wakes up for a few weeks three times a year but is otherwise 
> > asleep.
> > 
> > This is also relevant to the work that the SIP Forum is 
> doing to try 
> > to improve the ITU's T.38 recommendation this year; the ability to 
> > next version of T.38, but the ITU won't include normative 
> references 
> > to IETF drafts for obvious reasons.
> > 
> > --
> > Kevin P. Fleming
> > > The  SDPMedCapNeg was ready for WGLC since the latest revision 
> > > addressed the open comments Roni Even
> > >

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Wed, 27 Jan 2010 11:57:05 +0100

Do agree. 
The "running code" argument should not be used as a major condition for delaying approval.
Because there might be still inherent issues (see RFC 3264).
Because we got already running code for the simple capability negotiation framework (RFC 3407).
Because the implementation of the CapNeg technology may be accelerated if approved RFCs would be available, - and may become so much faster mature.

In general: no objections against "running code" justification, however, any "formal specification" (of the protocol) would be beneficial too. 

-Albrecht

> From: Ingemar Johansson S [mailto:[email-masked]] 
> Sent: Mittwoch, 27. Januar 2010 09:29
> To: Jean-Francois Mule; Schwarz Albrecht; [email-masked]
> I can understand the desire to see reference implementations. 
> This is however, I believe, one area where IETF and other 
> standards foras differ. 
> While IETF is much in favor of the "running code" principle 
> it is not quite the same e.g in 3GPP. Instead there is a 
> preference to write a spec and then implement from it. There 
> are of course examples of "running code", one example is the 
> development of media codecs where normative implementations 
> of encoder+decoder or just the decoder exist. 
> In the majority of cases however the specifications have to 
> do, proprietary implementations of specifications exists but 
> for varius reasons they stay proprietary.
> 
> 
> /Ingemar
> 
> 
> > interested in reference implementations and folks who need it in 
> > deployments. Real-time fax has been an issue some folks have raised 
> > for some time and some pb statements are being discussed in 
> dispatch.
> > 
> running code 
> > and field experience.  That has somewhat been lacking on SDP capneg 
> > and certainly on SDP media capneg.
> > 
> > Not to say that we should not move this work forward as fast as 
> > possible but if this is so important, we should see more 
> constructive 
> > > > > ================================= INGEMAR JOHANSSON  M.Sc.
> > > > > Senior Research Engineer
> > > > >
> > > > > Ericsson AB
> > > > > Multimedia Technologies
> > > > > Labratoriegränd 11
> > > > > 971 28, Luleå, Sweden
> > > > > Phone +46-1071 43042
> > > > > SMS/MMS +46-73 078 3289
> > > > > [email-masked] www.ericsson.com Visit 
> > > > > http://labs.ericsson.com !

---

From: "Roni Even" <[email-masked]>
Date: Wed, 27 Jan 2010 14:26:25 +0200

Hi,
The SDPCapNeg was waiting for update from the editor for a long time, I
thought it was supposed to happen in 2009.

As for requirements, some of the video conferencing system manufacturer are
writing an interoperability document for supporting multiple video streams
based on SDPCAPNeg. This is done at the IMTC. 

Roni Even

> Sent: Wednesday, January 27, 2010 10:29 AM
> I can understand the desire to see reference implementations. This is
> however, I believe, one area where IETF and other standards foras
> differ.
> While IETF is much in favor of the "running code" principle it is not
> quite the same e.g in 3GPP. Instead there is a preference to write a
> spec and then implement from it. There are of course examples of
> "running code", one example is the development of media codecs where
> normative implementations of encoder+decoder or just the decoder exist.
> In the majority of cases however the specifications have to do,
> proprietary implementations of specifications exists but for varius
> reasons they stay proprietary.
> 
> 
> /Ingemar
> 
>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 27 Jan 2010 15:41:31 +0100

> thought it was supposed to happen in 2009.
It was indeed. It's good to see that people are actually waiting for 
this document to move forward, so I appreciate all the comments on that. 
I am currently working on resolving the remaining open comments from the 
IESG review (almost done) and an update will be available in the 
timeframe indicated separately by Jean-Francois. Hopefully we can then 
move to RFC publication.

Thanks

-- Flemming