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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 23 Jun 2006 17:23:38 -0400

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

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 24 Jun 2006 00:34:40 +0200

>o  Should the minimum set of requirements for VoIP interconnect
>      include any media-related requirements at all?

 >  o  The speerming charter defines "VoIP" as in voice calls.  Does
 >     voice communication mean audio only or more? audio, DTMF tones,
  >    real-time fax, voiceband data?

IMHO not: Speermint is dealing with the interworking between proxies
media is basically an interworling between endpoints
 
In addition, as said in the second bullet, why just defining the audio-codecs?

regards
-sta

---

From: "Rohan Mahy" <[email-masked]>
Date: Sun, 25 Jun 2006 11:41:18 -0700

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

---

From: "Uzelac, Adam" <[email-masked]>
Date: Mon, 26 Jun 2006 15:07:39 -0400

I don't see why a Federation is deemed exclusively a business
arrangement.  A Federation should be an optional parameter in the
protocol set that facilitates SIP peering.  IMO, the main driver is
scale. Achieving scale without some hierarchical tools and therefore
summation options makes for problematic reachability propagation.
Thinking of DNS -  Hierarchy in the domain names is NOT the reason for
DNS scalability - the namespace is essentially flat in practice.
Federations presents an another option to the direct P2P model.  The
attempt is not to ingrain an archaic business model that forces
transitory providers into the P2P world.  Federations can help with
reachability awareness through a further segregation of the data-set.
If every single endpoint is the data-set, and we aspire to have everyone
be able to directly communicate with everyone else (think pure P2P),
then WHOA, what a database I would have to connect-to in the sky -OR-
WHOA, what a database of reachabiliy I would have resident on my local
proxy!  

Adam Uzelac

-----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

Mike,

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:
> >    o  the support of compatible codecs between communication peers, 
> > the
> >       G.711 MUST be supported, the IETF iLBC [RFC3951] codec and its

> > RTP
> > 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.
> >

> > >    This document describes general requirements for Session 
> > > PEERing for
> > >    requirements should be covered, and to start more discussions 
> > > on the
> > 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
> > 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
> >       a MIME-compliant mail reader.  Different MIME-compliant mail 
> > readers