Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt

[Gunnar Hellström <[e-mail]>]

We do not need to go to circuit switched mobile networks to find needs 
to use other codecs than G.711 in endpoints.

There are plenty of other situations when a service provider want to 
keep the endpoints simple, and can accept the responsibility to do any 
transcoding needed in the network. As a more simple example, in line 
with the original intentions of Phonebcp, I can imagine that there are 
VoIP providers who want to have the endpoints use only iLBC and 
introduce transcoding to whatever is available in the PSAP interface in 
their networks.

Many comments have indicated that transcoding in the network is to be 
expected. The draft should reflect this view.

The same reasoning applies to the other media: real-time text, text 
messaging and video.

Many points in the draft has already shared responsibility between 
various nodes declared. There are many ED-x/INT-y or ED-z/SP-q 
requirements indicating that responsibility to behave as the PSAP 
interface requires can be placed either in the end device or the network.

Chapter 5 about identifying emergency calls is a good example of shared 
responsibility between ED and SP.

Something similar should be done for chapter 14.

After reading the draft, I am not sure if the SP-x requirements are 
administrative responsibilities on the service provider, or real actions 
anywhere in the service provider network.
Assuming that SP-x requirements are suitable for this case, I want to 
propose the following slightly modified text for Chapter 14 to allow 
transcoding,  and also that guaranteed support of other codecs can be 
decided later:

--------------------------------------------------------------------------------------------
14. Media

The service provider MUST make sure that the media types supported by 
both the PSAPs and the endpoints are negotiated, coded and transported 
according to commonly supported specifications. Alignment with what 
PSAPs support may be done directly in the endpoint or in the service 
providers network.
This chapter provides the minimum set of media types and codecs that 
PSAPs are guaranteed to handle. Extensions are possible by local, 
regional or global agreements.

ED-71/SP-41 Media streams MUST be sent and received on RTP [RFC3550].

ED-72/SP-42 Normal SIP offer/answer [RFC3264] negotiations MUST be used 
to agree on the media streams to be used.

ED-73/SP-43 For endpoints supporting voice, G.722 or G.711 A law (and mu 
Law if they are intended be used in North America) encoded voice as 
described in [RFC3551] MUST be supported either directly by the endpoint 
or through conversion by the service provider. It is desirable to 
include other wideband codecs such as AMR-WB in the offer.

ED-74/SP-44 Silence suppression (Voice Activity Detection methods) MUST 
NOT be used on emergency calls. PSAP call takers sometimes get 
information on what is happening in the background to determine how to 
process the call.

ED-75/SP-45 For endpoints supporting Instant Messaging (IM) either 
[RFC3428] or [RFC4975] MUST be supported directly by the endpoint or 
through conversion by the service provider.

ED-76/SP-46 For endpoints supporting real-time text, [RFC4103] MUST be 
supported either directly by the endpoint or through conversion by the 
service provider. The expectations for emergency service support for the 
real-time text medium are described in [RFC5194], Section 7.1.

ED-77/SP-47 For endpoints supporting video, H.264 per 
[I-D.ietf-avt-rtp-rfc3984bis] MUST be supported either directly by the 
endpoint or through conversion by the service provider.


------------------------------------------------------------------------------------------

/Gunnar


Dawson, Martin skrev 2011-03-08 04:34:
> I agree with this.
>
> I'll go out on a limb and confess I don't understand why the point of (circuit service) mobile codecs came up anyway. These are air interface codecs and they will have been transcoded by the time the traffic hits the circuits in the core network anyway. I'm struggling to see why they are pertinent to the spec at all.
>
> Cheers,
> Martin
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of James M. Polk
> Sent: Sunday, 6 March 2011 5:38 PM
> To: Henning Schulzrinne; Brian Rosen
> Cc: DRAGE, Keith (Keith); 'ecrit Org'
> Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt
>
> I agree with Henning here. We really cannot really control or
> reliably expect that within the existing SW upgradeable
> "interworking" products that we can mandate a codec.
>
> That said, Gunnar is also right, this shouldn't be only an "ED" requirement.
>
> Along those lines, I think this requirement, while well intentioned,
> falls into the gap between IP and circuit, in which we can't
> truthfully say that we "know" this only applies to the IP part - at
> least not without rewording to limit this.
>
> Something needs to state definitively that when the media gets to the
> ESRP - via mobile or wired - it needs to be in either the G.711 or
> G.722 codec for interoperability sake. That means the cellco mobile
> devices can use whatever codec they want, as long as the cellco
> converts to 711 or 722 once the media is transcoded to RTP.
>
> I'm not sure we have a requirement that say exactly that, and I think
> we should for this situation.
>
> James
>
> At 10:48 AM 3/5/2011, Henning Schulzrinne wrote:
>> There's nothing we can do about this problem, particularly given
>> that there doesn't appear to be a universal codec for mobile
>> devices. Also, I suspect that all mobile calls *today* show up as
>> G.711 by the time they reach the ESInet, since they go through a
>> circuit-to-packet conversion. Once we have VoIP-over-LTE, it might
>> be appropriate to add the most common wideband codec for that
>> configuration to the SHOULD list. There doesn't seem to be as much
>> point in adding narrowband codecs, since the conversion to G.711 is
>> cheap and no quality would be lost in translation.
>>
>> Henning
>>
>> On Mar 5, 2011, at 10:24 AM, Brian Rosen wrote:
>>
>>> Nope, no downside.  I can do that.
>>>
>>> Doesn't handle the problem that started this: mobile phones don't
>> do G.711 or G.722
>>
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit