SDO Emergency Services Coordination Workshop

-andy --=_zeke.ecotroph.net-29287-1154998165-0001-2-- --===============1406882860== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1406882860==-- From ecrit-bounces@ietf.org Mon Aug 07 20:51:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAFp7-0004nI-G4; Mon, 07 Aug 2006 20:51:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAFp5-0004nD-QB for ecrit@ietf.org; Mon, 07 Aug 2006 20:51:55 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAFp4-0000IJ-DD for ecrit@ietf.org; Mon, 07 Aug 2006 20:51:55 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 07 Aug 2006 17:51:54 -0700 X-IronPort-AV: i="4.07,220,1151910000"; d="scan'208"; a="1845013522:sNHT27878232" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k780prKj021312; Mon, 7 Aug 2006 17:51:53 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k780pruF025077; Mon, 7 Aug 2006 17:51:53 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Aug 2006 17:51:53 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.144.223]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Aug 2006 17:51:52 -0700 Message-Id: <4.3.2.7.2.20060807194601.03736a10@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 Aug 2006 19:51:51 -0500 To: "Brian Rosen" , "'Andrew Newton'" From: "James M. Polk" Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. In-Reply-To: <073801c6ba80$6aab28a0$9de6a8c0@cis.neustar.com> References: <4.3.2.7.2.20060807174652.0335de68@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Aug 2006 00:51:52.0955 (UTC) FILETIME=[D6D7BCB0:01C6BA84] DKIM-Signature: a=rsa-sha1; q=dns; l=3444; t=1154998313; x=1155862313; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Ecrit]=20Audio=20Codecs=20for=20911=20CALLS.; X=v=3Dcisco.com=3B=20h=3DI80dhTFbN9LJpWYiFmBjB6VEZh0=3D; b=nXSp+3zFmh8oLseOt42GlZECdVswrzTTjduvGWPiRDIReURmL359B/DLxlDt0x2b3Bqe93lE ZGNKJ29UEFlCSHGba0k5WF8Iw/S8G5pvQrRpnzIfDSOXBDuPRUZAqad1; Authentication-Results: sj-dkim-8.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: "'Karihaloo, Ujjval'" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian 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: >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:jmpolk@cisco.com] > > Sent: Monday, August 07, 2006 6:48 PM > > To: Andrew Newton > > Cc: ecrit@ietf.org; 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 > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Aug 07 21:02:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAFys-0001jZ-Jl; Mon, 07 Aug 2006 21:02:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAFyr-0001jT-O6 for ecrit@ietf.org; Mon, 07 Aug 2006 21:02:01 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAFyq-0001nr-4F for ecrit@ietf.org; Mon, 07 Aug 2006 21:02:01 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 07 Aug 2006 20:56:57 -0400 id 015880AE.44D7E159.0000736B In-Reply-To: <073801c6ba80$6aab28a0$9de6a8c0@cis.neustar.com> References: <073801c6ba80$6aab28a0$9de6a8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. Date: Mon, 7 Aug 2006 20:56:47 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ecrit@ietf.org, "'Karihaloo, Ujjval'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Aug 7, 2006, at 8:20 PM, Brian Rosen wrote: > 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. What about WiFi SIP phones and DECT phones? > 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. I'm glad we can agree on this. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 01:52:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAKVy-0004JY-VD; Tue, 08 Aug 2006 01:52:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAKVx-0004JT-TT for ecrit@ietf.org; Tue, 08 Aug 2006 01:52:29 -0400 Received: from pne-smtpout2-sn1.fre.skanova.net ([81.228.11.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAKVw-00037K-Ho for ecrit@ietf.org; Tue, 08 Aug 2006 01:52:29 -0400 Received: from Misan (213.64.228.153) by pne-smtpout2-sn1.fre.skanova.net (7.2.075) id 44A135F10081B3BF; Tue, 8 Aug 2006 07:52:00 +0200 From: =?us-ascii?Q?Gunnar_Hellstrom?= To: "Brian Rosen" , "'James M. Polk'" , "'Andrew Newton'" Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 06:51:57 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <073801c6ba80$6aab28a0$9de6a8c0@cis.neustar.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: "'Karihaloo, Ujjval'" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, I am glad to see this statement: "Every PSAP will support the text codec, of course," Regards Gunnar gunnar.hellstrom@omnitor.se -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, August 08, 2006 1:20 AM To: 'James M. Polk'; 'Andrew Newton' Cc: 'Karihaloo, Ujjval'; ecrit@ietf.org 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:jmpolk@cisco.com] > Sent: Monday, August 07, 2006 6:48 PM > To: Andrew Newton > Cc: ecrit@ietf.org; 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 > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 09:18:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GARTi-0001gE-VZ; Tue, 08 Aug 2006 09:18:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GARTh-0001g9-U6 for ecrit@ietf.org; Tue, 08 Aug 2006 09:18:37 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GARTg-0005rz-LX for ecrit@ietf.org; Tue, 08 Aug 2006 09:18:37 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GARTa-0006bB-6q; Tue, 08 Aug 2006 08:18:30 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 09:18:30 -0400 Message-ID: <07a501c6baed$269f2fe0$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca6hYWCSoIf3v8DTjqP/r/lM1Q+cgAZrVHQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ecrit@ietf.org, "'Karihaloo, Ujjval'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Every spec for a WiFi SIP phone I've ever seen supported G.711 from the handset. I don't know much about DECT phones, especially what codecs they support in the handset, but they clearly support G.711 coming out of the "base station", because they usually have ISDN connection options. 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 :) Do we not agree that supporting compressed codecs other than the native wireless codecs is a bad idea (they all do g.711 also)? Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Monday, August 07, 2006 8:57 PM > To: Brian Rosen > Cc: 'James M. Polk'; ecrit@ietf.org; 'Karihaloo, Ujjval' > Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. > > > On Aug 7, 2006, at 8:20 PM, Brian Rosen wrote: > > 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. > > What about WiFi SIP phones and DECT phones? > > > 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. > > I'm glad we can agree on this. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 09:23:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GARYb-0003zy-6x; Tue, 08 Aug 2006 09:23:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GARYZ-0003uj-Ub for ecrit@ietf.org; Tue, 08 Aug 2006 09:23:39 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GARYX-0006k8-GU for ecrit@ietf.org; Tue, 08 Aug 2006 09:23:39 -0400 Received: from ([90.152.44.174]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.155244102; Tue, 08 Aug 2006 09:23:16 -0400 Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01AL10015010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 8 Aug 2006 08:23:15 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 08:23:15 -0500 Message-ID: <9888E1AA13C3A1459D122996A58C0E1107CA35BB@bre2k61p-55> Importance: normal X-MS-Has-Attach: Priority: normal X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Audio Codecs for 911 CALLS. Thread-Index: Aca6c4Hm4v+o2r3GRLCwxwV7L/Io1wAC26EQABodlKA= From: "Stark, Barbara" To: "Brian Rosen" , "James M. Polk" , "Andrew Newton" X-OriginalArrivalTime: 08 Aug 2006 13:23:15.0694 (UTC) FILETIME=[CE3FC8E0:01C6BAED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: "Karihaloo, Ujjval" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org 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.=20 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.=20 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 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, August 07, 2006 8:20 PM > To: 'James M. Polk'; 'Andrew Newton' > Cc: 'Karihaloo, Ujjval'; ecrit@ietf.org > Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. >=20 >=20 > I believe that the minimum codec is G.711. Every PSAP will=20 > support it, > every call must be able to support it. >=20 > I think we will recommend that every PSAP support the codecs=20 > 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=20 > vantage point, the > lack of standardization in this area (and I do mean "the=20 > wonderful thing > about standards is there are so many to choose from") is glaringly, > painfully stupid. >=20 > It is unwise to support the compressed codecs (G.723, G.729,=20 > ...). Some of > the adaptable codecs might be supported in their=20 > better-than-toll-quality > modes. >=20 > We might want to recommend support for straight linear 16 bit=20 > audio, so that > transcoding can be minimal loss, although since no=20 > transcoders can do this > now, that might be a futile gesture. >=20 > Every PSAP will support the text codec, of course, and I=20 > hope, one or two IM > streams. Every PSAP will probably (maybe eventually) support=20 > H.264, and > some will support H.263. >=20 > But in the end, I think these have to be recommendations=20 > (SHOULD) and thus > the MUST, for everyone, is G.711. >=20 > AND NO VOICE ACTIVITY DETECTION. >=20 > And I don't think this is SPEERMINT territory, even if the=20 > subject matter > overlaps some. Peering is not assumed to be able to place an=20 > emergency > call. >=20 > Brian >=20 > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Monday, August 07, 2006 6:48 PM > > To: Andrew Newton > > Cc: ecrit@ietf.org; Karihaloo, Ujjval > > Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. > >=20 > > At 06:44 PM 8/7/2006 -0400, Andrew Newton wrote: > >=20 > > >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=20 > 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=20 > 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. > >=20 > > err, what do you think will be answering the call in the PSAP? > >=20 > > (hint: it'll be a UA) > >=20 > >=20 > > >-andy > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 ***** 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 10:03:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASAi-0007Jn-HT; Tue, 08 Aug 2006 10:03:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASAi-0007Jc-4C for ecrit@ietf.org; Tue, 08 Aug 2006 10:03:04 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GASAh-0002yg-Na for ecrit@ietf.org; Tue, 08 Aug 2006 10:03:04 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 08 Aug 2006 10:03:04 -0400 X-IronPort-AV: i="4.07,222,1151899200"; d="scan'208"; a="95665565:sNHT33425686" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k78E33B9022731; Tue, 8 Aug 2006 10:03:03 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k78E32dr009063; Tue, 8 Aug 2006 10:03:02 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 10:02:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 10:02:42 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301C6E381@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Audio Codecs for 911 CALLS. Thread-Index: Aca6hO5eiGEPJF30QG65TZxCVv3LvwAbe18A From: "Michael Hammer $mhammer$" To: "James Polk $jmpolk$" , "Brian Rosen" , "Andrew Newton" X-OriginalArrivalTime: 08 Aug 2006 14:02:43.0242 (UTC) FILETIME=[516AF0A0:01C6BAF3] DKIM-Signature: a=rsa-sha1; q=dns; l=4606; t=1155045783; x=1155909783; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20$mhammer$=22=20 |Subject:RE=3A=20[Ecrit]=20Audio=20Codecs=20for=20911=20CALLS. |To:=22James=20Polk=20$jmpolk$=22=20, =0A=20=20=20=20=20= 20=20=20=22Brian=20Rosen=22=20, =20=22Andrew=20Newton=22= 20; X=v=3Dcisco.com=3B=20h=3DHFX3C1fMM2Y7Cyk0Y11hJTtb7RM=3D; b=Dq/SF7bx8xBFvB6gdH1vFBcvz7IS3NWysNvz4VtPTMEQNjHmV3DcCL2guMsM6SZ/19Izt4co l0U/OEIbEveJ1cq9oyy+jsL2RMuyWc015hpKK7oPMjA+Nj/8u71vykdX; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: "Karihaloo, Ujjval" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org 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 =20 > -----Original Message----- > From: James Polk (jmpolk)=20 > Sent: Monday, August 07, 2006 8:52 PM > To: Brian Rosen; 'Andrew Newton' > Cc: 'Karihaloo, Ujjval'; ecrit@ietf.org > Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. >=20 > Brian >=20 > I agree completely. >=20 > And I have a comment about SPEERMINT: though peering=20 > shouldn't have anything to do with endpoint codec support,=20 > peering in SIP will likely involve an SBC, which, by=20 > definition is a B2BUA - meaning it can change the SDP,=20 > meaning it can change the codecs to whatever it wants. >=20 > That said, we don't want peering (meaning SPEERMINT) to *NOT*=20 > have a requirement from this WG to support our minimal=20 > specifications in ECRIT to establish SIP calls as if the=20 > peering point wasn't there. >=20 > We/someone needs to make that WG aware of this situation -=20 > and have them incorporate, if appropriate, whatever we=20 > reasonably require of a peering specification from them. >=20 > At 08:20 PM 8/7/2006 -0400, Brian Rosen wrote: > >I believe that the minimum codec is G.711. Every PSAP will=20 > support it,=20 > >every call must be able to support it. > > > >I think we will recommend that every PSAP support the codecs=20 > applicable=20 > >to the wireless networks that are in their service=20 > boundaries, as well=20 > >as wideband codecs that may be supported in their service=20 > area, so that=20 > >transcoding is not required. From the emergency service=20 > vantage point,=20 > >the lack of standardization in this area (and I do mean "the=20 > wonderful=20 > >thing about standards is there are so many to choose from") is=20 > >glaringly, painfully stupid. > > > >It is unwise to support the compressed codecs (G.723, G.729, ...). =20 > >Some of the adaptable codecs might be supported in their=20 > >better-than-toll-quality modes. > > > >We might want to recommend support for straight linear 16=20 > bit audio, so=20 > >that transcoding can be minimal loss, although since no=20 > transcoders can=20 > >do this now, that might be a futile gesture. > > > >Every PSAP will support the text codec, of course, and I=20 > hope, one or=20 > >two IM streams. Every PSAP will probably (maybe eventually) support=20 > >H.264, and some will support H.263. > > > >But in the end, I think these have to be recommendations=20 > (SHOULD) and=20 > >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=20 > >matter overlaps some. Peering is not assumed to be able to place an=20 > >emergency call. > > > >Brian > > > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: Monday, August 07, 2006 6:48 PM > > > To: Andrew Newton > > > Cc: ecrit@ietf.org; 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=20 > environments. > > > >> > > > >> > > > >>does this mean that my wired IP-phone, like the majority of all=20 > > > >>others, will not have any chance at communicating with anyone=20 > > > >>else's IP cellphone? I think the reverse will have the=20 > same problem... > > > > > > > >That's my non-expert understanding. Fortunately, we aren't=20 > > > >concerned > > > with > > > >getting a call through between any two UAs: we are=20 > 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 > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 10:32:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASch-0005pq-N9; Tue, 08 Aug 2006 10:31:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAScg-0005pl-KJ for ecrit@ietf.org; Tue, 08 Aug 2006 10:31:58 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAScd-0007ws-DW for ecrit@ietf.org; Tue, 08 Aug 2006 10:31:58 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 08 Aug 2006 10:32:00 -0400 id 015880E4.44D8A060.0000661F In-Reply-To: <07a501c6baed$269f2fe0$9de6a8c0@cis.neustar.com> References: <07a501c6baed$269f2fe0$9de6a8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C0ED4EB-6D15-48B3-BC92-6497A9738F16@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 10:31:53 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "'Karihaloo, Ujjval'" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 11:34:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GATbS-0005KC-CV; Tue, 08 Aug 2006 11:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GATbR-0005Je-Eq for ecrit@ietf.org; Tue, 08 Aug 2006 11:34:45 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GATbO-000153-VU for ecrit@ietf.org; Tue, 08 Aug 2006 11:34:45 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GATbH-0007yI-N9; Tue, 08 Aug 2006 10:34:36 -0500 From: "Brian Rosen" To: Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 11:34:37 -0400 Message-ID: <07c801c6bb00$2a41d770$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca696Qhz07Wa4HgTDiIFG72SmnJAQAAtP2Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: ecrit@ietf.org, "'Karihaloo, Ujjval'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org 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. =20 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: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Tuesday, August 08, 2006 10:34 AM To: Brian Rosen Cc: 'Andrew Newton'; ecrit@ietf.org; 'James M. Polk'; 'Karihaloo, = Ujjval' Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Hi,=20 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). =A0To 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. =A0Alternatively, 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. =A0=20 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 ;-). =A0I 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. =A0On 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. =A0I believe everything else, such as wb audio, iLBC, video, IM, etc, becomes SHOULD on the PSAP end. =A0Perhaps = over time, as it becomes more clear what proportion of endpoints will support = the others, the PSAP MUST list should be extended. =A0=20 BTW, Somewhere waaaay down this thread someone said "it's in the BCP". = =A0I don't think it actually is. =A0I assume it will be added? =A0=20 -- Peter=20 "Brian Rosen" =20 07.08.06 20:20=20 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0"'James M. Polk'" , = "'Andrew Newton'" =20 =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0"'Karihaloo, Ujjval'" = , ecrit@ietf.org=20 =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0RE: [Ecrit] Audio Codecs for 911 = CALLS. I believe that the minimum codec is G.711. =A0Every 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. =A0From 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, ...). = =A0Some 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. =A0Every 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. =A0Peering is not assumed to be able to place an = emergency call. Brian > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Monday, August 07, 2006 6:48 PM > To: Andrew Newton > Cc: ecrit@ietf.org; Karihaloo, Ujjval > Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. >=20 > At 06:44 PM 8/7/2006 -0400, Andrew Newton wrote: >=20 > >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? =A0I think the reverse will have the same problem... > > > >That's my non-expert understanding. =A0Fortunately, 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. >=20 > err, what do you think will be answering the call in the PSAP? >=20 > (hint: it'll be a UA) >=20 >=20 > >-andy >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 11:35:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GATc9-0005RA-02; Tue, 08 Aug 2006 11:35:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GATc7-0005R5-MY for ecrit@ietf.org; Tue, 08 Aug 2006 11:35:27 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GASkl-0008Vf-Lg for ecrit@ietf.org; Tue, 08 Aug 2006 10:40:19 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GASeS-0006wk-Bv for ecrit@ietf.org; Tue, 08 Aug 2006 10:33:50 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id CBE4B2004E; Tue, 8 Aug 2006 10:33:41 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19953-04; Tue, 8 Aug 2006 10:33:41 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 329B42002E; Tue, 8 Aug 2006 10:33:41 -0400 (EDT) To: "Brian Rosen" Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: peter_blatherwick@mitel.com Date: Tue, 8 Aug 2006 10:33:40 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 08/08/2006 10:33:37 AM, Serialize complete at 08/08/2006 10:33:37 AM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: -2.5 (--) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: ecrit@ietf.org, "'Karihaloo, Ujjval'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2105578747==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============2105578747== Content-Type: multipart/alternative; boundary="=_alternative 004FFFB0852571C4_=" This is a multipart message in MIME format. --=_alternative 004FFFB0852571C4_= Content-Type: text/plain; charset="us-ascii" 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" 07.08.06 20:20 To: "'James M. Polk'" , "'Andrew Newton'" cc: "'Karihaloo, Ujjval'" , ecrit@ietf.org 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:jmpolk@cisco.com] > Sent: Monday, August 07, 2006 6:48 PM > To: Andrew Newton > Cc: ecrit@ietf.org; 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 > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --=_alternative 004FFFB0852571C4_= Content-Type: text/html; charset="us-ascii"
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" <br@brianrosen.net>

07.08.06 20:20

To: "'James M. Polk'" <jmpolk@cisco.com>, "'Andrew Newton'" <andy@hxr.us>
cc: "'Karihaloo, Ujjval'" <Ujjval.Karihaloo@Level3.com>, ecrit@ietf.org
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:jmpolk@cisco.com]
> Sent: Monday, August 07, 2006 6:48 PM
> To: Andrew Newton
> Cc: ecrit@ietf.org; 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
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

--=_alternative 004FFFB0852571C4_=-- --===============2105578747== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2105578747==-- From ecrit-bounces@ietf.org Tue Aug 08 11:52:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GATsR-0006iO-DP; Tue, 08 Aug 2006 11:52:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GATsQ-0006iJ-Lc for ecrit@ietf.org; Tue, 08 Aug 2006 11:52:18 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GATsN-0003mf-TE for ecrit@ietf.org; Tue, 08 Aug 2006 11:52:18 -0400 Received: from ([90.152.53.183]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.155295201; Tue, 08 Aug 2006 11:51:57 -0400 Importance: normal Priority: normal Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01AL10015010163.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 8 Aug 2006 10:51:57 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 10:51:57 -0500 Message-ID: <9888E1AA13C3A1459D122996A58C0E1109A9BE7C@bre2k61p-55> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Audio Codecs for 911 CALLS. thread-index: Aca7AFbXUoLjmhWdQpCzpg+xNa0EtAAAhufg From: "Stark, Barbara" To: , "Brian Rosen" X-OriginalArrivalTime: 08 Aug 2006 15:51:57.0621 (UTC) FILETIME=[9421CE50:01C6BB02] X-Spam-Score: 0.4 (/) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 Cc: "Karihaloo, Ujjval" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1924736212==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1924736212== Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6BB02.93E2B5F8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BB02.93E2B5F8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable BCP says: 12. A normal SDP offer SHOULD be included in the INVITE. The offer SHOULD NOT include compressed audio codecs, although a wideband codec offer MAY be included. Note: 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. Barbara -----Original Message----- From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Tuesday, August 08, 2006 10:34 AM To: Brian Rosen Cc: ecrit@ietf.org; 'Karihaloo, Ujjval' Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Hi,=20 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. =20 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. =20 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? =20 -- Peter=20 "Brian Rosen" =20 07.08.06 20:20=20 =20 To: "'James M. Polk'" , "'Andrew Newton'" =20 cc: "'Karihaloo, Ujjval'" , ecrit@ietf.org=20 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:jmpolk@cisco.com] > Sent: Monday, August 07, 2006 6:48 PM > To: Andrew Newton > Cc: ecrit@ietf.org; Karihaloo, Ujjval > Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. >=20 > At 06:44 PM 8/7/2006 -0400, Andrew Newton wrote: >=20 > >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. >=20 > err, what do you think will be answering the call in the PSAP? >=20 > (hint: it'll be a UA) >=20 >=20 > >-andy >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** 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 ------_=_NextPart_001_01C6BB02.93E2B5F8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

BCP=20 says:

   12. A normal = SDP offer=20 SHOULD be included in the INVITE. The=20 offer
        SHOULD NOT include=20 compressed audio codecs, although a=20 wideband
        codec offer MAY = be=20 included.

   Note: Silence suppression (Voice Activity=20 Detection methods) MUST NOT
   be used on emergency = calls. =20 PSAP call takers sometimes get
   information on what is = happening=20 in the background to determine how
   to process the = call.

Barbara

-----Original Message-----
From: = peter_blatherwick@mitel.com=20 [mailto:peter_blatherwick@mitel.com]
Sent: Tuesday, August = 08, 2006=20 10:34 AM
To: Brian Rosen
Cc: ecrit@ietf.org; = 'Karihaloo,=20 Ujjval'
Subject: RE: [Ecrit] Audio Codecs for 911=20 CALLS.

Hi,=20

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

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

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

-- Peter

"Brian Rosen"=20 <br@brianrosen.net>=20

07.08.06 20:20 =

=
To: = =20 "'James M. Polk'" <jmpolk@cisco.com>, = "'Andrew=20 Newton'" <andy@hxr.us>
cc: =20 "'Karihaloo, Ujjval'" <Ujjval.Karihaloo@Level3.com>, = ecrit@ietf.org
=20 Subject: RE: [Ecrit] = Audio=20 Codecs for 911 = CALLS.

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

I think we will recommend that every PSAP support the = codecs=20 applicable to
the wireless networks that are in their service = boundaries,=20 as well as
wideband codecs that may be supported in their service = area, so=20 that
transcoding is not required. From the emergency service = vantage=20 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=20 glaringly,
painfully stupid.

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

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

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

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

AND NO VOICE ACTIVITY = DETECTION.

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

Brian

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

_________________= ______________________________
Ecrit=20 mailing=20 = list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

<= FONT color=3D#0000ff>

*****

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

------_=_NextPart_001_01C6BB02.93E2B5F8-- --===============1924736212== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1924736212==-- From ecrit-bounces@ietf.org Tue Aug 08 12:02:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAU2D-0003rb-7p; Tue, 08 Aug 2006 12:02:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAU2C-0003rV-2n for ecrit@ietf.org; Tue, 08 Aug 2006 12:02:24 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAU2B-0005Ft-LR for ecrit@ietf.org; Tue, 08 Aug 2006 12:02:24 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GAU24-0001lA-Kn; Tue, 08 Aug 2006 11:02:17 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 12:02:18 -0400 Message-ID: <07cc01c6bb04$086a10f0$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7AFbXUoLjmhWdQpCzpg+xNa0EtAAAhufgAABe1fA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <9888E1AA13C3A1459D122996A58C0E1109A9BE7C@bre2k61p-55> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: "'Karihaloo, Ujjval'" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We=92ll need to make a real list if this converges. ________________________________________ From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]=20 Sent: Tuesday, August 08, 2006 11:52 AM To: peter_blatherwick@mitel.com; Brian Rosen Cc: ecrit@ietf.org; Karihaloo, Ujjval Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. BCP says: =A0=A0 12.=A0 A normal SDP offer SHOULD be included in the INVITE.=A0 = The offer =A0=A0=A0=A0=A0=A0=A0 SHOULD NOT include compressed audio codecs, = although a wideband =A0=A0=A0=A0=A0=A0=A0 codec offer MAY be included. =A0=A0 Note: Silence suppression (Voice Activity Detection methods) MUST = NOT =A0=A0 be used on emergency calls.=A0 PSAP call takers sometimes get =A0=A0 information on what is happening in the background to determine = how =A0=A0 to process the call. Barbara -----Original Message----- From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Tuesday, August 08, 2006 10:34 AM To: Brian Rosen Cc: ecrit@ietf.org; 'Karihaloo, Ujjval' Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Hi,=20 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). =A0To 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. =A0Alternatively, 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. =A0=20 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 ;-). =A0I 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. =A0On 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. =A0I believe everything else, such as wb audio, iLBC, video, IM, etc, becomes SHOULD on the PSAP end. =A0Perhaps = over time, as it becomes more clear what proportion of endpoints will support = the others, the PSAP MUST list should be extended. =A0=20 BTW, Somewhere waaaay down this thread someone said "it's in the BCP". = =A0I don't think it actually is. =A0I assume it will be added? =A0=20 -- Peter=20 "Brian Rosen" =20 07.08.06 20:20=20 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0"'James M. Polk'" , = "'Andrew Newton'" =20 =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0"'Karihaloo, Ujjval'" = , ecrit@ietf.org=20 =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0RE: [Ecrit] Audio Codecs for 911 = CALLS. I believe that the minimum codec is G.711. =A0Every 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. =A0From 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, ...). = =A0Some 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. =A0Every 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. =A0Peering is not assumed to be able to place an = emergency call. Brian > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Monday, August 07, 2006 6:48 PM > To: Andrew Newton > Cc: ecrit@ietf.org; Karihaloo, Ujjval > Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. >=20 > At 06:44 PM 8/7/2006 -0400, Andrew Newton wrote: >=20 > >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? =A0I think the reverse will have the same problem... > > > >That's my non-expert understanding. =A0Fortunately, 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. >=20 > err, what do you think will be answering the call in the PSAP? >=20 > (hint: it'll be a UA) >=20 >=20 > >-andy >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 12:40:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAUdW-0008RT-Ij; Tue, 08 Aug 2006 12:40:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAUdV-0008P0-CZ for ecrit@ietf.org; Tue, 08 Aug 2006 12:40:57 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAUdS-0001Po-2l for ecrit@ietf.org; Tue, 08 Aug 2006 12:40:57 -0400 Received: from lion.cs.columbia.edu (IDENT:wEUoyCcU5CSueiSQ8fBlXbs2kGX8feAS@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k78GeWf7021238 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 8 Aug 2006 12:40:32 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k78GeVrh014461 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Aug 2006 12:40:31 -0400 Message-ID: <44D8BE7A.20103@cs.columbia.edu> Date: Tue, 08 Aug 2006 12:40:26 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. References: <07a501c6baed$269f2fe0$9de6a8c0@cis.neustar.com> <3C0ED4EB-6D15-48B3-BC92-6497A9738F16@hxr.us> In-Reply-To: <3C0ED4EB-6D15-48B3-BC92-6497A9738F16@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.8.92433 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_NOT_1 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: "'Karihaloo, Ujjval'" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org 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 > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 13:16:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVBl-00028D-FH; Tue, 08 Aug 2006 13:16:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVBk-000283-9I for ecrit@ietf.org; Tue, 08 Aug 2006 13:16:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAVBk-0001Ac-75 for ecrit@ietf.org; Tue, 08 Aug 2006 13:16:20 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAV96-00014q-Vp for ecrit@ietf.org; Tue, 08 Aug 2006 13:13:39 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GAV8w-0007vb-Vk; Tue, 08 Aug 2006 12:13:29 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Andrew Newton'" Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 13:13:29 -0400 Message-ID: <07e601c6bb0d$fb3a0390$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7CWYtwEcHMSjyTdKQhcIu7xmkWwAA1MsQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44D8BE7A.20103@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.4 (--) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: "'Karihaloo, Ujjval'" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org 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 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, August 08, 2006 12:40 PM > To: Andrew Newton > Cc: Brian Rosen; 'Karihaloo, Ujjval'; ecrit@ietf.org > Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. > > 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 > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 13:20:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVG9-0004Uk-N9; Tue, 08 Aug 2006 13:20:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVG8-0004Ub-Ch for ecrit@ietf.org; Tue, 08 Aug 2006 13:20:52 -0400 Received: from qfe1.f10207-20.atlanta2.level3.net ([67.72.93.25] helo=f10207-20.adc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAVG6-00027f-15 for ecrit@ietf.org; Tue, 08 Aug 2006 13:20:52 -0400 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f10207-20.adc1.level3.com (8.12.10/8.12.10) with ESMTP id k78HKh3N015436; Tue, 8 Aug 2006 17:20:43 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 963D112481E; Tue, 8 Aug 2006 17:20:42 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id 3184612482A; Tue, 8 Aug 2006 17:20:42 +0000 (GMT) Received: from idc1exc0004.corp.global.level3.com ([10.1.9.15]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 11:20:41 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 11:20:40 -0600 Message-ID: <99148FC6551C9641A4B1CDE206D895440DB2564D@idc1exc0004.corp.global.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Audio Codecs for 911 CALLS. Thread-Index: Aca7CWYtwEcHMSjyTdKQhcIu7xmkWwAA1MsQAABnQRA= From: "Karihaloo, Ujjval" To: "Brian Rosen" , "Henning Schulzrinne" , "Andrew Newton" X-OriginalArrivalTime: 08 Aug 2006 17:20:41.0967 (UTC) FILETIME=[F9B087F0:01C6BB0E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org For IP to PSTN call -=20 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? -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, August 08, 2006 11:13 AM To: 'Henning Schulzrinne'; 'Andrew Newton' Cc: Karihaloo, Ujjval; ecrit@ietf.org Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. 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.=20 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 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, August 08, 2006 12:40 PM > To: Andrew Newton > Cc: Brian Rosen; 'Karihaloo, Ujjval'; ecrit@ietf.org > Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. >=20 > Practically speaking, we're likely to have two classes of IP end systems: >=20 > (1) residential and enterprise, all of which speak G.711 mu-law today; >=20 > (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) >=20 > 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. >=20 > Also, it is not necessarily true that G.711 is more resilient against > packet loss than compressed codecs. >=20 > See http://www.globalipsound.com/datasheets/EG711.pdf for some > comparisons. >=20 > 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. >=20 > Henning >=20 > 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 > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 13:31:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVQr-0001wc-MI; Tue, 08 Aug 2006 13:31:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVQq-0001wX-5c for ecrit@ietf.org; Tue, 08 Aug 2006 13:31:56 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAVQm-00045n-S0 for ecrit@ietf.org; Tue, 08 Aug 2006 13:31:56 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 08 Aug 2006 10:31:52 -0700 X-IronPort-AV: i="4.07,222,1151910000"; d="scan'208"; a="1845241223:sNHT25777996" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k78HVqK7010169; Tue, 8 Aug 2006 10:31:52 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k78HVpIZ018295; Tue, 8 Aug 2006 10:31:51 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Aug 2006 10:31:51 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.96.36]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 10:31:50 -0700 Message-Id: <4.3.2.7.2.20060808122814.03789ef8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Aug 2006 12:31:49 -0500 To: "Brian Rosen" , From: "James M. Polk" Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. In-Reply-To: <07c801c6bb00$2a41d770$9de6a8c0@cis.neustar.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Aug 2006 17:31:51.0020 (UTC) FILETIME=[8879EAC0:01C6BB10] DKIM-Signature: a=rsa-sha1; q=dns; l=496; t=1155058312; x=1155922312; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Ecrit]=20Audio=20Codecs=20for=20911=20CALLS.; X=v=3Dcisco.com=3B=20h=3DI80dhTFbN9LJpWYiFmBjB6VEZh0=3D; b=F5O2M+wet1o9+4lC0nL4imh+uLfu+dSohLtimUE6AVax569Sp2wOXFZHZWQgVxmuWfE47BdX qUP1UgpN2tIVHW/rd0zPOb70krZ/SgsrLTy7RR1+/zak9mEWQPsTtySb; Authentication-Results: sj-dkim-8.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "'Karihaloo, Ujjval'" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org 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. >Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 13:36:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVV2-0003TW-7u; Tue, 08 Aug 2006 13:36:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVV0-0003SV-9Q for ecrit@ietf.org; Tue, 08 Aug 2006 13:36:14 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAVUx-0004O3-Ru for ecrit@ietf.org; Tue, 08 Aug 2006 13:36:14 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GAVUq-0001cE-Ef; Tue, 08 Aug 2006 12:36:04 -0500 From: "Brian Rosen" To: "'Karihaloo, Ujjval'" , "'Henning Schulzrinne'" , "'Andrew Newton'" Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 13:36:07 -0400 Message-ID: <07eb01c6bb11$23295fb0$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7CWYtwEcHMSjyTdKQhcIu7xmkWwAA1MsQAABnQRAAAKAYgA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <99148FC6551C9641A4B1CDE206D895440DB2564D@idc1exc0004.corp.global.level3.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org 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 > -----Original Message----- > From: Karihaloo, Ujjval [mailto:Ujjval.Karihaloo@Level3.com] > Sent: Tuesday, August 08, 2006 1:21 PM > To: Brian Rosen; Henning Schulzrinne; Andrew Newton > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. > > 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? > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, August 08, 2006 11:13 AM > To: 'Henning Schulzrinne'; 'Andrew Newton' > Cc: Karihaloo, Ujjval; ecrit@ietf.org > Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. > > 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 > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Tuesday, August 08, 2006 12:40 PM > > To: Andrew Newton > > Cc: Brian Rosen; 'Karihaloo, Ujjval'; ecrit@ietf.org > > Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. > > > > 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 > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 13:46:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVed-0000VU-8S; Tue, 08 Aug 2006 13:46:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVec-0000VP-92 for ecrit@ietf.org; Tue, 08 Aug 2006 13:46:10 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAVeZ-0006NV-R9 for ecrit@ietf.org; Tue, 08 Aug 2006 13:46:10 -0400 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k78Hk3aK024076; Tue, 8 Aug 2006 17:46:03 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 3BD9F12480E; Tue, 8 Aug 2006 17:46:03 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id D4076124816; Tue, 8 Aug 2006 17:46:02 +0000 (GMT) Received: from idc1exc0004.corp.global.level3.com ([10.1.9.15]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 11:46:02 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 11:46:01 -0600 Message-ID: <99148FC6551C9641A4B1CDE206D895440DB256B1@idc1exc0004.corp.global.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Audio Codecs for 911 CALLS. Thread-Index: Aca7CWYtwEcHMSjyTdKQhcIu7xmkWwAA1MsQAABnQRAAAKAYgAAAWyAg From: "Karihaloo, Ujjval" To: "Brian Rosen" , "Henning Schulzrinne" , "Andrew Newton" X-OriginalArrivalTime: 08 Aug 2006 17:46:02.0516 (UTC) FILETIME=[8401E540:01C6BB12] X-Spam-Score: 0.1 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org 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). -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, August 08, 2006 11:36 AM To: Karihaloo, Ujjval; 'Henning Schulzrinne'; 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. 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. =20 Brian > -----Original Message----- > From: Karihaloo, Ujjval [mailto:Ujjval.Karihaloo@Level3.com] > Sent: Tuesday, August 08, 2006 1:21 PM > To: Brian Rosen; Henning Schulzrinne; Andrew Newton > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. >=20 > For IP to PSTN call - >=20 > 1 2 3 > UA---> SBC-----> Voip Gateway ---> PSTN (Traditional PRI Trunk from VoIP > Gateway to say a DMS 250) >=20 > 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. >=20 > However, for AUDIO in step 2 above, is what I was looking for. >=20 > Is "G711" the consensus in step 2 above? >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, August 08, 2006 11:13 AM > To: 'Henning Schulzrinne'; 'Andrew Newton' > Cc: Karihaloo, Ujjval; ecrit@ietf.org > Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Brian >=20 > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Tuesday, August 08, 2006 12:40 PM > > To: Andrew Newton > > Cc: Brian Rosen; 'Karihaloo, Ujjval'; ecrit@ietf.org > > Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. > > > > 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 > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 14:04:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVwa-0001v7-HU; Tue, 08 Aug 2006 14:04:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVwY-0001tw-Sr for ecrit@ietf.org; Tue, 08 Aug 2006 14:04:42 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAVwX-0001D9-Lx for ecrit@ietf.org; Tue, 08 Aug 2006 14:04:42 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GAVwQ-0004I3-7n; Tue, 08 Aug 2006 13:04:34 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 14:04:37 -0400 Message-ID: <080201c6bb15$1e639d70$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7Ex16ZjBtSBRmR9i5lWtRcgl6fAAAcSgA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44D8CED4.3040807@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "'Karihaloo, Ujjval'" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org SBCs routinely prune codec lists in the SDP. An endpoint may offer it but that offer may not get to you. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, August 08, 2006 1:50 PM > To: Brian Rosen > Cc: 'Andrew Newton'; 'Karihaloo, Ujjval'; ecrit@ietf.org > Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. > > > > Brian Rosen wrote: > > 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, > > I don't know what you mean by "through the carrier". SDP negotiation is > end-to-end. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 14:06:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVyR-00034Z-Uq; Tue, 08 Aug 2006 14:06:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVyQ-00034S-BY for ecrit@ietf.org; Tue, 08 Aug 2006 14:06:38 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAVyO-0001XT-OY for ecrit@ietf.org; Tue, 08 Aug 2006 14:06:38 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GAVyC-0004TN-1N; Tue, 08 Aug 2006 13:06:24 -0500 From: "Brian Rosen" To: "'Karihaloo, Ujjval'" , "'Henning Schulzrinne'" , "'Andrew Newton'" Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 14:06:27 -0400 Message-ID: <080601c6bb15$5fda7ee0$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7CWYtwEcHMSjyTdKQhcIu7xmkWwAA1MsQAABnQRAAAKAYgAAAWyAgAAC2mhA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <99148FC6551C9641A4B1CDE206D895440DB256B1@idc1exc0004.corp.global.level3.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Existing systems use existing mechanisms. The work we are doing here is a single global standard, but it assumes that the PSAP also evolves. Nothing stops anyone from putting a gateway between what WE would conside to be the PSAP boundary and making it into something else. That gateway would have to transcode. Brian > -----Original Message----- > From: Karihaloo, Ujjval [mailto:Ujjval.Karihaloo@Level3.com] > Sent: Tuesday, August 08, 2006 1:46 PM > To: Brian Rosen; Henning Schulzrinne; Andrew Newton > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. > > 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). > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, August 08, 2006 11:36 AM > To: Karihaloo, Ujjval; 'Henning Schulzrinne'; 'Andrew Newton' > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. > > 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 > > > -----Original Message----- > > From: Karihaloo, Ujjval [mailto:Ujjval.Karihaloo@Level3.com] > > Sent: Tuesday, August 08, 2006 1:21 PM > > To: Brian Rosen; Henning Schulzrinne; Andrew Newton > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. > > > > 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? > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, August 08, 2006 11:13 AM > > To: 'Henning Schulzrinne'; 'Andrew Newton' > > Cc: Karihaloo, Ujjval; ecrit@ietf.org > > Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. > > > > 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 > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Tuesday, August 08, 2006 12:40 PM > > > To: Andrew Newton > > > Cc: Brian Rosen; 'Karihaloo, Ujjval'; ecrit@ietf.org > > > Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. > > > > > > 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 > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 14:07:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVyn-0003V9-Bv; Tue, 08 Aug 2006 14:07:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVym-0003SP-8x for ecrit@ietf.org; Tue, 08 Aug 2006 14:07:00 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAVyk-0001Ya-KM for ecrit@ietf.org; Tue, 08 Aug 2006 14:07:00 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 08 Aug 2006 11:06:57 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k78I6veH024962; Tue, 8 Aug 2006 11:06:57 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k78I6vVP023889; Tue, 8 Aug 2006 11:06:57 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 11:06:57 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.96.36]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 11:06:56 -0700 Message-Id: <4.3.2.7.2.20060808130542.02927578@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Aug 2006 13:06:55 -0500 To: "Karihaloo, Ujjval" , "Brian Rosen" , "Henning Schulzrinne" , "Andrew Newton" From: "James M. Polk" Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. In-Reply-To: <99148FC6551C9641A4B1CDE206D895440DB256B1@idc1exc0004.corp. global.level3.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Aug 2006 18:06:56.0911 (UTC) FILETIME=[6FAF61F0:01C6BB15] DKIM-Signature: a=rsa-sha1; q=dns; l=5779; t=1155060417; x=1155924417; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Ecrit]=20Audio=20Codecs=20for=20911=20CALLS.; X=v=3Dcisco.com=3B=20h=3DI80dhTFbN9LJpWYiFmBjB6VEZh0=3D; b=GtZIxQy6h4yGd4nlS7FOPuuRwUoKQK5SFOoRvCl3gAGQVD98QmVEEhpU9P2wu3jD1DBbWCxS 5U7uIeeg28Vw8c6/Scljgh2ZRxbYrm11ly0qfUyBKSQNa6ZufDWVTn3a; Authentication-Results: sj-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org 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). > >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net] >Sent: Tuesday, August 08, 2006 11:36 AM >To: Karihaloo, Ujjval; 'Henning Schulzrinne'; 'Andrew Newton' >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. > >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 > > > -----Original Message----- > > From: Karihaloo, Ujjval [mailto:Ujjval.Karihaloo@Level3.com] > > Sent: Tuesday, August 08, 2006 1:21 PM > > To: Brian Rosen; Henning Schulzrinne; Andrew Newton > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. > > > > 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? > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, August 08, 2006 11:13 AM > > To: 'Henning Schulzrinne'; 'Andrew Newton' > > Cc: Karihaloo, Ujjval; ecrit@ietf.org > > Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. > > > > 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 > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Tuesday, August 08, 2006 12:40 PM > > > To: Andrew Newton > > > Cc: Brian Rosen; 'Karihaloo, Ujjval'; ecrit@ietf.org > > > Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. > > > > > > 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 > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 14:18:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAW9v-0000Cm-CE; Tue, 08 Aug 2006 14:18:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAW9s-0000C8-6f for ecrit@ietf.org; Tue, 08 Aug 2006 14:18:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAW9s-0003SC-3e for ecrit@ietf.org; Tue, 08 Aug 2006 14:18:28 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAW9j-00028f-JE for ecrit@ietf.org; Tue, 08 Aug 2006 14:18:28 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k78II8Js018597; Tue, 8 Aug 2006 13:18:08 -0500 (CDT) Received: from ILEXC1U01.ndc.lucent.com ([135.3.39.6]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Aug 2006 13:18:07 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 13:18:06 -0500 Message-ID: <7A5EF92F6D86BD419418FFBD69E882B60187FE01@ILEXC1U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Audio Codecs for 911 CALLS. Thread-Index: Aca7CWYtwEcHMSjyTdKQhcIu7xmkWwAA1MsQAABnQRAAAKAYgAAAWyAgAAEijhA= From: "GOLDMAN, STUART O $STUART$" To: "Karihaloo, Ujjval" , "Brian Rosen" , "Henning Schulzrinne" , "Andrew Newton" X-OriginalArrivalTime: 08 Aug 2006 18:18:07.0802 (UTC) FILETIME=[FF9139A0:01C6BB16] X-Spam-Score: -2.6 (--) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org 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 sgoldman@lucent.com 602 493 8438 -----Original Message----- From: Karihaloo, Ujjval [mailto:Ujjval.Karihaloo@Level3.com]=20 Sent: Tuesday, August 08, 2006 10:46 AM To: Brian Rosen; Henning Schulzrinne; Andrew Newton Cc: ecrit@ietf.org Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. 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). -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, August 08, 2006 11:36 AM To: Karihaloo, Ujjval; 'Henning Schulzrinne'; 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. 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. =20 Brian > -----Original Message----- > From: Karihaloo, Ujjval [mailto:Ujjval.Karihaloo@Level3.com] > Sent: Tuesday, August 08, 2006 1:21 PM > To: Brian Rosen; Henning Schulzrinne; Andrew Newton > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. >=20 > For IP to PSTN call - >=20 > 1 2 3 > UA---> SBC-----> Voip Gateway ---> PSTN (Traditional PRI Trunk from VoIP > Gateway to say a DMS 250) >=20 > 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. >=20 > However, for AUDIO in step 2 above, is what I was looking for. >=20 > Is "G711" the consensus in step 2 above? >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, August 08, 2006 11:13 AM > To: 'Henning Schulzrinne'; 'Andrew Newton' > Cc: Karihaloo, Ujjval; ecrit@ietf.org > Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Brian >=20 > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Tuesday, August 08, 2006 12:40 PM > > To: Andrew Newton > > Cc: Brian Rosen; 'Karihaloo, Ujjval'; ecrit@ietf.org > > Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. > > > > 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 > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 14:26:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAWHG-0004mN-KS; Tue, 08 Aug 2006 14:26:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAWHF-0004mE-6y for ecrit@ietf.org; Tue, 08 Aug 2006 14:26:05 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAWHD-0004B6-Oq for ecrit@ietf.org; Tue, 08 Aug 2006 14:26:05 -0400 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k78IPvaK011189; Tue, 8 Aug 2006 18:25:57 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id ABC9C124816; Tue, 8 Aug 2006 18:25:56 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id 49FE3124802; Tue, 8 Aug 2006 18:25:56 +0000 (GMT) Received: from idc1exc0004.corp.global.level3.com ([10.1.9.15]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 12:25:56 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 12:25:55 -0600 Message-ID: <99148FC6551C9641A4B1CDE206D895440DB2572A@idc1exc0004.corp.global.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Audio Codecs for 911 CALLS. Thread-Index: Aca7FXgH/toKWckyQvGHmCY5fkOHZwAAiKZQ From: "Karihaloo, Ujjval" To: "James M. Polk" , "Brian Rosen" , "Henning Schulzrinne" , "Andrew Newton" X-OriginalArrivalTime: 08 Aug 2006 18:25:56.0014 (UTC) FILETIME=[16A4B4E0:01C6BB18] X-Spam-Score: 0.1 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org 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) -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: Tuesday, August 08, 2006 12:07 PM To: Karihaloo, Ujjval; Brian Rosen; Henning Schulzrinne; Andrew Newton Cc: ecrit@ietf.org Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. This WG is not discussing migration issues involving the PSTN, it is=20 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). > >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net] >Sent: Tuesday, August 08, 2006 11:36 AM >To: Karihaloo, Ujjval; 'Henning Schulzrinne'; 'Andrew Newton' >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. > >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 > > > -----Original Message----- > > From: Karihaloo, Ujjval [mailto:Ujjval.Karihaloo@Level3.com] > > Sent: Tuesday, August 08, 2006 1:21 PM > > To: Brian Rosen; Henning Schulzrinne; Andrew Newton > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. > > > > 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? > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, August 08, 2006 11:13 AM > > To: 'Henning Schulzrinne'; 'Andrew Newton' > > Cc: Karihaloo, Ujjval; ecrit@ietf.org > > Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. > > > > 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 > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Tuesday, August 08, 2006 12:40 PM > > > To: Andrew Newton > > > Cc: Brian Rosen; 'Karihaloo, Ujjval'; ecrit@ietf.org > > > Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. > > > > > > 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 > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 14:46:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAWb0-0007ab-44; Tue, 08 Aug 2006 14:46:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAWay-0007aT-Vc for ecrit@ietf.org; Tue, 08 Aug 2006 14:46:28 -0400 Received: from aismt08p.bellsouth.com ([139.76.165.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAWax-0005FL-HI for ecrit@ietf.org; Tue, 08 Aug 2006 14:46:28 -0400 Received: from ([90.152.53.183]) by aismt08p.bellsouth.com with SMTP id KP-AXPNC.155007242; Tue, 08 Aug 2006 14:46:03 -0400 Importance: normal Priority: normal Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01AL10015010163.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 8 Aug 2006 13:46:03 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 13:46:02 -0500 Message-ID: <9888E1AA13C3A1459D122996A58C0E1107CA35BD@bre2k61p-55> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Audio Codecs for 911 CALLS. thread-index: Aca7CYERQLCsZ2KfRzaBsGfIGnP55wACU07g From: "Stark, Barbara" To: "Henning Schulzrinne" , "Andrew Newton" X-OriginalArrivalTime: 08 Aug 2006 18:46:03.0285 (UTC) FILETIME=[E63BA450:01C6BB1A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: "Karihaloo, Ujjval" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org 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 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, August 08, 2006 12:40 PM > To: Andrew Newton > Cc: 'Karihaloo, Ujjval'; ecrit@ietf.org > Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. >=20 >=20 > Practically speaking, we're likely to have two classes of IP=20 > end systems: >=20 > (1) residential and enterprise, all of which speak G.711 mu-law today; >=20 > (2) 3GPP and 3GPP2, which all support AMR (although I'm not=20 > sure which=20 > of the set of codecs in the AMR family are mandatory to support) >=20 > Thus, I don't see this as particularly hard. I see no need to support=20 > A-law, unless somebody can show that there's a VoIP device out there=20 > that only speaks A-law. >=20 > Also, it is not necessarily true that G.711 is more resilient against=20 > packet loss than compressed codecs. >=20 > See http://www.globalipsound.com/datasheets/EG711.pdf for=20 > some comparisons. >=20 > Clearly, we're using compressed codecs (G.729 and GSM-FR, primarily,=20 > although I'm not sure what Sprint's CDMA network uses) today for=20 > emergency calls, given that roughly half originate from cell phones. >=20 > Henning >=20 > Andrew Newton wrote: > >=20 > > On Aug 8, 2006, at 9:18 AM, Brian Rosen wrote: > >> Do we not agree that forcing every PSAP to support every=20 > codec that every > >> carrier in its service area chooses makes no sense? I'm=20 > assuming we=20 > >> can't > >> just pick one ourselves and demand the carriers support that one,=20 > >> right :) > >=20 > > A lot of "nots" in the sentence. Yes, PSAPs ought to be=20 > encouraged to=20 > > support the codecs of the wireless carriers in the service area. > >=20 > >> Do we not agree that supporting compressed codecs other=20 > than the native > >> wireless codecs is a bad idea (they all do g.711 also)? > >=20 > > I really don't know about this. I believe Barbara has a point. > >=20 > > Also, I've been told that 3GPP2 has settled on a codec that MUST be=20 > > supported. > >=20 > > -andy > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 ***** 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 15:47:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXYJ-0001ld-3d; Tue, 08 Aug 2006 15:47:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXYI-0001lI-Am for ecrit@ietf.org; Tue, 08 Aug 2006 15:47:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAVxc-0001Qr-MH for ecrit@ietf.org; Tue, 08 Aug 2006 14:05:48 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAVil-0001lQ-CK for ecrit@ietf.org; Tue, 08 Aug 2006 13:50:28 -0400 Received: from lion.cs.columbia.edu (IDENT:Ru3fmGqdV50cTnLRx/yCoxZfgpnaRjf5@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k78HoIf7004224 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 8 Aug 2006 13:50:18 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k78HoHrh018812 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Aug 2006 13:50:17 -0400 Message-ID: <44D8CED4.3040807@cs.columbia.edu> Date: Tue, 08 Aug 2006 13:50:12 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. References: <07e601c6bb0d$fb3a0390$9de6a8c0@cis.neustar.com> In-Reply-To: <07e601c6bb0d$fb3a0390$9de6a8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.8.102932 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0, __cbl.abuseat.org_TIMEOUT ' X-Spam-Score: -2.4 (--) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: "'Karihaloo, Ujjval'" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > 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, I don't know what you mean by "through the carrier". SDP negotiation is end-to-end. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 08 19:01:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAaZL-0005Ag-Lj; Tue, 08 Aug 2006 19:01:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAaZL-0005Ab-0B for ecrit@ietf.org; Tue, 08 Aug 2006 19:01:03 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAaZI-0007ro-Os for ecrit@ietf.org; Tue, 08 Aug 2006 19:01:02 -0400 Received: from [10.0.1.50] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 08 Aug 2006 19:01:05 -0400 id 0158810A.44D917B1.000040A8 In-Reply-To: <44D8BE7A.20103@cs.columbia.edu> References: <07a501c6baed$269f2fe0$9de6a8c0@cis.neustar.com> <3C0ED4EB-6D15-48B3-BC92-6497A9738F16@hxr.us> <44D8BE7A.20103@cs.columbia.edu> Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: [Ecrit] Audio Codecs for 911 CALLS. Date: Tue, 8 Aug 2006 19:00:55 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1365211764==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1365211764== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-16554-1155078066-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-16554-1155078066-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Aug 8, 2006, at 12:40 PM, Henning Schulzrinne wrote: > (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) Well, we shouldn't really guess about this. Perhaps the co-chairs can make an official inquiry via the IETF 3GPP and 3GPP2 liaisons. -andy --=_zeke.ecotroph.net-16554-1155078066-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.0

On Aug 8, 2006, at 12:4= 0 PM, Henning Schulzrinne wrote:

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

Well, we shouldn't really guess about this.=A0= Perhaps the co-chairs can make an official inquiry via the IETF 3GPP and= 3GPP2 liaisons.

-andy=A0