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

From: "Karihaloo, Ujjval" <[email-masked]>
Date: Mon, 7 Aug 2006 12:44:51 -0600

Thanks Hannes.
I will review and provide my views 
Thx,
Ujjval.

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Monday, August 07, 2006 12:28 PM
To: Karihaloo, Ujjval
Cc: [email-masked]
Subject: Re: [Ecrit] Audio Codecs for 911 CALLS.

Hi Ujjval,

our Phone BCP draft should give some guidance on the codecs to use for 
emergency calls. However, to some extend this is also a SPEERMINT issue.

The Phone BCP draft can be found here:
http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-phonebcp-01.txt

Feedback for the draft is appreciated.

Ciao
Hannes

Karihaloo, Ujjval wrote:
> Hi All,
> 
>  
> 
>   Is there any draft/RFC around which Codec (G711, G729 etc) to use
for 
> a 911 Call?
> Thx,
> Ujjval.
------------------------------------------------------------------------
> 
> _______________________________________________
> 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: "Stark, Barbara" <[email-masked]>
Date: Tue, 8 Aug 2006 08:23:15 -0500

I agree that all endpoints intended to work over a broadband connection
must support G.711 PCMU and PCMA. I can't speak for cell phones. In the
US we tend to prefer PCMU, and I think Asia prefers PCMA. I'm assuming
that the BCP won't prefer one of these over the other, and that regional
preferences can dictate the default 711 in an endpoint. Please let's not
suggest that the phone use its location to determine the preferred 711. 

But I think there may be times when there isn't enough bandwidth for
711. I think the phones must support at least one compressed codec. That
can be one or both of iLBC or 729a.

We have some customers whose link only supports 128kbps (raw data rate)
in the upstream. Adding in overhead for ATM, PPPoE, and IP headers, 711
doesn't work over this. While we don't offer VoIP to these customers,
that doesn't mean they can't or don't get it from someone else.

While I agree that uncompressed is generally preferred, if it's a choice
between the call losing lots of packets or failing vs. using a
compressed codec, I prefer compressing. With compressed voice, the PSAP
can still pick up more ambient noise than with a text message. 

I'd expect PSAPs to be able to support 711 PCMU, PCMA, iLBC, 729a. And
they should support 722 for wideband. They can support others if they
want. Again, I don't know where the cellphone people are heading. I
would prefer for the PSAPs to natively support whatever the cell phones
use, rather than have the SBCs do transcoding between codecs.

