Re: [MMUSIC] Hitchhiker's guide to SDP

"Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com> Wed, 07 March 2012 14:59 UTC

Return-Path: <albrecht.schwarz@alcatel-lucent.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629F921F84EB; Wed, 7 Mar 2012 06:59:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.17
X-Spam-Level:
X-Spam-Status: No, score=-7.17 tagged_above=-999 required=5 tests=[AWL=3.079, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lrqs3Mab1nMk; Wed, 7 Mar 2012 06:59:49 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id CD4D221F8564; Wed, 7 Mar 2012 06:59:48 -0800 (PST)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q27EuvK9000658 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 7 Mar 2012 15:59:11 +0100
Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.50]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 7 Mar 2012 15:58:59 +0100
From: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>, "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>, Bert Greevenbosch <Bert.Greevenbosch@huawei.com>
Date: Wed, 07 Mar 2012 15:58:58 +0100
Thread-Topic: [MMUSIC] Hitchhiker's guide to SDP
Thread-Index: Acz8UPhLdtyhqIOBRNq1QBXclwrtWAAHMlYwAADkzhA=
Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9621626AD30B@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com>
References: <BBF5DDFE515C3946BC18D733B20DAD230C3A03@XMB105ADS.rim.net> <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <CAHBDyN5p+=jMzM2LZBhWFkOh21x+najZ_cn-TXJBGtOJ1GwW9g@mail.gmail.com> <4F463159.5040903@ericsson.com> <CAHBDyN7V+pku-Ejn+1uzj9Nqo4Fs3V3W7eZMnZ8s3gA=YXQsMQ@mail.gmail.com> <4F4677D3.2090406@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> <4F573ED3.2030409@ericsson.com> <EDC0A1AE77C57744B664A310A0B23AE224C368E6@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE224C368E6@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Cc: "megaco@ietf.org" <megaco@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Hitchhiker's guide to SDP
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2012 14:59:50 -0000

> If I am a Megaco / H.248 user of SDP I suspect therefore I come up with a different viewpoint of what is core and what is not.

Good point.

The Megaco/H.248 hitchhiker's guide to SDP should include at least, e.g.:
1) ITU-T H.248.1 Version 3 Amendment 2: "Summary - H.248 usage of SDP"
2) ITU-T H.248.15: "SDP H.248 package attribute"
3) ITU-T H.248.39: "H.248 SDP parameter identification and wildcarding"
4) ITU-T H.248.49: "Session description protocol RFC and capabilities packages"
5) ITU-T H.248.80: "Usage of the revised SDP offer / answer model with H.248" (Draft)
6) ETSI 183 046: "SDP Interworking between Call/Session Control Protocols (SIP/SDP, RTSP/SDP; etc.) and the Gateway Control Protocol (H.248/SDP)"

Such an "Megaco/H.248 hitchhiker's guide to SDP" should be incorporated in an "Hitchhiker's guide to SDP" in my opinion.

Regards
Albrecht



-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: Mittwoch, 7. März 2012 15:25
To: Miguel A. Garcia; Bert Greevenbosch
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Hitchhiker's guide to SDP

I notice RFC 3264 is mentioned as one of the core specifications.

This only becomes core when SDP is used in the context of SIP.

If I am a Megaco / H.248 user of SDP I suspect therefore I come up with a different viewpoint of what is core and what is not.

We may need to address these different viewpoints, unless you want to make a guide that is entirely focused on SIP usage.

Regards

