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

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Mon, 24 Jul 2006 12:13:45 +0200

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.

(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).

Regards

Keith

> -----Original Message-----
> From: Klaus Darilion [mailto:[email-masked]] 
> Sent: 21 July 2006 13:25
> To: Brian Rosen
> Cc: 'Jean-Francois Mule'; Drage, Keith (Keith); 'Livingood, 
> Jason'; 'Rohan Mahy'; 'Michael Hammer (mhammer)'; [email-masked]
> Subject: Re: [Speermint] I-D 
> ACTION:draft-ietf-speermint-requirements-00.t xt
> 
> 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
> > 
> > -----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
> 
> 

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

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 24 Jul 2006 15:00:33 +0200

> environment borders on commercial insanity for either the customer, the

When you specify G.711 as mandatory that does not imply that it must be 
used - you may also use better codecs.

The funny thing is, that if we do not specify them, there is no 
guarantee for a working interconnect. E.g. Provider A is a mobile 
operator and willing to interconnect via SIP. Provider B is a fixed line 
operator willing to interconnect via SIP. They both spend $$$ to by a 
SIP environment which supports peering according to the specifications 
made by the SPEERMINT group. And finally they can't interconnect as A 
uses AMR and B uses G.711.

regards
Klaus

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 24 Jul 2006 15:35:39 +0200

>And finally they can't interconnect as A

They can, if one provides transcoding
 
If we say G.711 is mandatory, it is provider A who has to provide the transcoding

Richard

________________________________

Von: Klaus Darilion [mailto:[email-masked]]
Gesendet: Mo 24.07.2006 15:00
An: Drage, Keith (Keith)
Cc: [email-masked]
Betreff: Re: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt

regards
Klaus

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 24 Jul 2006 17:06:28 +0200

> If we say G.711 is mandatory, it is provider A who has to provide the transcoding

Thus, we have to mandate a minimum set of codecs.

regards
klaus

---

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 24 Jul 2006 13:23:29 -0400

I tend to agree. One thing is to specify a behavior over a peering
interface that affects only the peering devices. Another is to specify a
behavior that affects possibly millions of phones (or alternatively a
requirement to install many of transcoders).

I cannot imagine Sprint changing all its phones to support G.711 or
Comcast changing all of its phones to support some wireless codec
because Speermint mandates it. 

That leaves only three alternatives:

1) Do not specify anything in the RFCs and the peers work in out whether
through some transcoding devices, or some common coder when possible.

2) Specify a minimum set (Can it be done and make everybody happy?)

3) Let offer/answer decide. I believe this might fall back into 1) since
I do not believe carriers will just "wing it" when it comes to peering. 

Regards,

Reinaldo

> Sent: Monday, July 24, 2006 8:06 AM
> To: Stastny Richard
> Cc: [email-masked]
> > If we say G.711 is mandatory, it is provider A who has to provide
the
> transcoding