Subject: RE: [Ecrit] Audio Codecs for 911 CALLS.

From: "Brian Rosen" <[email-masked]>
Date: Tue, 8 Aug 2006 11:34:37 -0400

I think that PSAPs have to handle both uLaw and aLaw, although most
endpoints do both.

I don't think you can FORCE a PSAP to support every wireless carrier's
chosen codec.  If there were a small list, that might be practical, but, as
I understand it, such a short list does not exist for U.S., although it's
easier in areas where only GSM or only CDMA is supported. Even in those
areas, the codec list is, I think 3 at least, and going to 4, if you cover
all the existing handsets as well as the next gen (I'm including the
wideband).  In the U.S. it would be around 10 I think.

I don't agree that it's easy to support a large number of codecs.  The
problem is that it IS specialized kit, and the costs of supporting most
codecs are dominated by the up front and minimum royalty payments, and not
the per endpoint charges when you don't make millions of endpoints.  You are
also forcing, I think, the UAs to be custom, and not off the shelf UAs
unless you transcode at the PSAP, which is just as bad as transcoding
earlier in the process.  While I think it's a good idea to handle a wide
range of codecs, I don't think we can require that.

I think the interactive text codec is a MUST.  I think IM, at least at the
moment, is not MUST.  Video, I expect, may end up being a national matter,
but at the moment, in the IETF, I'd think it was not a MUST.  

I'm rethinking my position on compression due to Barbara's comments.  I
really wonder if you can say 729 only (with or without iLBC), and not
support g.723

Brian

________________________________________
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 08, 2006 10:34 AM
To: Brian Rosen
Cc: 'Andrew Newton'; [email-masked]; 'James M. Polk'; 'Karihaloo, Ujjval'
Subject: RE: [Ecrit] Audio Codecs for 911 CALLS.

Hi, 

I certainly agree with below, G.711 is a MUST for both ends -- it is the
common denominator supported by virtually everything in one way or another
(one of those possible ways being via transcoding).  To avoid regional
issues, I guess it is really MUST 711 u-law and a-law on both ends;
otherwise we wind up making it based on location or some darned thing.
 Alternatively, we might think about making u-law and a-law MUST on the PSAP
side only -- premise being if an endpoint does not support both, its calls
using the wrong one for the region will sound like junk ... except for
emergency calls.   