Keith

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Miguel A. Garcia
> Sent: 07 March 2012 10:56
> To: Bert Greevenbosch
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP
> 
> Bert,
> 
> Here is another document with the same purpose. You can use it for
> inspiration. This is a bit more complex document, because it has to deal
> with several different protocols, rather than only one.
> 
> http://tools.ietf.org/html/draft-ietf-opsawg-management-stds
> 
> The other document that you need to consult is the IANA SDP Parameters
> registry at:
> 
> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml
> 
> This contains a list of all the SDP extensions, and they all should be
> listed in the hitchhiker's guide.
> 
> /Miguel
> 
> On 07/03/2012 3:54, Bert Greevenbosch wrote:
> > Hi all,
> >
> > On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide to SDP".
> It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I have copied
> most initial text from there, and in addition included an initial list of
> RFCs / drafts that seem relevant.
> >
> > https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide-
> sdp/
> >
> > If the group is happy with this approach, I will be happy to maintain an
> editor's role, and write more text. Obviously other people's input will be
> highly appreciated, and indeed is needed.
> >
> > I look forward to your comments.
> >
> > Best regards,
> > Bert
> >
> > P.S. Unfortunately, I forgot to include "mmusic" in the name of the
> draft. How to deal with this?
> >
> >
> >
> > -----Original Message-----
> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Christer Holmberg
> > Sent: 27 February 2012 04:53
> > To: Gonzalo Camarillo; Mary Barnes
> > Cc: mmusic@ietf.org
> > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP
> >
> >
> > Hi,
> >
> > As a directorate member, I am willing to co-author such draft, should a
> decision to write one be taken.
> >
> > Regards,
> >
> > Christer
> >
> > -----Original Message-----
> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Gonzalo Camarillo
> > Sent: 23. helmikuuta 2012 19:31
> > To: Mary Barnes
> > Cc: mmusic@ietf.org
> > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP
> >
> > I agree.
> >
> > Gonzalo
> >
> > On 23/02/2012 7:06 PM, Mary Barnes wrote:
> >> I would think that in order for the document to have integrity that at
> >> least one of the directorate members should at least be a co-author.
> >>   Otherwise, I see a lot more stuff falling through the cracks and
> >> needing to be resolved during WGLC and later, which usually isn't a
> >> good thing.  The SIP Hitchhiker's guide provides a good example in
> >> that the author was also a primary contributor to RFC3261, etc.
> >>
> >> Mary.
> >>
> >> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo
> >> <Gonzalo.Camarillo@ericsson.com
> >> <mailto:Gonzalo.Camarillo@ericsson.com>>
> >> wrote:
> >>
> >>      Hi Mary,
> >>
> >>      yes, the members of the SDP directorate would need to review such
> a
> >>      guide. However, the fact that they agreed to be members of the
> >>      directorate does not mean they will necessarily have cycles to
> >>      significantly contribute to the creation of the guide. We need to
> make
> >>      sure we have enough energy around this effort in order to start
> it.
> >>
> >>      Cheers,
> >>
> >>      Gonzalo
> >>
> >>      On 15/02/2012 7:14 PM, Mary Barnes wrote:
> >>      >  I think this is a good idea.  I would think the experts that
> can
> >>      >  contribute (and should review) can be found in the new SDP
> >>      >  directorate:
> >>      >  http://www.ietf.org/iesg/directorate/sdp.html
> >>      >  BTW, it would be nice to have a link to this page on the MMUSIC
> WG
> >>      wiki:
> >>      >  http://trac.tools.ietf.org/wg/mmusic/trac/wiki
> >>      >
> >>      >  As far as whether to publish, I think it would be a good idea
> to
> >>      >  complete publication as IMHO that improves the integrity of the
> >>      >  information - i.e., more eyes review a published RFC than a
> draft.
> >>      >  It could later be updated to reflect more recent RFCs OR a
> "More of
> >>      >  Hitchhikers Guide" could be published.
> >>      >
> >>      >  Thanks,
> >>      >  Mary.
> >>      >
> >>      >  On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch
> >>      >  <Bert.Greevenbosch@huawei.com
> >>      <mailto:Bert.Greevenbosch@huawei.com>>  wrote:
> >>      >>  Hi Miguel, Andrew, all,
> >>      >>
> >>      >>  Sounds like a good idea. I would be happy to volunteer to play
> a
> >>      central role in it (i.e. be the editor, create the initial draft,
> >>      ...), but I would need support from other experts too.
> >>      >>
> >>      >>  As for practicalities, I see that the "Hitchhiker's Guide to
> SIP"
> >>      has become an RFC (5411). That means that it has been frozen, and
> to
> >>      add new info new individual or WG drafts are needed.
> >>      >>
> >>      >>  Would this be the same approach for SDP? Currently, there are
> >>      already quite some new drafts that extend SDP. How will future
> >>      extensions be handled? Maybe it would be good to make it a
> permanent
> >>      WG draft, which is updated every now and then.
> >>      >>
> >>      >>  Best regards,
> >>      >>  Bert
> >>      >>
> >>      >>
> >>      >>  -----Original Message-----
> >>      >>  From: mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org>
> >>      [mailto:mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org>]
> On
> >>      Behalf Of Miguel A. Garcia
> >>      >>  Sent: 14 February 2012 15:42
> >>      >>  To: Andrew Allen
> >>      >>  Cc: mmusic@ietf.org<mailto:mmusic@ietf.org>
> >>      >>  Subject: Re: [MMUSIC] Do we need to update in time 4566bis?
> >>      >>
> >>      >>  Sounds good to me too. If someone wants to start such draft...
> >>      >>
> >>      >>  /Miguel
> >>      >>
> >>      >>  On 13/02/2012 23:15, Andrew Allen wrote:
> >>      >>>
> >>      >>>  What about considering a hitchhikers guide to SDP similar to
> >>      what was done for SIP?
> >>      >>>
> >>      >>>  One umbrella document that points the reader to all the SDP
> >>      capabilities available that they might want to take advantage of.
> >>      >>>
> >>      >>>  Just a suggestion.
> >>      >>>
> >>      >>>  Andrew
> >>      >>>
> >>      >>>  ----- Original Message -----
> >>      >>>  From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com
> >>      <mailto:Miguel.A.Garcia@ericsson.com>]
> >>      >>>  Sent: Saturday, January 28, 2012 06:23 AM
> >>      >>>  To: mmusic<mmusic@ietf.org<mailto:mmusic@ietf.org>>
> >>      >>>  Subject: [MMUSIC] Do we need to update in time 4566bis?
> >>      >>>
> >>      >>>  <as an individual>
> >>      >>>
> >>      >>>  Hi all,
> >>      >>>
> >>      >>>  You know we are revising RFC 4566. So far, the effort has
> been
> >>      in bug fixing.
> >>      >>>
> >>      >>>  The first SDP version was published as RFC 2327 in 1998
> (i.e.,
> >>      14 years
> >>      >>>  ago), and was then revised as RFC 4566 in 2006.
> >>      >>>
> >>      >>>  Lots of things have happened since then. We have SDP offer
> answer,
> >>      >>>  Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES,
> comeida,
> >>      >>>  labels, BFCP, FEC, ICE, CapNeg, and many other that are in
> the pipe.
> >>      >>>
> >>      >>>     From the point of view of a reader who takes 4566 (or its
> current
> >>      >>>  4566bis incarnation), I think it will be difficult for her or
> him to
> >>      >>>  understand a protocol that ignores those other extensions.
> For
> >>      example, I
> >>      >>>  recently post another e-mail where there is an apparent
> >>      contradiction
> >>      >>>  between 4566 and ICE (see
> >>      >>>  http://www.ietf.org/mail-
> archive/web/mmusic/current/msg09089.html ).
> >>      >>>
> >>      >>>  So, I was wondering if time has come to make not a bug
> correction in
> >>      >>>  4566bis, but also put that RFC in context with the other
> >>      extensions that
> >>      >>>  exist. This may include:
> >>      >>>
> >>      >>>  - Add minor extensions to the core document, similarly to
> what
> >>      we did
> >>      >>>  with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know
> which
> >>      of these
> >>      >>>  extensions make sense to include, this would be an exercise
> to
> >>      do, but
> >>      >>>  let me give you one potential example: RFC 4574, the SDP
> "label"
> >>      >>>  attribute is a 6 pages RFC.
> >>      >>>
> >>      >>>  - Adding references to extensions, when it makes sense. For
> >>      example, ICE
> >>      >>>  should be referred somewhere (see my previous post regarding
> the "o"
> >>      >>>  line). I guess capneg could be also mentioned, perhaps
> others.
> >>      >>>
> >>      >>>  I know this is a bigger effort than anticipated, but the
> result
> >>      could
> >>      >>>  really help newcomers to this world.
> >>      >>>
> >>      >>>  Now, it is your turn to express your opinions. Please do it.
> >>      >>>
> >>      >>>  /Miguel
> >>      >>
> >>      >>  --
> >>      >>  Miguel A. Garcia
> >>      >>  +34-91-339-3608<tel:%2B34-91-339-3608>
> >>      >>  Ericsson Spain
> >>      >>  _______________________________________________
> >>      >>  mmusic mailing list
> >>      >>  mmusic@ietf.org<mailto:mmusic@ietf.org>
> >>      >>  https://www.ietf.org/mailman/listinfo/mmusic
> >>      >>  _______________________________________________
> >>      >>  mmusic mailing list
> >>      >>  mmusic@ietf.org<mailto:mmusic@ietf.org>
> >>      >>  https://www.ietf.org/mailman/listinfo/mmusic
> >>      >  _______________________________________________
> >>      >  mmusic mailing list
> >>      >  mmusic@ietf.org<mailto:mmusic@ietf.org>
> >>      >  https://www.ietf.org/mailman/listinfo/mmusic
> >>      >
> >>
> >>
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
> 
> --
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic