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

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 28 Jun 2006 06:46:00 -0400

Let's drop the IM and video examples -- for now.  Let's first focus on
getting the basic one working that we're committed to: voice.  

So in the case of voice, the question at hand is - is there a lowest
common denominator voice codec which should be required to do peering?
If not, is there much utility in peering if certain provider types
cannot agree on a common codec?

Jason

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Tuesday, June 27, 2006 5:40 PM
> To: 'Jean-Francois Mule'; 'Drage, Keith (Keith)'; Livingood, 
> Jason; 'Rohan Mahy'; 'Michael Hammer (mhammer)'
> Cc: [email-masked]
> Subject: RE: [Speermint] I-D 
> ACTION:draft-ietf-speermint-requirements-00.t xt
> 
> Consider an all-IMS, all-GSM federation.  Do they have to have G.711?
> 
> Consider an all-video conference federation.  Do they have to 
> have G.711?
> 
> Consider an all-IM federation.  Do they have to have G.711?
> 
> 
> Brian
> 
> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]]
> Sent: Tuesday, June 27, 2006 4:30 PM
> To: Drage, Keith (Keith); Livingood, Jason; Rohan Mahy; Michael Hammer
> (mhammer)
> Cc: [email-masked]
> Subject: RE: [Speermint] I-D 
> ACTION:draft-ietf-speermint-requirements-00.t
> xt
> 
> So is this kind of scenario in scope of speermint?
> Take:
> 	- on one side, a 3GPP IMS network with the typical UE 
> that does not support G.711 on the terminal, and,
> 	- on the other, a VSP like free world dialup or alike 
> that allow any sip UA with any kind of codec.
> 
> Do we want to have some minimal requirements to ensure that 
> negotiation just does not fail?  I could care less where this 
> transcoding function is implemented.
> 
> Jean-Francois
> 
> > -----Original Message-----
> > From: Drage, Keith (Keith) [mailto:[email-masked]]
> > Sent: Tuesday, June 27, 2006 11:31 AM
> > To: Livingood, Jason; Rohan Mahy; Michael Hammer (mhammer)
> > Cc: [email-masked]
> > Subject: RE: [Speermint] I-D 
> ACTION:draft-ietf-speermint-requirements-
> > 00.t xt
> > 
> > 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
> 
> 
> 
> _______________________________________________
> 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: Wed, 28 Jun 2006 13:05:38 +0200

> cannot agree on a common codec?
The codecs are a terminal or end-user device issue. Peering between
service 
providers have no influence on these. So if there is no match in
available 
codecs, the only way out is to insert a transcoding function on one or
on both sides.

Since I am not so in protocol details, so I have a question: is there a
call
flow available to do so?

And if, the codec selected is part of the peering agreement itself.
Which 
codec is up to the parties.

Richard

---

From: "Patrick Melampy" <[email-masked]>
Date: Wed, 28 Jun 2006 10:44:10 -0400

If there are 3 carriers...A, B, and C

A may only support AMR (wireless network)
B may support AMR and G.711 (wireless interconnect network)
C may only support G.711 (terminating PSNT network)

So now we have a problem...

A-----B  (negotiates to AMR) WORKS

B-----C  (negotiates to G.711) WORKS

But A----via B-----C  FAILS [has no agreeable CODEC's]

Thus B finds that on a call by call basis, if they support A and C, they may
not be able to provide universal connectivity from A to C and vica-versa.

I don't see how this problem can be avoided when there are 3 or more
carriers interconnected. I would suggest that this problem is outside the
scope of spearmint, and just a general problem.

I don't think we should require a codec (this doesn't always make sense),
nor do I think we should require transcoding which is offensive in its own
rite. I just think this is part of the internal problem B has with the
services B wishes to offer. B may have to provide either segmented service
offerings, and or transcoding internal to its network to support A and C
peering relationships.

Said another way, I do not believe incompatible CODEC's is a service
provider peering issue, but rather a general technology issue that exists
with or without service provider borders.

-----Original Message-----
From: Livingood, Jason [mailto:[email-masked]] 
Sent: Wednesday, June 28, 2006 6:46 AM
To: Brian Rosen; Jean-Francois Mule; Drage, Keith (Keith); Rohan Mahy;
Michael Hammer (mhammer)
Cc: [email-masked]
Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t
xt

Jason

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 30 Jun 2006 09:16:14 -0700

> common denominator voice codec which should be required to do peering?

Don't know what you should do but ... pretty much every voice device  
does G.711 so the "cost" of mandating at least that is pretty low.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 30 Jun 2006 09:19:53 -0700

On Jun 30, 2006, at 9:16 AM, Cullen Jennings wrote:

> Don't know what you should do but ... pretty much every voice  
> device does G.711 so the "cost" of mandating at least that is  
> pretty low.
>

I clearly had not had enough coffee before hitting send on this  
message. Please ignore this this complete wrong statement :-) Sorry.