On the PSAP end, the MUST list must be longer, to also include any codecs
native to wireless domains the PSAP serves, and real time text (to avoid
Gunnar's wrath ;-).  I do not think it is onerous at all to make the PSAP
end support a long list -- the PSAP end is likely to be an expensive /
sophisticated piece of kit anyway, and very small in number compared to the
zillions able to make calls towards the PSAP.  On compressed codecs, I
believe they SHOULD be supported (BUT NOT PREFERRED) on PSAP end, as a last
resort to avoid failed calls for misbehaved endpoints that do not agree on
711 or others in the MUST list.  I believe everything else, such as wb
audio, iLBC, video, IM, etc, becomes SHOULD on the PSAP end.  Perhaps over
time, as it becomes more clear what proportion of endpoints will support the
others, the PSAP MUST list should be extended.   

BTW, Somewhere waaaay down this thread someone said "it's in the BCP".  I
don't think it actually is.  I assume it will be added?   

-- Peter 

"Brian Rosen" <[email-masked]> 
07.08.06 20:20 
        
        To:        "'James M. Polk'" <[email-masked]>, "'Andrew Newton'"
<[email-masked]> 
        cc:        "'Karihaloo, Ujjval'" <[email-masked]>,
[email-masked] 
        Subject:        RE: [Ecrit] Audio Codecs for 911 CALLS.

I believe that the minimum codec is G.711.  Every PSAP will support it,
every call must be able to support it.

I think we will recommend that every PSAP support the codecs applicable to
the wireless networks that are in their service boundaries, as well as
wideband codecs that may be supported in their service area, so that
transcoding is not required.  From the emergency service vantage point, the
lack of standardization in this area (and I do mean "the wonderful thing
about standards is there are so many to choose from") is glaringly,
painfully stupid.

It is unwise to support the compressed codecs (G.723, G.729, ...).  Some of
the adaptable codecs might be supported in their better-than-toll-quality
modes.

We might want to recommend support for straight linear 16 bit audio, so that
transcoding can be minimal loss, although since no transcoders can do this
now, that might be a futile gesture.

Every PSAP will support the text codec, of course, and I hope, one or two IM
streams.  Every PSAP will probably (maybe eventually) support H.264, and
some will support H.263.

But in the end, I think these have to be recommendations (SHOULD) and thus
the MUST, for everyone, is G.711.

AND NO VOICE ACTIVITY DETECTION.

And I don't think this is SPEERMINT territory, even if the subject matter
overlaps some.  Peering is not assumed to be able to place an emergency
call.

Brian

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]]
> Sent: Monday, August 07, 2006 6:48 PM
> To: Andrew Newton
> Cc: [email-masked]; Karihaloo, Ujjval
> Subject: Re: [Ecrit] Audio Codecs for 911 CALLS.
> 
> At 06:44 PM 8/7/2006 -0400, Andrew Newton wrote:
> 
> >On Aug 7, 2006, at 6:22 PM, James M. Polk wrote:
> >
> >>At 05:45 PM 8/7/2006 -0400, Andrew Newton wrote:
> >>>
> >>>G.711 is likely not a very good choice for wireless environments.
> >>
> >>
> >>does this mean that my wired IP-phone, like the majority of all others,
> >>will not have any chance at communicating with anyone else's IP
> >>cellphone?  I think the reverse will have the same problem...
> >
> >That's my non-expert understanding.  Fortunately, we aren't concerned
> with
> >getting a call through between any two UAs: we are concerned about
> getting
> >a call through from any UA to a PSAP.
> 
> err, what do you think will be answering the call in the PSAP?
> 
> (hint: it'll be a UA)
> 
> 
> >-andy
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit

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

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

---

From: [email-masked]
Date: Tue, 8 Aug 2006 10:33:40 -0400

Hi, 

I certainly agree with below, G.711 is a MUST for both ends -- it is the 
common denominator supported by virtually everything in one way or another 
(one of those possible ways being via transcoding).  To avoid regional 
issues, I guess it is really MUST 711 u-law and a-law on both ends; 
otherwise we wind up making it based on location or some darned thing. 
Alternatively, we might think about making u-law and a-law MUST on the 
PSAP side only -- premise being if an endpoint does not support both, its 
calls using the wrong one for the region will sound like junk ... except 
for emergency calls. 

On the PSAP end, the MUST list must be longer, to also include any codecs 
native to wireless domains the PSAP serves, and real time text (to avoid 
Gunnar's wrath ;-).  I do not think it is onerous at all to make the PSAP 
end support a long list -- the PSAP end is likely to be an expensive / 
sophisticated piece of kit anyway, and very small in number compared to 
the zillions able to make calls towards the PSAP.  On compressed codecs, I 
believe they SHOULD be supported (BUT NOT PREFERRED) on PSAP end, as a 
last resort to avoid failed calls for misbehaved endpoints that do not 
agree on 711 or others in the MUST list.  I believe everything else, such 
as wb audio, iLBC, video, IM, etc, becomes SHOULD on the PSAP end. Perhaps 
over time, as it becomes more clear what proportion of endpoints will 
support the others, the PSAP MUST list should be extended. 

-- Peter

        To:     "'James M. Polk'" <[email-masked]>, "'Andrew Newton'" <[email-masked]>
        cc:     "'Karihaloo, Ujjval'" <[email-masked]>, [email-masked]
        Subject:        RE: [Ecrit] Audio Codecs for 911 CALLS.

transcoding is not required.  From the emergency service vantage point, 
the

It is unwise to support the compressed codecs (G.723, G.729, ...).  Some 
of
the adaptable codecs might be supported in their better-than-toll-quality
modes.

We might want to recommend support for straight linear 16 bit audio, so 
that
transcoding can be minimal loss, although since no transcoders can do this
now, that might be a futile gesture.

Every PSAP will support the text codec, of course, and I hope, one or two 
IM
streams.  Every PSAP will probably (maybe eventually) support H.264, and
some will support H.263.

Brian

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 08 Aug 2006 12:31:49 -0500

At 11:34 AM 8/8/2006 -0400, Brian Rosen wrote:
>I'm rethinking my position on compression due to Barbara's comments.

I am too

>I really wonder if you can say 729 only (with or without iLBC), and not
>support g.723

g723 is way small, has at least 2 sending rates, and has an inconvenient 
royalty payment.  Weren't these the reasons iLBC was created?

It'll be g711 and iLBC in CableLabs/PacketCable, and I'm not sure it 
they've chosen to support any other audio codecs.