I agree with the text and video codecs and not enabling VAD.
Barbara

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Monday, August 07, 2006 8:20 PM
> To: 'James M. Polk'; 'Andrew Newton'
> Cc: 'Karihaloo, Ujjval'; [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
> 
> > From: James M. Polk [mailto:[email-masked]]
> > Sent: Monday, August 07, 2006 6:48 PM
> > To: Andrew Newton
> > Cc: [email-masked]; Karihaloo, Ujjval
> > 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
> > 

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. AL621

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 8 Aug 2006 10:02:42 -0400

James,

Gee, I'm so glad you decided to pick up this tarball and run with it. :)

Maybe we could take the lengthy discussion in Speermint and re-label all
those messages and save everyone the time to re-post those arguments.

Anyway, if you can discover a reasonable set of codecs that all domains
(including PSAP domains) should support, many groups will thank you.

Cheers,
Mike

> From: James Polk (jmpolk) 
> Sent: Monday, August 07, 2006 8:52 PM
> To: Brian Rosen; 'Andrew Newton'
> I agree completely.
> And I have a comment about SPEERMINT: though peering 
> shouldn't have anything to do with endpoint codec support, 
> peering in SIP will likely involve an SBC, which, by 
> definition is a B2BUA - meaning it can change the SDP, 
> meaning it can change the codecs to whatever it wants.
> 
> That said, we don't want peering (meaning SPEERMINT) to *NOT* 
> have a requirement from this WG to support our minimal 
> specifications in ECRIT to establish SIP calls as if the 
> peering point wasn't there.
> 
> We/someone needs to make that WG aware of this situation - 
> and have them incorporate, if appropriate, whatever we 
> reasonably require of a peering specification from them.
> 
> At 08:20 PM 8/7/2006 -0400, Brian Rosen wrote:
> 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 
> 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.
> >
> hope, one or 
> >two IM streams.  Every PSAP will probably (maybe eventually) support 
> >H.264, and some will support H.263.
> >
> (SHOULD) and 
> >thus the MUST, for everyone, is G.711.
> >
> >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
> >
> > > >>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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 08 Aug 2006 13:06:55 -0500

This WG is not discussing migration issues involving the PSTN, it is 
chartered with IP-to-IP emergency calling.

At 11:46 AM 8/8/2006 -0600, Karihaloo, Ujjval wrote:
>As I understand 911 implementations today work in the IP --> PSTN model,
>which may change in the future, So, I think it would be prudent to cover
>both scenarios in the Draft (BCP or some new draft).
>
>Sent: Tuesday, August 08, 2006 11:36 AM
>To: Karihaloo, Ujjval; 'Henning Schulzrinne'; 'Andrew Newton'
>Cc: [email-masked]
>But we aren't discussing an IP to PSTN call.  We're talking about a VoIP
>to
>VoIP emergency call; the PSAP answers the call as VoIP, and we're
>talking
>about what codecs the PSAP must implement.
>
>Brian
>
> > From: Karihaloo, Ujjval [mailto:[email-masked]]
> > Sent: Tuesday, August 08, 2006 1:21 PM
> > To: Brian Rosen; Henning Schulzrinne; Andrew Newton
> > Cc: [email-masked]
> > For IP to PSTN call -
> >    1         2                 3
> > UA---> SBC-----> Voip Gateway ---> PSTN (Traditional PRI Trunk from
>VoIP
> > Gateway to say a DMS 250)
> >
> > There is a PRI connection in 3 above. So the VoIP Gateway would do the
> > conversion from any Compressed Codec (say G729) to G711 for the PSTN
> > Bearer.
> >
> > However, for AUDIO in step 2 above, is what I was looking for.
> >
> > Is "G711" the consensus in step 2 above?
> >
> > Sent: Tuesday, August 08, 2006 11:13 AM
> > To: 'Henning Schulzrinne'; 'Andrew Newton'
> > Cc: Karihaloo, Ujjval; [email-masked]
> > I don't really know enough about A law issues.  I believe, as you
> > suggest,
> > that the phones all support mu law.  That doesn't mean it's supported
> > through the carrier.  I'd be hesitant to say that, for emergency case
> > only,
> > mu Law was required, if they weren't already doing that, or at least
> > willing
> > to do that.  Plenty of VoIP systems "groom" codec lists with SBCs.
> >
> > I don't think any cellular network uses G.729.  GSM systems will
>support
> > AMR, which will be nice, but doesn't cover all the cases.  There will
>be
> > a
> > lot of EvRC out there I think.  There ARE a lot of other codecs out
> > there
> > now.  Of course, they are all now transcoded to G.711.
> >
> > Can someone tell us where the transcode is done?  Is it at the MSC
> > itself?
> > It may not be worth worrying about older systems because you may not
>be
> > able
> > to get the compressed voice stream packetized any reasonable way.  If
> > you
> > think about replacing the connection to the PSTN emergency call system
> > now
> > with a gateway, it may already G.711 by that point.  If the transcode
>is
> > already done on some kind of PSTN gateway, maybe we could replace that
> > gateway with a VoIP gateway, and then you would have to deal with all
> > the
> > old codecs.
> >
> > Brian
> >
> > > From: Henning Schulzrinne [mailto:[email-masked]]
> > > Sent: Tuesday, August 08, 2006 12:40 PM
> > > To: Andrew Newton
> > > Cc: Brian Rosen; 'Karihaloo, Ujjval'; [email-masked]
> > > Practically speaking, we're likely to have two classes of IP end
> > systems:
> > >
> > > (1) residential and enterprise, all of which speak G.711 mu-law
>today;
> > >
> > > (2) 3GPP and 3GPP2, which all support AMR (although I'm not sure
>which
> > > of the set of codecs in the AMR family are mandatory to support)
> > >
> > > Thus, I don't see this as particularly hard. I see no need to
>support
> > > A-law, unless somebody can show that there's a VoIP device out there
> > > that only speaks A-law.
> > >
> > > Also, it is not necessarily true that G.711 is more resilient
>against
> > > packet loss than compressed codecs.
> > >
> > > See http://www.globalipsound.com/datasheets/EG711.pdf for some
> > > comparisons.
> > >
> > > Clearly, we're using compressed codecs (G.729 and GSM-FR, primarily,
> > > although I'm not sure what Sprint's CDMA network uses) today for
> > > emergency calls, given that roughly half originate from cell phones.
> > >
> > > Henning
> > >
> > > Andrew Newton wrote:
> > > >
> > > > On Aug 8, 2006, at 9:18 AM, Brian Rosen wrote:
> > > >> Do we not agree that forcing every PSAP to support every codec
>that
> > > every
> > > >> carrier in its service area chooses makes no sense?  I'm assuming
> > we
> > > >> can't
> > > >> just pick one ourselves and demand the carriers support that one,
> > > >> right :)
> > > >
> > > > A lot of "nots" in the sentence.  Yes, PSAPs ought to be
>encouraged
> > to
> > > > support the codecs of the wireless carriers in the service area.
> > > >
> > > >> Do we not agree that supporting compressed codecs other than the
> > native
> > > >> wireless codecs is a bad idea (they all do g.711 also)?
> > > >
> > > > I really don't know about this.  I believe Barbara has a point.
> > > >
> > > > Also, I've been told that 3GPP2 has settled on a codec that MUST
>be
> > > > supported.
> > > >
> > > > -andy
> > > >

