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

From: Brian Rosen <[email-masked]>
Date: Wed, 2 Mar 2011 16:45:35 -0500

Folks, we need to decide what to do about codecs, as discussed below.

I believe we have been over this, and the only thing that made sense was to require G.711 as the common codec.

I'm still comfortable with that, and propose to leave the text as is.

Brian

On Feb 22, 2011, at 1:17 PM, Brian Rosen wrote:

> Thank you for this review.  It shows once again what a brand new set of eyes can do for  document.  My thanks, again, to all the GenART reviewers and the system.
> 
> See inline for my responses
> 
> On Feb 20, 2011, at 9:34 AM, Miguel A. Garcia wrote:
> 
>> I have been selected as the General Area Review Team (Gen-ART)
>> reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>> 
>> Please resolve these comments along with any other comments you may receive.
>> 
>> Document: draft-ietf-ecrit-phonebcp-16.txt
>> Reviewer: Miguel Garcia <[email-masked]>
>> Review Date: 2011-02-20
>> IETF LC End Date: 2011-02-21
>> 
>> Summary: This draft is on the right track but has open issues, described in the review.
>> 
>> Major issues: None
>> 
>> Minor issues:
>> 
>> - I don't understand the last sentence in Section 6.2.1, which reads:
>> 
>>  Where a civic form of location is provided, all
>>  fields in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be
>>  specified.
>> 
>> what I don't understand is the meaning of "MUST be able to be specified". And I don't understand if this is a requirement for the service provider, for the access network, or for the end device. Can you explain what is the intention of the sentence?
> The notion is that the location configuration protocol may generate a PIDF that contains any of the elements defined in 4119/5139.  All downstream elements must pass all fields.  It applies to all the entities.  Any suggestions for rewording to make this more clear would be appreciated.
> 
> 
> 
>> 
>> 
>> 
>> - Section 6.5, second paragraph (req. AN-13/INT-14). I have a problem with the sentence that reads:
>> 
>>  If the access network supports more than one location
>>  configuration protocol, all such protocols MUST return the same
>>  location, within the constraints of the protocols deployed.
>> 
>> I don't understand how this requirement can be achieved. Assume that an access network supports several location configuration protocols, which are able to determine the location by different means. Ideally all protocols should return the same location, but in practice, it will be difficult, due to the different accuracy and confidence among the various protocols. Additionally, I believe there is nothing the access network administrator can do to make sure that all location protocols will return the same location for a given device.
>> 
>> Conclusion: I consider this sentence to be a hope rather than a requirement. Perhaps it can be rephrased saying that ".... it is expected that all such protocols will return the same location ....".
> This is a PROTOCOL issue and not a location determination issue.  Think of the protocol as being a transport mechanism for the location.  Each transport must return the same location.  This is saying if you have more than one protocol and more than one location determination mechanism, all protocols must return the same location
> 
> 
>> 
>> 
>> 
>> - Section 6.5., requirement AN-15/INT-17. It seems that this requirement is duplicated from the second sentence of requirements AN-13/INT-14 (see my previous comment). So, there should be only one requirement with the same text, and my previous comment should apply.
> Yes, that is a problem.  I propose to delete the sentence in the prior section, and leave this one.
> 
>> 
>> 
>> 
>> - Section 7, Requirement ED-51. I think this requirement also applies to the Service Provider (at least the configuration part of it), so it should get an SP number as well.
> Yeah, I see the problem.  It might be easier to just delete the sentence, but I could add an AN requirement.  Anyone else have an opinion?
> 
>> 
>> 
>> 
>> - Section 9.2, first bullet point. The text reads:
>> 
>>                                                                    If
>>       the device cannot interpret local dial strings, the Request-URI
>>       SHOULD be a dial string URI [RFC4967] with the dialed digits.
>> 
>> I don't understand how this requirement can be enforced. If someone has not read this document and has not implemented local dial strings, how can you put a requirement around dial string URIs to that person who has not implemented dial string URIs and possibly not read your draft?
> If the device implementer didn't read the document, then it wouldn't conform to this document.  If they did, then they should use dial strings.  The device generates this, it doesn't get it from other entity.  I don't understand the problem.
> 
> 
>> 
>> Perhaps you can say that "it is expected that ...", but not placing a formal requirement.
>> 
>> This comment also applies to bullet point 2 in the same Section 9.2, regarding the To header field.
> Same response.
> 
>> 
>> 
>> 
>> - Section 9.2, bullet point 10. The text reads:
>> 
>>       A SDP offer SHOULD be included in the INVITE.  If voice is
>>       supported the offer MUST include the G.711 codec, see
>>       Section 14.
>> 
>> Honestly, this is an unrealistic requirement. G.711 is well known for its bandwidth consumption. Due to this, as far as I know, there is no cellular network in the world that support or uses G.711 either in circuit-switched or VoIP. I don't think this draft is going to change the current status quo. Actually, none has ever got to standardize a single codec for an application. Due to this, protocols like SIP/SDP support an codec negotiation mechanism in the format of the SDP offer answer.
>> 
>> Other considerations:
>> 
>> The requirement is nod needed, because in the absence of it, SDP offer answer will get to negotiate to a single codec for the emergency call.
>> 
>> This requirement falls into the category of national or supranational regulation. There will be organisms which will dictate minimum or recommended support in terms of codecs, and this regulation will be above the requirements in this document.
>> 
>> My recommendation is to delete this requirement.
>> 
>> I also noticed that this requirement is also repeated in Section 14, Requirement AD-73. The recommendation is also to delete such requirement.
>> 
>> Also, req ED-77 in Section 14 tries to do the same with a video codec. The recommendation is still the same.
> This has been discussed before.  The goal is to be able to have any device, anywhere, be able to complete an emergency call.  To make that work, you have to have at least one common codec.  It's not something a local regulation could fix: when you get off a plane, your softclient on your VoIP service provider, must be able to complete an emergency call where you are.
> 
> The alternative is to have the document have a requirement on PSAPs to implement a relatively long list of codecs, and then have each device implement at least one of those.  That would be quite difficult to make such a list, and even if you did, some service would have a problem.
> 
> 
>> 
>> 
>> 
>> - Section 12, the text reads:
>> 
>>  Dropping of the old call MUST only
>>  occur if the user is attempting to hang up
>> 
>> But the previous sentence says:
>> 
>>  If in the interval, an incoming call is received from
>>  the domain of the PSAP, the device MUST drop the old call and alert
>>  for the (new) incoming call.
>> 
>> So, we have two scenarios for dropping an old call:
>> 1) the user is attempting to hung up
>> 2) an incoming call is received from the PSAP
>> 
>> Therefore, I disagree with the "MUST only occur" of the first sentence. Please rephrase the text to avoid contradictions.
> Is see your point.  In SIP, hang up requires the complete BYE transaction, and you can be in the middle of that transaction when the new call arrives.  The problem is the word "drop".  What we are attempting to say is that even though you are in the middle of that transaction, you have to abandon it, and accept the new call.  So I need a better word for "drop".
> 
>> 
>> 
>> 
>> 
>> 
>> Nits:
>> 
>> - Expands acronyms at first occurrence. This includes: PSAP, PIDF, PIDF-LO, HELD, LCP, and LoST.
> the terminology sections says:
> This document uses terms from [RFC3261], [RFC5012] and [I-D.ietf-ecrit-framework].
> 
> I thought that would be enough.  I can expand the acronyms here.
> 
>> 
>> - Section 9.2, first bullet point
>> s/tree, If/tree. If
>> 
>> - Section 9.2, second bullet point
>> s/not find a a Router/not find a Router
>> 
>> - Section 11
>> s/and the Referred-by: header/and the Referred-by header
> Thanks, I'll fix these
> 
> 
>> 
>> 
>> BR,
>> 
>>    Miguel
>> 
>> 
>> 
>> -- 
>> Miguel A. Garcia
>> +34-91-339-3608
>> Ericsson Spain
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Mar 2011 15:15:57 -0800

It seems to me that the requirements could be different on the PSAP side
(which could be expected to support more codecs) than on the handset.  For
example, the requirements for the PSAP could be support of codecs A, B AND
C.  

It is already suggested in Section 9.2 that "PSAPs may support a wide range
of media types  and codecs".   This is just a "may", not even a "MAY".   Yet
in ED-73 it is suggested that " It is desirable to include wideband codecs
such as AMR-WB in the offer."  What is the point of doing that if there is
not even a recommendation  that the PSAP support a wideband codec?  That
raises the question of whether it would make sense to require the PSAP to
implement at least one codec widely implemented on mobile devices. 

In terms of the handset requirements generated by whatever is decided on the
PSAP, it would make sense for the handset to have to implement at least one
of the MANDATORY to implement PSAP codecs.   If it turns out that the PSAP
is only mandated to support G.711, but recommended to do others, then you'd
have to mandate G.711 on the handset.   But if there are multiple
mandatory-to-implement codecs on the PSAP side, then the handset should only
have to implement one of them. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Wednesday, March 02, 2011 1:46 PM
To: Brian Rosen
Cc: ecrit Org
Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt

I believe we have been over this, and the only thing that made sense was to
require G.711 as the common codec.

Brian

On Feb 22, 2011, at 1:17 PM, Brian Rosen wrote:

> Thank you for this review.  It shows once again what a brand new set of
eyes can do for  document.  My thanks, again, to all the GenART reviewers
and the system.
>> reviewer for this draft. For background on Gen-ART, please see the 
>> FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>> 
>> Reviewer: Miguel Garcia <[email-masked]> Review Date: 
>> 2011-02-20 IETF LC End Date: 2011-02-21
>> 
>>  Where a civic form of location is provided, all  fields in the 
>> PIDF-LO [RFC4119] and [RFC5139] MUST be able to be  specified.
>> 
>> what I don't understand is the meaning of "MUST be able to be specified".
And I don't understand if this is a requirement for the service provider,
for the access network, or for the end device. Can you explain what is the
intention of the sentence?
> The notion is that the location configuration protocol may generate a PIDF
that contains any of the elements defined in 4119/5139.  All downstream
elements must pass all fields.  It applies to all the entities.  Any
suggestions for rewording to make this more clear would be appreciated.
>>  If the access network supports more than one location  configuration 
>> protocol, all such protocols MUST return the same  location, within 
>> the constraints of the protocols deployed.
>> 
>> I don't understand how this requirement can be achieved. Assume that an
access network supports several location configuration protocols, which are
able to determine the location by different means. Ideally all protocols
should return the same location, but in practice, it will be difficult, due
to the different accuracy and confidence among the various protocols.
Additionally, I believe there is nothing the access network administrator
can do to make sure that all location protocols will return the same
location for a given device.
>> 
>> Conclusion: I consider this sentence to be a hope rather than a
requirement. Perhaps it can be rephrased saying that ".... it is expected
that all such protocols will return the same location ....".
> This is a PROTOCOL issue and not a location determination issue.  
> Think of the protocol as being a transport mechanism for the location.  
> Each transport must return the same location.  This is saying if you 
> have more than one protocol and more than one location determination 
> mechanism, all protocols must return the same location
> 
> 
>> 
>> 
>> 
>> - Section 6.5., requirement AN-15/INT-17. It seems that this requirement
is duplicated from the second sentence of requirements AN-13/INT-14 (see my
previous comment). So, there should be only one requirement with the same
text, and my previous comment should apply.
>> - Section 7, Requirement ED-51. I think this requirement also applies to
the Service Provider (at least the configuration part of it), so it should
get an SP number as well.
> Yeah, I see the problem.  It might be easier to just delete the sentence,
but I could add an AN requirement.  Anyone else have an opinion?
>> I don't understand how this requirement can be enforced. If someone has
not read this document and has not implemented local dial strings, how can
you put a requirement around dial string URIs to that person who has not
implemented dial string URIs and possibly not read your draft?
> If the device implementer didn't read the document, then it wouldn't
conform to this document.  If they did, then they should use dial strings.
The device generates this, it doesn't get it from other entity.  I don't
understand the problem.
>> Honestly, this is an unrealistic requirement. G.711 is well known for its
bandwidth consumption. Due to this, as far as I know, there is no cellular
network in the world that support or uses G.711 either in circuit-switched
or VoIP. I don't think this draft is going to change the current status quo.
Actually, none has ever got to standardize a single codec for an
application. Due to this, protocols like SIP/SDP support an codec
negotiation mechanism in the format of the SDP offer answer.
>> 
>> Other considerations:
>> 
>> The requirement is nod needed, because in the absence of it, SDP offer
answer will get to negotiate to a single codec for the emergency call.
>> 
>> This requirement falls into the category of national or supranational
regulation. There will be organisms which will dictate minimum or
recommended support in terms of codecs, and this regulation will be above
the requirements in this document.
>> I also noticed that this requirement is also repeated in Section 14,
Requirement AD-73. The recommendation is also to delete such requirement.
> This has been discussed before.  The goal is to be able to have any
device, anywhere, be able to complete an emergency call.  To make that work,
you have to have at least one common codec.  It's not something a local
regulation could fix: when you get off a plane, your softclient on your VoIP
service provider, must be able to complete an emergency call where you are.
> 
> The alternative is to have the document have a requirement on PSAPs to
implement a relatively long list of codecs, and then have each device
implement at least one of those.  That would be quite difficult to make such
a list, and even if you did, some service would have a problem.
>>  If in the interval, an incoming call is received from  the domain of 
>> the PSAP, the device MUST drop the old call and alert  for the (new) 
>> incoming call.
>> 
>> Therefore, I disagree with the "MUST only occur" of the first sentence.
Please rephrase the text to avoid contradictions.
> Is see your point.  In SIP, hang up requires the complete BYE transaction,
and you can be in the middle of that transaction when the new call arrives.
The problem is the word "drop".  What we are attempting to say is that even
though you are in the middle of that transaction, you have to abandon it,
and accept the new call.  So I need a better word for "drop".

---

From: Brian Rosen <[email-masked]>
Date: Wed, 2 Mar 2011 19:17:49 -0500

The problem is agreeing on which ones

Although you could pick AMR, what do you do about other systems?  Is it reasonable to expect all devices to implement 711 or AMR? Hardly.
How many codecs must a PSAP implement?  2 is reasonable.  Is 6, 8?

This was the discussion we had before.

Brian

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 2 Mar 2011 20:02:00 -0500

Do you have a pointer to the prior discussion?
--Richard

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 03 Mar 2011 06:28:03 +0100

The solution can be to label the codec points ED-x/SP-x meaning that it 
is the service providers responsibility to make sure that transcoding is 
made if there is no codec match between what the PSAP has in reality and 
what the endpoint has in reality.

Thus the Service provider takes part in the ED tasks when needed.

The same is valid if the user device is not at all a SIP device, but 
need to be able to make IP based emergency calls. Then, the service 
provider needs to be the conversion point for whatever protocol and 
media coding you have between the service provider and the terminal.

This can be done in the document in two alternative ways:

1. Change the explanation of ED to mean functions provided by the  End 
Device and Service Provider together in a way decided by the service 
provider.

2. Use ED/SP labels on the requirements that must be handled in this 
combined way to guarantee functionality.

It would of course be good also to have a very short list of alternative 
codecs here so that the service provider can know that it does not need 
to activate transcoding in most cases, e.g. mobile.

/Gunnar Hellström

Richard L. Barnes skrev 2011-03-03 02:02:
>>>>> FAQ at<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>>>>>
>>>>> Reviewer: Miguel Garcia<[email-masked]>  Review Date:

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 3 Mar 2011 13:13:07 +0100

PSAPs all support G.711 at the moment essentially. There are PSAPs out there that will support this and only this. It is also the common denominator of what everything else will convert to. So while GSM uses AMR, it provides gateways to the circuit switched world that will convert this to G.711.

So I guess UEs not supported by any other infrastructure must support G.711. They can support other codecs and not G.711 if they belong to a known infrastructure where that infrastructure will do the conversion.

Any other codecs have to be an optional extra with no guarantee of support.

Regards

Keith

> Sent: 03 March 2011 00:18
> To: Bernard Aboba
> Cc: 'ecrit Org'
> Although you could pick AMR, what do you do about other systems?  Is it
> reasonable to expect all devices to implement 711 or AMR? Hardly.
> >>> Summary: This draft is on the right track but has open issues,
> described
> > in the review.
> >>>
> >>> Major issues: None
> >>>
> >>> Minor issues:
> >>>

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 03 Mar 2011 13:38:52 +0100

Yes, you can do the conversion in the infrastructure, but the 
requirement is marked by ED-73 in the draft.
ED means "end devices and applications (requirements prefaced by "ED-")"

So, in order to allow the infrastructure to do the conversion, the 
classification of this requirement could be changed to ED/SP.

/Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 03 Mar 2011 13:39:00 +0100

/Gunnar

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 3 Mar 2011 08:42:59 -0500

Since these types of documents are often used for RFPs, national regulations and other requirement documents, would it make sense to create a list of "recommended" codecs? While it does not ensure that both sides can negotiate anything other than G.711, it greatly increases the likelihood. Thus, we could say something like

"It is RECOMMENDED that the PSAP supports AMR-WB, G.722, G.729."

I suspect that identifying this larger set wouldn't be that hard. From a quick look at phone specs, lists like

G.722, G.723, G.726, G.729 a/b, GSM, G.711 (snom)
G.722, G.723, G.726, G.729 a/b, GSM, iLBC, G.711 (Grandstream)
G.722, G.729 a/b, G.711 u/a law (Polycom)
G.722, G.726, G.729 a/b, G.711 u/a law (Cisco)

are common. There's a pattern here...

Thus, by looking at the support in commodity PBX phones today, we should be able to come up with a reasonable set that is likely going to be easily commercially available. This would also set a process in motion - a few years later, we might then be able to promote a non-G.711 codec to a required status.

---

From: Marc Linsner <[email-masked]>
Date: Thu, 03 Mar 2011 08:58:28 -0500

I agree with the sentiment of Keith's message, G.711 should be the only
MUST support codec.

Since 80%+ of the PSAPs (in the US) are still analog, I wouldn't use the
justification that all PSAPs essentially support G.711.

It is reasonable to justify G.711 by stating that it's the most common
codec used in 'local' wireline telephony networks, where the PSAPs
currently live.

-Marc-

-----Original Message-----
From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 3 Mar 2011 13:13:07 +0100
To: Brian Rosen <[email-masked]>, Bernard Aboba
<[email-masked]>
Cc: 'ecrit Org' <[email-masked]>
Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt

>PSAPs all support G.711 at the moment essentially. There are PSAPs out
>there that will support this and only this. It is also the common
>denominator of what everything else will convert to. So while GSM uses
>AMR, it provides gateways to the circuit switched world that will convert
>this to G.711.
>
>So I guess UEs not supported by any other infrastructure must support
>G.711. They can support other codecs and not G.711 if they belong to a
>known infrastructure where that infrastructure will do the conversion.
>
>> > such as AMR-WB in the offer."  What is the point of doing that if
>>there
>> is
>> > In terms of the handset requirements generated by whatever is decided
>>on
>> the
>> > PSAP, it would make sense for the handset to have to implement at
>>least
>> one
>> > mandatory-to-implement codecs on the PSAP side, then the handset
>>should
>> only
>> > I believe we have been over this, and the only thing that made sense
>>was
>> to
>> >>> - Section 6.5, second paragraph (req. AN-13/INT-14). I have a
>>problem
>> > with the sentence that reads:
>> >>>
>> > access network supports several location configuration protocols,
>>which
>> are
>> > should return the same location, but in practice, it will be
>>difficult,
>> due
>> > is duplicated from the second sentence of requirements AN-13/INT-14
>>(see
>> my
>> >> Yes, that is a problem.  I propose to delete the sentence in the
>>prior
>> > section, and leave this one.
>> >>
>> >>>
>> >>>
>> >>>
>> >>> - Section 7, Requirement ED-51. I think this requirement also
>>applies
>> to
>> >>> Perhaps you can say that "it is expected that ...", but not placing
>>a
>> > formal requirement.
>> >>>
>> >>> Honestly, this is an unrealistic requirement. G.711 is well known
>>for
>> its
>> > or VoIP. I don't think this draft is going to change the current
>>status
>> quo.
>> >>> Also, req ED-77 in Section 14 tries to do the same with a video
>>codec.
>> > The recommendation is still the same.
>> > regulation could fix: when you get off a plane, your softclient on
>>your
>> VoIP
>> > implement at least one of those.  That would be quite difficult to
>>make
>> such

---

From: Brian Rosen <[email-masked]>
Date: Thu, 3 Mar 2011 09:34:08 -0500

The comment that started this thread was discussing mobile phones.  All PBX phones support G.711.  Most current mobile phones don't.  

I don't have a problem with a recommended set of codecs if that is 3-5 codecs.  I have a problem if it's 10-15.

I would actually like a few of those to be wide band.  Wide band is really a good thing for emergency calls.  OTOH, not all mobile phones support any WB codecs.  

We are the IETF, we are talking about newer systems, and we are talking about things that require upgrades (or new features) in phones.  Worrying about not having enough bandwidth for G.711 seems to me to be an old problem, not a current or new problem.  If we could get away with it, I'd make the codec the new IETF codec and require wideband modes.  That is unrealistic, of course.

Brian

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 03 Mar 2011 21:35:46 +0100

This discussion has made it clear that some change is needed to allow 
service providers with non-SIP devices to enable their device users to 
call emergency services. And also service providers with devices using 
new kinds of codecs not supported by PSAPs.

For both cases, the easiest way seems me to be to insert three 
definitions in the Framework draft. Phonebcp refers to Framework for terms.

The terms in need of definition are End Device, Endpoint and Application.

I suggest the following inserts in Chapter 1, Terminology, of 
draft-ietf-ecrit-framework

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

Application: Software functions performing the tasks related to the End 
Device so that the Endpoint can perform the protocols, functions and 
media codings required in this Framework. An Application may be 
distributed among the End Device and various nodes in the Service 
Provider's Infrastructure.

End Device: Physical device on the user side where the emergency call is 
handled.

Endpoint: The entity representing the user where the protocols excpected 
to be performed by End Devices and Applications are handled. This may in 
reality be implemented at different points for different functions. If a 
Service Provider has SIP terminals capable of the same media as the 
PSAP, the Endpoint is in the user terminal. If a Service Provider has 
non-SIP devices, the Endpoint for call control and media may be in a 
gateway in the Service Provider's infrastructure etc.

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

By this little change we enable for example the whole current and future 
Mobile networks to use the emergency services specified by the Framework 
and Phonebcp specifications. We also enable Service Providers using 
other call control protocols than SIP to use emergency services.

Without these changes, the application of the ecrit specifications 
remain very limited to native SIP terminals, implementing exactly the 
same codecs as listed in Phonebcp.

Gunnar
_____________________________________________

Gunnar Hellström
Omnitor
[email-masked]
+46708204288

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 03 Mar 2011 21:57:39 +0100

When deciding on the audio codec list, it is relevant to check if other 
bodies do similar lists of mandatory codecs. Harmonization is of course 
of value.

It is then interesting to note that the current proposal for mandatory 
audio codec for public procurements and telecom devices in USA is G.722.
This is because of the better characteristics for users with hearing 
impairments of wide-band codecs over the old telephone quality codecs.

This is stated in the proposal from the US Access Board for refresh of 
US Acts Sections 508 and 255.

See
http://www.access-board.gov/sec508/refresh/draft-rule.htm
"906 Audio Clarity for Interconnected VoIP"

On the other hand, this is not decided, and it is just one country, so 
it may not be what we need to dictate in Phonebcp.

Tricky. It may be a disaster for a person with hearing impairment to 
have G.722 or AMR-WB audio quality in all every-day calls, but suddenly 
limited to G.711 quality in the Emergency call.

This is also a question for the Framework specification.

Gunnar

___________________________________________________
Gunnar Hellström
Omnitor
[email-masked]
+46708204288

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 3 Mar 2011 22:28:45 -0500

Since the PSAP phones won't (likely) be mobile, non-support for specific codecs seems less of an issue, except that mobile phones won't give you the better quality. But many of the applications where this matters, e.g., to support callers with disabilities, aren't necessarily mobile. And transcoding AMR-WB into G.722 is certainly better than transcoding it into G.711.

From what I can tell from my quick survey of commodity PBX phones, there does appear to be a list of 3-5 codecs that would cover a pretty broad spectrum, for example, G.722 + G.729a/b + G.711. Even G.722 + G.711 wouldn't be bad; since neither codec is patent-encumbered, the incremental cost should be essentially zero. There is no reason we can't revisit the list in a few years. Even if we add a new recommended codec every 5 years and never retire one, this will hardly be a major complexity driver, given that the older codecs will be relatively lightweight compared to the newer ones.

Is there any downside to specifying G.711 MUST, G.722 SHOULD, for example?

Henning

---

From: Brian Rosen <[email-masked]>
Date: Sat, 5 Mar 2011 10:24:51 -0500

Nope, no downside.  I can do that.

Doesn't handle the problem that started this: mobile phones don't do G.711 or G.722

Brian

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 05 Mar 2011 16:58:54 +0100

An indication that transcoding is acceptable is also needed. Right now 
the codec requirement ED-73 is on the End Device.
Solution: Either change to ED-73/SP-41  or change the definition of ED- 
to include a possilbe transcoder or gateway.

Still does not handle the initial problem neatly.

/Gunnar

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 5 Mar 2011 11:48:03 -0500

There's nothing we can do about this problem, particularly given that there doesn't appear to be a universal codec for mobile devices. Also, I suspect that all mobile calls *today* show up as G.711 by the time they reach the ESInet, since they go through a circuit-to-packet conversion. Once we have VoIP-over-LTE, it might be appropriate to add the most common wideband codec for that configuration to the SHOULD list. There doesn't seem to be as much point in adding narrowband codecs, since the conversion to G.711 is cheap and no quality would be lost in translation.

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 06 Mar 2011 00:37:52 -0600

I agree with Henning here. We really cannot really control or 
reliably expect that within the existing SW upgradeable 
"interworking" products that we can mandate a codec.

That said, Gunnar is also right, this shouldn't be only an "ED" requirement.

Along those lines, I think this requirement, while well intentioned, 
falls into the gap between IP and circuit, in which we can't 
truthfully say that we "know" this only applies to the IP part - at 
least not without rewording to limit this.

Something needs to state definitively that when the media gets to the 
ESRP - via mobile or wired - it needs to be in either the G.711 or 
G.722 codec for interoperability sake. That means the cellco mobile 
devices can use whatever codec they want, as long as the cellco 
converts to 711 or 722 once the media is transcoded to RTP.

I'm not sure we have a requirement that say exactly that, and I think 
we should for this situation.

James

At 10:48 AM 3/5/2011, Henning Schulzrinne wrote:
>There's nothing we can do about this problem, particularly given 
>that there doesn't appear to be a universal codec for mobile 
>devices. Also, I suspect that all mobile calls *today* show up as 
>G.711 by the time they reach the ESInet, since they go through a 
>circuit-to-packet conversion. Once we have VoIP-over-LTE, it might 
>be appropriate to add the most common wideband codec for that 
>configuration to the SHOULD list. There doesn't seem to be as much 
>point in adding narrowband codecs, since the conversion to G.711 is 
>cheap and no quality would be lost in translation.
>
>Henning
>

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 06 Mar 2011 08:38:48 +0100

We should explicitly say that we expect that the reader shall understand 
the specification freely and for example be fre to apply the media 
requirement in a Media Gateway instead of the endpoint.

Can the solution be to include the following in the introduction:

"This specification describes a conceptual interface to the PSAP 
distributed among devices and network components. Service providers who 
cannot distribute the tasks as specified here shall make sure that their 
services comply at the interface to the PSAP."

The Framework draft has a sentence in that direction where it talks 
about other signaling protocols. So it is natural to include something 
similar in Phonebcp.

Or, if we focus on media, under 14. Media add:
"The following requirements for media shall be met at the interface to 
the PSAP. If they are not handled directly by the end device, conversion 
must be possible to take place in the service provider's network."

Note "possible". It must still be OK to offer AMR-WB and find that the 
PSAP luckily supports it, so we do not need to invoke transcoding to G.722.

Gunnar

James M. Polk skrev 2011-03-06 07:37:
> I agree with Henning here. We really cannot really control or reliably 
> expect that within the existing SW upgradeable "interworking" products 
> that we can mandate a codec.
>
>> There's nothing we can do about this problem, particularly given that 
>> there doesn't appear to be a universal codec for mobile devices. 
>> Also, I suspect that all mobile calls *today* show up as G.711 by the 
>> time they reach the ESInet, since they go through a circuit-to-packet 
>> conversion. Once we have VoIP-over-LTE, it might be appropriate to 
>> add the most common wideband codec for that configuration to the 
>> SHOULD list. There doesn't seem to be as much point in adding 
>> narrowband codecs, since the conversion to G.711 is cheap and no 
>> quality would be lost in translation.
>>
>> Henning
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 6 Mar 2011 10:16:19 -0500

On Mar 6, 2011, at 2:38 AM, Gunnar Hellström wrote:
> 
> 
> Note "possible". It must still be OK to offer AMR-WB and find that the PSAP luckily supports it, so we do not need to invoke transcoding to G.722.

Definitely. The goal of having a mandatory codec list is to prevent negotiation failure, not to preempt or prevent negotiation. The goal of the SHOULD list is to increase the chance of negotiation success at the highest possible quality level.

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 8 Mar 2011 11:34:42 +0800

I agree with this.

I'll go out on a limb and confess I don't understand why the point of (circuit service) mobile codecs came up anyway. These are air interface codecs and they will have been transcoded by the time the traffic hits the circuits in the core network anyway. I'm struggling to see why they are pertinent to the spec at all.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of James M. Polk
Sent: Sunday, 6 March 2011 5:38 PM
To: Henning Schulzrinne; Brian Rosen
Cc: DRAGE, Keith (Keith); 'ecrit Org'
Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt

James

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 08 Mar 2011 10:59:58 +0100

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

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

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

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

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

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

Something similar should be done for chapter 14.

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

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

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

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

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

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

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

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

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

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

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

/Gunnar

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 9 Mar 2011 17:12:05 +0100

The applicability of this document to most mobile phone networks is tenuous anyway. 

For Voip, 3GPP and 3GPP2 based networks have a defined manner of supporting emergency calls covered by 3GPP common IMS specifications, backed up by use of the existing CS network where such exists. 

As far as the 3GPP and 3GPP2 operators are concerned the 3GPP specifications meet their obligations to the regulators, and the phones wishing to use those capabilities have to correspond to the 3GPP specifications.

Those specifications correspond to phone BCP only where they are trying to address a common requirement. Key things they will not do is use of Lost and Lost servers, endpoint location validation, no encryption of location, as this is protected by trust domains, no direct calling of the PSAP from the end device - recognition instead by intermediate SIP entities, etc.

If as an end user you choose to ignore those provisions for support of emergency calls in 3GPP and 3GPP2 networks, and make the call using an IP connection to some other service provider, then that is your look out. It imposes no obligations on the 3GPP or 3GPP2 service provider.

Now there were comments prior to this to write some of this into the document. As far as I am concerned those comments are still open.

Regards

Keith

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: 08 March 2011 03:35
> To: James M. Polk; Henning Schulzrinne; Brian Rosen
> Subject: RE: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt
> 
> I agree with this.
> 
> I'll go out on a limb and confess I don't understand why the point of
> (circuit service) mobile codecs came up anyway. These are air interface
> codecs and they will have been transcoded by the time the traffic hits the
> circuits in the core network anyway. I'm struggling to see why they are
> pertinent to the spec at all.
> 
> Cheers,
> Martin
> 
> James M. Polk

---

From: Brian Rosen <[email-masked]>
Date: Wed, 9 Mar 2011 11:23:36 -0500

This is a BCP for Internet connected devices, service providers and access networks.  There are no protocol police.  

I woud point out that a 3GPP service provider may be an access network (raw packet service).

Please send text.

Brian

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 11 Mar 2011 13:48:16 +0800

Given this is going off-topic with respect to the original thread, I'll pick up Keith's point with a new subject title.

There's a meme going around that IMS emergency calling, specified in the stage 2 3GPP TS 23.167, is somehow a mutually exclusive alternative or inconsistent architecture with ECRIT and phone BCP.

I don't think that's true at all.

It should be self evident that, like any other solution, IMS needs to address the functions of location determination and call routing. And, indeed, these functions are covered in 23.167 and are attributed to the "LRF" (Location Retrieval Function) network element. The spec decomposes the LRF into the logical functions of "LS" and "RDF" ("Location Server" and "Route Determination Function"). Most aspects of the operation of the LS and RDF are left out of scope or considered implementation dependent - which is fair enough.

ECRIT isn't ruled out. There is a quite practical, IMS consistent, deployment of the LRF that uses LoST as the implementation for the RDF and HELD for the LS function. This should not be any surprise since IMS is much like an over the top VoIP service with the simplification that all the elements can be in the same trust domain (though I find IMS specifications to be curiously silent of the use case of a subscriber initiating a call from a completely third party IP-CAN such as a residential WiFi access). It's also attractive in that it's consistent with respect to the principle of IMS being based on IETF specifications as opposed to inventing 3GPP-specific mechanisms.

The real value to the network/IMS operator of course is that an implementation that used LoST and HELD as described above would also support the more general use cases that Keith rules out below - while obviating the need to resort to pseudo-legalistic arguments to justify the limited scope of IMS. It would also facilitate the use case mentioned above assuming the broadband provider behind the residential WiFi connection also had a consistent implementation. It's all good.

Cheers,
Martin

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Thursday, 10 March 2011 3:12 AM
To: Dawson, Martin; James M. Polk; Henning Schulzrinne; Brian Rosen
Cc: 'ecrit Org'
Subject: RE: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt

Regards

Keith

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 11 Mar 2011 07:27:33 +0100

A consequence of this discussion is that next task for Ecrit could be to 
more strictly specify the inter-service interface to the emergency 
service network ( Where M7 is in Figure 1 of the ecrit-framework draft ).

Now, both Phonebcp and Framework describe a collaboration between many 
elements in the service provider's network. A service provider with an 
established structure need today analyze Phonebcp to pick what is 
relevant as it is said. Other functions need to be provided as intended 
when the call reaches the Emergency Service Network even if they are 
done in another way than what Phonebcp says internally in the Service 
Provider's network.

This need will be much more evident when service providers with IP but 
not SIP based conversational services want to arrange emergency calling.

Will it be sufficiently easy to do that mapping from Phonebcp and 
Framework, or is a true Emergency Service Network interface 
specification needed?

Gunnar

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 11 Mar 2011 15:46:01 +0100

I didn't say they were incompatible, or that they would never work. However it is more a matter of fitting where they touch.

If for example in a 3GPP network running LTE, you attempt to contact a LOST server from the terminal, as specified in phoneBCP, you are not going to find one provided by your 3GPP access provider because there is no requirement in 23.167 to provide one. You may be able to find one provided by someone else.

If you make such an attempt in a phone without a UICC, then you are not even going to be able to get the request to leave the terminal.

If you do attempt to follow phoneBCP as a pure IP connection to some non-3GPP provider, then you will not get the emergency bearer specified in 23.167 for LTE, UTRAN and cdma2000 accesses. That means other users could well get priority on the radio access over you.

I would also add that many 3GPP or 3GPP2 operators will initially support emergency calls by pushing you back to the CS network (where they already have universal coverage), they can only do that if you follow the procedures by which they recognize the emergency call attempt in the first place. PhoneBCP does not provide for the UE making a call in that form.

The bottom line is that if you make an emergency call using a 3GPP or 3GPP2 phone in the manner specified in 23.167, then the 3GPP or 3GPP2 operator will undertake to ensure that it works. If you attempt to make the emergency call using procedures on the phone that are not specified in 23.167, then you will have to do your own analysis on what works, and it is on your own head if it does not.

If you want to alter what 3GPP specifies, then you make the appropriate contribution to 3GPP, not try and write something in an IETF RFC to imply that it is accepted fact.

Regards

Keith

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: 10 March 2011 04:55
> To: DRAGE, Keith (Keith)
> Cc: 'ecrit Org'
> Subject: IMS and ECRIT are not incompatible
> 
> Given this is going off-topic with respect to the original thread, I'll
> pick up Keith's point with a new subject title.
> 
> There's a meme going around that IMS emergency calling, specified in the
> stage 2 3GPP TS 23.167, is somehow a mutually exclusive alternative or
> inconsistent architecture with ECRIT and phone BCP.
> 
> It should be self evident that, like any other solution, IMS needs to
> address the functions of location determination and call routing. And,
> indeed, these functions are covered in 23.167 and are attributed to the
> "LRF" (Location Retrieval Function) network element. The spec decomposes
> the LRF into the logical functions of "LS" and "RDF" ("Location Server"
> and "Route Determination Function"). Most aspects of the operation of the
> LS and RDF are left out of scope or implementation dependent - which is
> fair enough.
> 
> There's a quite practical, IMS consistent, deployment of the LRF that uses
> LoST as the implementation for the RDF and HELD for the LS function. This
> should not be any surprise since IMS is like an over the top VoIP service
> with the simplification that all the elements can be in the same trust
> domain (though I find IMS specifications to be curiously silent of the use
> case of a subscriber initiating a call from a completely third party IP-
> CAN such as a residential WiFi access). It's also attractive in that it's
> consistent with respect to the principle of IMS being based on IETF
> specifications as opposed to inventing 3GPP-specific mechanisms.
> 
> The real value to the network/IMS operator of course is that an
> implementation that used LoST and HELD as described above would also
> support the more general use cases that Keith rules out below - and
> obviating the need to resort to pseudo-legalistic arguments to justify the
> limited scope of IMS. It would also facilitate the use case mentioned
> above assuming the broadband provider behind the residential WiFi
> connection also had a consistent implementation. It's all good.
> 
> Cheers,
> Martin
> 
> For Voip, 3GPP and 3GPP2 based networks have a defined manner of
> supporting emergency calls covered by 3GPP common IMS specifications,
> backed up by use of the existing CS network where such exists.
> 
> As far as the 3GPP and 3GPP2 operators are concerned the 3GPP
> specifications meet their obligations to the regulators, and the phones
> wishing to use those capabilities have to correspond to the 3GPP
> specifications.
> 
> Those specifications correspond to phone BCP only where they are trying to
> address a common requirement. Key things they will not do is use of Lost
> and Lost servers, endpoint location validation, no encryption of location,
> as this is protected by trust domains, no direct calling of the PSAP from
> the end device - recognition instead by intermediate SIP entities, etc.
> 
> If as an end user you choose to ignore those provisions for support of
> emergency calls in 3GPP and 3GPP2 networks, and make the call using an IP
> connection to some other service provider, then that is your look out. It
> imposes no obligations on the 3GPP or 3GPP2 service provider.
> 
> Now there were comments prior to this to write some of this into the
> document. As far as I am concerned those comments are still open.
> 
> Regards
> 
> Keith
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 14 Mar 2011 14:19:13 +0800

Hi Keith,

You appear to continue to argue that it's an either/or situation - despite your no doubt sincere assurances. My argument is that IMS with all it's benefits (perceived or actual) can still be implemented while, with no additional complexity, also having a network that supports the general ECRIT model.

Responses below.

Cheers,
Martin

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Saturday, 12 March 2011 1:46 AM
To: Dawson, Martin
Cc: 'ecrit Org'
Subject: RE: IMS and ECRIT are not incompatible

I didn't say they were incompatible, or that they would never work.
[[MCD] ] I'm sure you weren't saying that; I'm sure you weren't even intending to imply it... though there was nothing to prevent the inference.

 However it is more a matter of fitting where they touch.

If for example in a 3GPP network running LTE, you attempt to contact a LOST server from the terminal, as specified in phoneBCP, you are not going to find one provided by your 3GPP access provider because there is no requirement in 23.167 to provide one. You may be able to find one provided by someone else.
[[MCD] ] This doesn't sound right. There's no requirement in 23.167 that there isn't a LoST server or that the RDF couldn't be implemented as a LoST server. The LRF could query LoST in response to the routing request from the E-CSCF. If the operator did that then they have the option to provide access to that LoST service for non-IMS phone-bcp procedures as well thereby supporting both the IMS use case and the general use cases as well.

If you make such an attempt in a phone without a UICC, then you are not even going to be able to get the request to leave the terminal.
[[MCD] ] That's an IMS-specific consideration. The question of providing unregistered access to VoIP 9-1-1 is orthogonal. You can still do the emergency registration procedures on IMS without excluding LoST and LIS for the LRF mechanisms.

If you do attempt to follow phoneBCP as a pure IP connection to some non-3GPP provider, then you will not get the emergency bearer specified in 23.167 for LTE, UTRAN and cdma2000 accesses. That means other users could well get priority on the radio access over you.
[[MCD] ] Ditto, that's an IMS consideration. The question of priority for VOIP 9-1-1 calls is orthogonal. You don't have to throw away IMS if you really really think this is an imperative. Further, in principle, layer 4 methods can still provide priority to sessions established with known PSAP/ESInet destinations consistent with the area of coverage of the network; so QoS becomes a matter of degree not a binary consideration. 

I would also add that many 3GPP or 3GPP2 operators will initially support emergency calls by pushing you back to the CS network (where they already have universal coverage), they can only do that if you follow the procedures by which they recognize the emergency call attempt in the first place. PhoneBCP does not provide for the UE making a call in that form.
[[MCD] ] Absolutely agree; and phone-BCP isn't even a consideration if that's the scenario. Indeed the apparent likelihood that fallback to circuit services will be used for 9-1-1 (and, probably, voice generally) only raises the question of when IMS will be the relevant consideration anyway. At the same time, the increasing emphasis on strategies involving WiFi off-load raise the question of how 9-1-1 would be supported in that case when the WiFi may well be independent of the operator network. The best hope is actually that phone-bcp procedures can be used on that access; that may be where VoIP actually bites first for mobile operators.

The bottom line is that if you make an emergency call using a 3GPP or 3GPP2 phone in the manner specified in 23.167, then the 3GPP or 3GPP2 operator will undertake to ensure that it works. If you attempt to make the emergency call using procedures on the phone that are not specified in 23.167, then you will have to do your own analysis on what works, and it is on your own head if it does not.
[[MCD] ] This falls under the category of the pseudo-legalistic argument. There is no explicit regulation currently and, as Brian says, there are no protocol police. When it comes to supporting emergency calls made on IP (that is - VoIP) operators have their own choices as to the extent and manner in which they implement solutions. There's not much in the way regulatory imperative at the moment - so if you're not subscribing to any circuit service (wired or wireless) at the moment you're already taking the consequences "on your own head". But then... that's what people are doing isn't it.

If you want to alter what 3GPP specifies, then you make the appropriate contribution to 3GPP, not try and write something in an IETF RFC to imply that it is accepted fact.
[[MCD] ] That would be good. I'd really like to see 3GPP taking a proactive approach to showing how the ECRIT and associated IETF protocols can comfortably be integrated with the IMS use case. As I say, this should not be a surprising possibility given the design principle of IMS anyway.

Regards

Keith