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

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 7 Jul 2006 10:55:20 -0400

> About 1 second after I hit the send button on my original 
> message, I realized what a stupid thing I was saying. 
> Completely agree with Keith.
> 
> 
> On Jul 2, 2006, at 1:23 AM, Drage, Keith (Keith) wrote:
> 
> > Oh no they do not - starting with just about every mobile phone you 
> > pick up.
> >
> > and therein lies your problem. Use of G.711 over the air 
> interface has 
> > sufficient cost to either preclude or prevent its use.

So, in the mobile space, what is the lowest common denominator codec?
(Perhaps we can arrive at a couple of options and figure things out from
there.)

Jason

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

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 7 Jul 2006 22:40:44 +0100

If you go here, you will find the 3GPP specification for codec usage in IMS.

http://www.3gpp.org/ftp/Specs/html-info/26235.htm

Suggest use the latest version of the latest release unless you have reasons otherwise.

Any of the other 3GPP references from within this document can be found by starting at 

http://www.3gpp.org/ftp/Specs/html-info/status-report.htm

but you should get the information you need from clause 6.1 of the main document.

Afraid I am not close enough to 3GPP2 to give you their references until I catch up with some of my colleagues next week.

regards

Keith

> -----Original Message-----
> From: Livingood, Jason [mailto:[email-masked]]
> Sent: 07 July 2006 15:55
> To: Cullen Jennings; Drage, Keith (Keith)
> Cc: [email-masked]
> Subject: RE: [Speermint] I-D
> ACTION:draft-ietf-speermint-requirements-00.t xt
> 
>

---

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Sat, 8 Jul 2006 10:42:08 -0500

My suggestion is Enhanced Variable Rate Codec (EVRC).

-----Original Message-----
From: Livingood, Jason [mailto:[email-masked]] 
Sent: Friday, July 07, 2006 9:55 AM
To: Cullen Jennings; Drage, Keith (Keith)
Cc: [email-masked]
Subject: RE: [Speermint] I-D
...

Jason

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 21 Jul 2006 14:25:18 +0200

Brian Rosen wrote:
> 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?

IMO we should specify G711 as mandatory codec for voice peering. Thus, 
the all-IM and all-video federations are still standard conform.

Regarding IMS: Is really everything in IMS/3GPP 100%IETF compatible? Any 
federation can overrule the standard.

For example the federation "high secure" can have a policy: Peering 
according to SPEERMINT RFCxxxx+RFCxxx witht he exception that it 
requires signaling over TLS+IPSEC over private Layer2 network.

The "low-bandwidth" federation specifies speermint RFCxxxx + G.729. 
Every service provider can choose to participate in this federation or not.

Thus, if the IMS federation mandates SPEERMINT RFCxxxx with the 
exception of AMR instead of G.711 IMO this is fine. But if any of the 
IMS providers want to peer with the "low-bandwidth" federation it has to 
support G.711 and G.729 as well.

I'm sure there will be also federation which do not use the SPEERMINT 
documents at all.

regards
klaus

> Brian
> 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
> 
>> 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
>>
>>> Sent: 27 June 2006 16:24
>>> To: Rohan Mahy; Michael Hammer (mhammer)
>>> Cc: [email-masked]
>>> 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
>>>
>>>> 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,
>>>> 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
>>>>>
>>>>>
>>>>>> From: Drage, Keith (Keith) [mailto:[email-masked]]
>>>>>> Sent: Friday, June 23, 2006 10:22 AM
>>>>>> To: [email-masked]
>>>>>> 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
>>>>>>
>>>>>>> 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.
>>>>>>

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 24 Jul 2006 07:47:41 -0600

Keith, 

   See inline. 

Jean-Francois.

You wrote:
> Sent: Monday, July 24, 2006 4:14 AM
> To: Klaus Darilion
> Cc: [email-masked]
> The issue here is not whether IMS wants to do their own thing.
> 
> The issue is that putting G.711 over any radio interface in a cellular
> environment borders on commercial insanity for either the customer,
> the
> operator, or both.
> 
> Therefore you should not be specifying G.711 as the default unless you
> are also going to specify that transcoding (in the intervening sustem)
> must take place to G.711 when the terminal does not support or use
> such
> a codec, AND that some form of transcoder free operation should also
           ^^^^^^^^^^^^^^^^^^^^^ !!!!!!!!!!!!!!! ^^^^^^^^^ !!!!!! ^^^^
> be
> supported across the peering interface.

This is where you loose me.
Are you suggesting putting a requirement (albeit at a should level) on
transcoder free operation for all VoIP networks, yet not specify one or
more *common* codecs? 
If so, are you suggesting to recommend transcoder free operations
without specifying any common denominator between L5 peers (user groups,
VSP, enterprises)?

> (Side note: I suspect if one started totally figures for the number of
> end systems that support G.711, and those that support AMR, you might
> well be surprised at the result).

Side side note: I think we should define "end systems" as in *IP* end
systems (with RTP data pumps bolted to the codec DSP) in this speermint
context. Does the result survive?

> Regards

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Tue, 25 Jul 2006 11:07:52 +0200

The architecture you describe is a B2BUA with media. While you may try
and design this as transparently as possible, it still exists from the
start of the dialog, unless you REFER it in, and is end to middlebox,
middlebox to end. A SIP proxy cannot suddenly decide mid dialog to
become a B2BUA.

The SIP/SIPPING working groups do have a number of RFCs and drafts
relating to transcoding, and how they are provided.

Regards

Keith 

> From: Patrick Melampy [mailto:[email-masked]] 
> Sent: 24 July 2006 19:08
> To: Drage, Keith (Keith); 'Jean-Francois Mule'; 'Klaus Darilion'
> Cc: [email-masked]
> It is possible to "modify" the offer to permit otherwise 
> impossible communication. So a middle box of some kind, could 
> insert an additional capability into an offer. It is of 
> course the hope that this additional capability will not be 
> selected. If it is, then the network element that inserted 
> the capability, must provide the transcoding capability on 
> the fly transparently.
> 
> The signaling (offer/answer) is still end-to-end. But 
> midpoints can modify the offer if so desired to enable the 
> communication to occur.
> 
> This is by far preferred over other techniques that would 
> "normalize" all RTP to a single common form (G.711).
> 
> Sent: Monday, July 24, 2006 10:28 AM
> To: Jean-Francois Mule; Klaus Darilion
> Cc: [email-masked]
> Inline as well.
> > Sent: 24 July 2006 14:48
> > To: Drage, Keith (Keith); Klaus Darilion
> > Cc: [email-masked]
> > > the operator, or both.
> > > such a codec, AND that some form of transcoder free
> > operation should
> > > also
> > Are you suggesting putting a requirement (albeit at a should
> > level) on transcoder free operation for all VoIP networks, yet not 
> > specify one or more *common* codecs?
> > without specifying any common denominator between
> > L5 peers (user groups, VSP, enterprises)?
> > 
> As soon as you put a transcoder in the path, then the 
> offer/answer no longer works end-to-end. End-to-end offer 
> answer will ensure that if the UAC and the UAS support a 
> common codec they will use it. With the transcoder in the 
> way, we do not want to end up with something that goes from 
> codec A to codec B (as the default, or some other codec) back 
> to codec A. Therefore I believe if you allow transcoding, you 
> also have to require that we prevent such scenarios.
> 
> <snipped>
> 
> > > Regards
> > > 
> > > Keith
> > 
> > 
>

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Tue, 25 Jul 2006 19:28:26 +0200

Published or WG work in progress

http://www.ietf.org/rfc/rfc4117.txt
http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-framework-
04.txt
http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-conf-03.tx
t

Author draft not yet discussed as follows:

http://www.ietf.org/internet-drafts/draft-kang-sipping-transc-scenario-0
1.txt 

Regards

Keith 

> Sent: 25 July 2006 14:40
> To: Drage, Keith (Keith)
> Can you email the list some of the pertinent RFCs or I-Ds 
> related to transcoding?  That way folks can read them and get 
> familiar with them.
> 
> Thx
> Jason 
> 
> > Sent: Tuesday, July 25, 2006 5:08 AM
> > To: Patrick Melampy; Jean-Francois Mule; Klaus Darilion
> > Cc: [email-masked]
> impossible 
> > > communication. So a middle box of some kind, could insert an 
> > > additional capability into an offer. It is of course the 
> hope that 
> > > this additional capability will not be selected. If it 
> is, then the 
> > > network element that inserted the capability, must provide the 
> > > transcoding capability on the fly transparently.
> > > 
> midpoints can 
> > > modify the offer if so desired to enable the 
> communication to occur.
> > > 
> > offer/answer no
> > > longer works end-to-end. End-to-end offer answer will
> > ensure that if
> > > the UAC and the UAS support a common codec they will use
> > it. With the
> > > transcoder in the way, we do not want to end up with 
> something that 
> > > goes from codec A to codec B (as the default, or some 
> other codec) 
> > > back to codec A. Therefore I believe if you allow 
> transcoding, you