---

From: "GOLDMAN, STUART O \(STUART\)" <[email-masked]>
Date: Tue, 8 Aug 2006 13:18:06 -0500

It would seem prudent to at least explicitly address the IP to PSTN
scenario, so that it does not appear that we overlooked it.

Stuart Goldman
Lucent Technologies
[email-masked]
602 493 8438

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, August 08, 2006 11:36 AM
To: Karihaloo, Ujjval; 'Henning Schulzrinne'; 'Andrew Newton'
Cc: [email-masked]
Subject: RE: [Ecrit] Audio Codecs for 911 CALLS.

Brian

VoIP
support
be
be
is
today;
which
support
against
that
encouraged
be

---

From: "Karihaloo, Ujjval" <[email-masked]>
Date: Tue, 8 Aug 2006 12:25:55 -0600

I think AUDIO codecs for the IP side (2 - below) of the Call flow should
also be identified as well, irrespective of whether the termination on
the PSAP in IP or PSTN.
   1        2			 3
UA---> SBC-----> Voip Gateway ---> PSTN DMS or IP VoIP Gateway (PSAP)

---

From: "Karihaloo, Ujjval" <[email-masked]>
Date: Fri, 11 Aug 2006 11:47:47 -0600

Hi Hannes,

Is this feedback something you can incorporate into your draft?

Thx,

________________________________

From: Raymond Forbes [mailto:[email-masked]] 
Sent: Wednesday, August 09, 2006 3:18 AM
To: [email-masked]
Cc: Andrew Newton; [email-masked]; Henning Schulzrinne; Karihaloo,
Ujjval
Subject: RE: [Ecrit] Audio Codecs for 911 CALLS.

I support Barbara, G.711 mu-law is only a requirement in North America. 

If the IETF and Ecrit wants to develop a worldwide specification, the
Rest of the World uses G.711 A-law coding. For example all PSAPS in the
UK currently only support G.711 A-law encoding, and may optionally
support AMR for more efficient interworking with GSM. 

It is your choice but Ecrit RFCs will not change the encoding supported
in PSAPs in the Rest of the World. 

Regards,

Ray Forbes.

+44 24 7656 3106 phone
+44 24 7656 3816 fax.
+44 771 851 1361 Mobile/text
------------
This e-mail and any attachments are confidential.  If you are not the
intended recipient, please notify us immediately by reply e-mail and
then delete this message from your system. Do not copy this e-mail or
any attachments, use the contents for any purpose, or disclose the
contents to any other person: to do so could be a breach of confidence.

"Stark, Barbara" <[email-masked]> 

08/08/2006 19:46 

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

I suspect that if we were to not put A-law on an even par with mu-law,
the world outside North America would be most unhappy and see this as
yet another example of North American hubris. In fact, I have seen
devices that supported only A-law and not mu-law (provided to me by a
Korean vendor, who was unaware that mu-law was used by anybody). I've
never seen a device that didn't support A-law.

If we don't treat these as equals, then we're opening up the debate that
created the European A-law and North American mu-law all over again. I'd
really rather just say that both must be supported, and preference is up
to the device (which is generally set according to regional
preferences).

By the way, my point was not that compressed codecs were more resilient
to packet loss than 711, but that packet loss was more likely to occur
when running a codec that needs 106kbps (711 at 20ms sampling on a
PPPoE/ATM with LLC encoding connection), than one that (for example)
requires about 64kbps (729a at 20ms sampling on PPPoE/ATM with LLC
encoding), when the connection is at 128kbps upstream. Noise on this
line might cause the connection rate to drop to, say, 100kbps, at which
point 711 is definitely experiencing loss.
Barbara

> Practically speaking, we're likely to have two classes of IP 
> end systems:
> 
> (1) residential and enterprise, all of which speak G.711 mu-law today;
> 
> (2) 3GPP and 3GPP2, which all support AMR (although I'm not 
> sure which 
> Thus, I don't see this as particularly hard. I see no need to support 
> Also, it is not necessarily true that G.711 is more resilient against 
> See http://www.globalipsound.com/datasheets/EG711.pdf for 
> some comparisons.
> 
> >> Do we not agree that forcing every PSAP to support every 
> codec that every
> >> carrier in its service area chooses makes no sense?  I'm 
> assuming we 
> >> can't
> encouraged to 
> >> Do we not agree that supporting compressed codecs other 
> than the native
> > Also, I've been told that 3GPP2 has settled on a codec that MUST be 
> > supported.
> > 
> > -andy
> > 

*****

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by
persons or entities other than the intended recipient is prohibited. If
you received this in error, please contact the sender and delete the
material from all computers. 163

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 11 Aug 2006 15:12:08 -0500

At 11:47 AM 8/11/2006 -0600, Karihaloo, Ujjval wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C6BD6E.41D49889"
>
>Hi Hannes,
>
>
>

It probably could go into the phoneBCP ID that Brian and I are revising 
now.  We'll need to figure out where in the doc it belongs and exactly what 
to state (i.e. was there consensus?)

I'm not sure this belongs in the Framework ID...

I don't believe it should be in any other existing ID near ECRIT

>----------
>Cc: Andrew Newton; [email-masked]; Henning Schulzrinne; Karihaloo, Ujjval
>If the IETF and Ecrit wants to develop a worldwide specification, the Rest 
>of the World uses G.711 A-law coding. For example all PSAPS in the UK 
>currently only support G.711 A-law encoding, and may optionally support 
>AMR for more efficient interworking with GSM.
>
>It is your choice but Ecrit RFCs will not change the encoding supported in 
>PSAPs in the Rest of the World.
>
>Regards,
>
>Ray Forbes.
>
>+44 24 7656 3106 phone
>+44 24 7656 3816 fax.
>intended recipient, please notify us immediately by reply e-mail and then 
>delete this message from your system. Do not copy this e-mail or any 
>attachments, use the contents for any purpose, or disclose the contents to 
>any other person: to do so could be a breach of confidence.
>
>
>
>
>I suspect that if we were to not put A-law on an even par with mu-law, the 
>world outside North America would be most unhappy and see this as yet 
>another example of North American hubris. In fact, I have seen devices 
>that supported only A-law and not mu-law (provided to me by a Korean 
>vendor, who was unaware that mu-law was used by anybody). I've never seen 
>a device that didn't support A-law.
>
>to the device (which is generally set according to regional preferences).
>
>By the way, my point was not that compressed codecs were more resilient to 
>packet loss than 711, but that packet loss was more likely to occur when 
>running a codec that needs 106kbps (711 at 20ms sampling on a PPPoE/ATM 
>with LLC encoding connection), than one that (for example) requires about 
>64kbps (729a at 20ms sampling on PPPoE/ATM with LLC encoding), when the 
>connection is at 128kbps upstream. Noise on this line might cause the 
>connection rate to drop to, say, 100kbps, at which point 711 is definitely 
>experiencing loss.
>Barbara
>