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

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Mon, 24 Jul 2006 16:28:03 +0200

Inline as well.

Keith 

> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]] 
> Sent: 24 July 2006 14:48
> To: Drage, Keith (Keith); Klaus Darilion
> Cc: [email-masked]
> Subject: RE: [Speermint] I-D 
> ACTION:draft-ietf-speermint-requirements-00.t xt
> 
> Keith, 
> 
>    See inline. 
> 
> Jean-Francois.
> 
> You wrote:
> > -----Original Message-----
> > From: Drage, Keith (Keith) [mailto:[email-masked]]
> > Sent: Monday, July 24, 2006 4:14 AM
> > To: Klaus Darilion
> > Cc: [email-masked]
> > Subject: RE: [Speermint] I-D 
> ACTION:draft-ietf-speermint-requirements-
> > 00.t xt
> > 
> > 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)?
> 
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

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

---

From: "Patrick Melampy" <[email-masked]>
Date: Mon, 24 Jul 2006 14:07:39 -0400

Keith,

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

-----Original Message-----
From: Drage, Keith (Keith) [mailto:[email-masked]] 
Sent: Monday, July 24, 2006 10:28 AM
To: Jean-Francois Mule; Klaus Darilion
Cc: [email-masked]
Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t
xt

Inline as well.

Keith 

<snipped>

---

From: "Klaus Darilion" <[email-masked]>
Date: Mon, 24 Jul 2006 22:19:09 +0200 (CEST)

> inserted the capability, must provide the transcoding capability on the

Yes, this is possible, but with the drawback, that either:
- you have to enforce that the media is sent to an RTP proxy (and performs
transcoding if necessary) as the SDP in the offer contains the socket
where to send the RTP stream
- or you have to generate re-INVITEs to change the media sockets to the
transcoder when transcoding is needed (requires a B2BUA).

This is complicated.

> RTP to a single common form (G.711).

The normalization is only needed if the terminals do not support G.711. If
the terminal is a SIP phone, usually G.711 is supported. If the terminal
is a PSTN phone, usualy G.711 is used. If the terminal is a mobile phone
(usually GSM or AMR), and it want's to peer with non mobile providers, it
either:
- ensures that the other peer supports AMR/GSM too
- or it transcodes. Every mobile operator has transcoders for PSTN
interconnect.

regards
klaus