Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 27 Jun 2006 18:30:52 +0100

But this still does not answer my original question.

How can you mandate a codec for what is essentially a network operator when that operator does not own the terminals (which contain the vast majority of the codecs). Are you making a requirement for transcoding support in the absence of whatever codec set is defined, or is it just an empty letter?

regards

Keith

> -----Original Message-----
> From: Livingood, Jason [mailto:[email-masked]]
> Sent: 27 June 2006 16:24
> To: Rohan Mahy; Michael Hammer (mhammer)
> Cc: [email-masked]
> Subject: RE: [Speermint] I-D
> ACTION:draft-ietf-speermint-requirements-00.t xt
> 
> 
> My initial thought is that you are accurate saying that 
> federations are
> NOT REQUIRED for speermint.  Federations MAY or MAY NOT be 
> used, as you
> noted, and to that extent will be considered in some fashion here.
> 
> As for codecs, I think we'll have to see based on further WG 
> discussion.
> I would surely agree that codec negotiation / selection is *well*
> handled in the underlying SIP protocol itself.  However, we may well
> find a need to specify (or not) a lowest common denominator codec but
> we'll have to see how our requirements work progress.
> 
> Jason
> 
> > -----Original Message-----
> > From: Rohan Mahy [mailto:[email-masked]] 
> > Sent: Sunday, June 25, 2006 2:41 PM
> > To: Michael Hammer (mhammer)
> > Cc: [email-masked]
> > Subject: Re: [Speermint] I-D 
> > ACTION:draft-ietf-speermint-requirements-00.t xt
> > 
> > Mike,
> > 
> > There is no requirement for a federation to exist in 
> > speermint.  It might or it might not, but the IETF won't be 
> > very effective trying to put requirements on something which 
> > is effectively a business arrangement.  We can define a set 
> > of protocols however, which needs to be useful in the big-I 
> > Internet and hopefully for folks building federations and 
> > other clubs as well.
> > 
> > Everyone,
> > 
> > I think codec selection should be out of scope.  Mandating 
> > G.711 will have no positive effect now.  Everyone supports it 
> > today in some way or another, but it could be detrimental in 
> > the future.  The point of the SDP negotiation is to allow RTP 
> > *endpoints* to select the best codec in common under the 
> > circumstances.  I don't think we can do any better than that 
> > in a requirements document, especially since we are 
> > describing an interface between SIP intermediaries that I 
> > hope will not even be a participant in the RTP media most 
> of the time.
> > 
> > thanks,
> > -rohan
> > 
> > 
> > 
> > On 6/23/06, Michael Hammer (mhammer) <[email-masked]> wrote:
> > > Shouldn't the requirement be that the policy of a 
> federation should 
> > > address the default codecs used by a federation to interconnect?
> > >
> > > Mike
> > >
> > >
> > > > -----Original Message-----
> > > > From: Drage, Keith (Keith) [mailto:[email-masked]]
> > > > Sent: Friday, June 23, 2006 10:22 AM
> > > > To: [email-masked]
> > > > Subject: RE: [Speermint] I-D
> > > > ACTION:draft-ietf-speermint-requirements-00.t xt
> > > >
> > > > Section 3.5 indicates:
> > > >
> > > >    The minimum requirements to allow a successful VoIP 
> > interconnection
> > > >    include:
> > > >
> > > >    o  the mandatory support of RTP *and* RTCP as defined in 
> > > > [RFC3550],
> > > >
> > > >    o  the support of compatible codecs between 
> > communication peers, 
> > > > the
> > > >       G.711 MUST be supported, the IETF iLBC [RFC3951] 
> > codec and its 
> > > > RTP
> > > >       payload format [RFC3952] SHOULD be supported.
> > > >
> > > >    o  the support of the VoIP metric block as defined in 
> > RTP Control
> > > >       Protocol Extended Reports [RFC3611] MAY be supported.
> > > >
> > > > What exactly does this mean to the two bodies that are 
> making the 
> > > > peering arrangement. Is this a requirement to control 
> the codecs 
> > > > used by the UAs attached to the peering organisations equipment 
> > > > before peering can occur, or a requirement to support 
> > transcoding if 
> > > > these requirements are not met by the population of 
> attached UAs.
> > > >
> > > > Additional nit comment. RFC 2327 is obsolete and sdp-new is 
> > > > imminently about to be published and I assume we are going to 
> > > > reference that document (it will be RFC 4566).
> > > >
> > > > regards
> > > >
> > > > Keith
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked] 
> [mailto:[email-masked]]
> > > > > Sent: 21 June 2006 23:50
> > > > > To: [email-masked]
> > > > > Cc: [email-masked]
> > > > > Subject: [Speermint] I-D
> > > > > ACTION:draft-ietf-speermint-requirements-00.txt
> > > > >
> > > > >
> > > > >
> > > > > A New Internet-Draft is available from the on-line 
> > Internet-Drafts 
> > > > > directories.
> > > > > This draft is a work item of the Session PEERing for 
> Multimedia 
> > > > > INTerconnect Working Group of the IETF.
> > > > >
> > > > >     Title           : SPEERMINT Requirements for SIP-based
> > > > > VoIP Interconnection
> > > > >     Author(s)       : J. Mule
> > > > >     Filename        : draft-ietf-speermint-requirements-00.txt
> > > > >     Pages           : 10
> > > > >     Date            : 2006-6-21
> > > > >
> > > > >    This document describes general requirements for Session 
> > > > > PEERing for
> > > > >    Multimedia INTerconnect and defines the minimum set of
> > > > requirements
> > > > >    applicable to SIP session peering for VoIP interconnects.
> > > > >
> > > > >    In its current form, the document is a first draft 
> > based on the
> > > > >    SPEERMINT mailing list's discussions on 
> > requirements.  The main
> > > > >    objectives are to generate consensus on what categories of
> > > > >    requirements should be covered, and to start more 
> > discussions 
> > > > > on the
> > > > >    technical protocol requirements that apply to VoIP 
> > interconnects.
> > > > >
> > > > >
> > > > > A URL for this Internet-Draft is:
> > > > > http://www.ietf.org/internet-drafts/draft-ietf-speermint-requi
> > > > rements-00.txt
> > > >
> > > > To remove yourself from the I-D Announcement list, send a 
> > message to 
> > > > [email-masked] with the word unsubscribe 
> > in the body 
> > > > of the message.
> > > > You can also visit 
> > > > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > > to change your subscription settings.
> > > >
> > > >
> > > > Internet-Drafts are also available by anonymous FTP. 
> > Login with the 
> > > > username "anonymous" and a password of your e-mail 
> address. After 
> > > > logging in, type "cd internet-drafts" and then
> > > >       "get draft-ietf-speermint-requirements-00.txt".
> > > >
> > > > A list of Internet-Drafts directories can be found in 
> > > > http://www.ietf.org/shadow.html or 
> > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >
> > > >
> > > > Internet-Drafts can also be obtained by e-mail.
> > > >
> > > > Send a message to:
> > > >       [email-masked].
> > > > In the body type:
> > > >       "FILE
> > > > /internet-drafts/draft-ietf-speermint-requirements-00.txt".
> > > >
> > > > NOTE: The mail server at ietf.org can return the document in
> > > >       MIME-encoded form by using the "mpack" utility.  
> To use this
> > > >       feature, insert the command "ENCODING mime" before 
> > the "FILE"
> > > >       command.  To decode the response(s), you will need 
> > "munpack" or
> > > >       a MIME-compliant mail reader.  Different 
> > MIME-compliant mail 
> > > > readers
> > > >       exhibit different behavior, especially when dealing with
> > > >       "multipart" MIME messages (i.e. documents which 
> > have been split
> > > >       up into multiple messages), so check your local 
> > documentation on
> > > >       how to manipulate these messages.
> > > >
> > > >
> > > > Below is the data which will enable a MIME compliant 
> mail reader 
> > > > implementation to automatically retrieve the ASCII 
> version of the 
> > > > Internet-Draft.
> > > >
> > > > _______________________________________________
> > > > Speermint mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/speermint
> > > >
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > >
> > 
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> > 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 27 Jun 2006 13:41:31 -0400

Hello,

When I posted my comments I also thought that this part was weird. Maybe
Francois had something else in mind. I see codecs coming into play in a
media relay/transcoding scenario. 

But even then, a media relay (or a pair of them) would negotiate the
necessary codecs as transparently as possible. 

And in the case of SUBSCRIBE/NOTIFY policies and media relays, the
preferred codecs would be known in advance if transcoding was needed. 

But I'm open to hear scenarios where mandating a codec would be
necessary.

Regards,

REinaldo

> Sent: Tuesday, June 27, 2006 10:31 AM
> To: Livingood, Jason; Rohan Mahy; Michael Hammer (mhammer)
> Cc: [email-masked]
ACTION:draft-ietf-speermint-requirements-00.t
> xt
> How can you mandate a codec for what is essentially a network operator
> when that operator does not own the terminals (which contain the vast
> majority of the codecs). Are you making a requirement for transcoding
> support in the absence of whatever codec set is defined, or is it just
an
> empty letter?