Re: Hitchhiker's guide to SDP

> 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 packa=
ges"
5) ITU-T H.248.80: "Usage of the revised SDP offer / answer model with H.24=
8" (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: [email protected] [mailto:[email protected]] On Behalf Of=
 DRAGE, Keith (Keith)
Sent: Mittwoch, 7. M=E4rz 2012 15:25
To: Miguel A. Garcia; Bert Greevenbosch
Cc: [email protected]
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 d=
ifferent 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: [email protected] [mailto:[email protected]] On Behalf
> Of Miguel A. Garcia
> Sent: 07 March 2012 10:56
> To: Bert Greevenbosch
> Cc: [email protected]
> 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: [email protected] [mailto:[email protected]] On Behalf
> Of Christer Holmberg
> > Sent: 27 February 2012 04:53
> > To: Gonzalo Camarillo; Mary Barnes
> > Cc: [email protected]
> > 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: [email protected] [mailto:[email protected]] On Behalf
> Of Gonzalo Camarillo
> > Sent: 23. helmikuuta 2012 19:31
> > To: Mary Barnes
> > Cc: [email protected]
> > 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
> >> <[email protected]
> >> <mailto:[email protected]>>
> >> 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
> >>      >  <[email protected]
> >>      <mailto:[email protected]>>  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: [email protected]<mailto:[email protected]>
> >>      [mailto:[email protected]<mailto:[email protected]>]
> On
> >>      Behalf Of Miguel A. Garcia
> >>      >>  Sent: 14 February 2012 15:42
> >>      >>  To: Andrew Allen
> >>      >>  Cc: [email protected]<mailto:[email protected]>
> >>      >>  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:[email protected]
> >>      <mailto:[email protected]>]
> >>      >>>  Sent: Saturday, January 28, 2012 06:23 AM
> >>      >>>  To: mmusic<[email protected]<mailto:[email protected]>>
> >>      >>>  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 =3D 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
> >>      >>  [email protected]<mailto:[email protected]>
> >>      >>  https://www.ietf.org/mailman/listinfo/mmusic
> >>      >>  _______________________________________________
> >>      >>  mmusic mailing list
> >>      >>  [email protected]<mailto:[email protected]>
> >>      >>  https://www.ietf.org/mailman/listinfo/mmusic
> >>      >  _______________________________________________
> >>      >  mmusic mailing list
> >>      >  [email protected]<mailto:[email protected]>
> >>      >  https://www.ietf.org/mailman/listinfo/mmusic
> >>      >
> >>
> >>
> >
> > _______________________________________________
> > mmusic mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/mmusic
> > _______________________________________________
> > mmusic mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/mmusic
> > _______________________________________________
> > mmusic mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
> =

> --
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
> _______________________________________________
> mmusic mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic