Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

[Jean-Marc Valin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Seriously, I think this whole issue is adequately addressed by this
audio draft ticket by Bernard:
http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/12

Cheers,

	Jean-Marc

On 03/15/2013 12:08 PM, [e-mail] wrote:
>>> we shouldn't give the impression that its more important to
>>> include some codecs than others that are available to the
>>> browser to use.
> 
> But Why shouldn't we give that impression ?
> 
> Because obviously YES it is more important to support codecs that
> are implemented in billions of devices and the support of which
> will improve the quality for millions of customers and reduce the
> costs in networks than codecs of specific and limited usage.
> 
> And since AMR AMR-WB stay the mandatory codecs for 4G VoLTE I don't
> think the importance of these codecs can ben challenged for the
> future
> 
> Stéphane
> 
> 
> -----Message d'origine----- De : Andrew Allen
> [mailto:[e-mail]] Envoyé : vendredi 15 mars 2013
> 16:58 À : PROUST Stephane OLNC/OLPS; [e-mail];
> [e-mail]; [e-mail] Cc : MARJOU Xavier OLNC/OLN;
> [e-mail] Objet : Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
> 
> 
> Suitable to me means suitable for the application context i.e if
> the application is conversational real time audio then all audio
> codecs suitable for conversational real time audio the browser has
> the ability to use are recommended to be included in the offer.
> 
> I don't agree to mention specific codecs - all codecs that meet the
> suitability for the application apply and we shouldn't give the
> impression that its more important to include some codecs than
> others that are available to the browser to use.
> 
> 
> ----- Original Message ----- From: [e-mail]
> [mailto:[e-mail]] Sent: Friday, March 15, 2013
> 10:50 AM Central Standard Time To: Andrew Allen;
> [e-mail] <[e-mail]>; [e-mail]
> <[e-mail]>; [e-mail] <[e-mail]> Cc:
> MARJOU Xavier OLNC/OLN <[e-mail]>; [e-mail]
> <[e-mail]> Subject: RE: [rtcweb] Agenda time	request	for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
> 
> Hello
> 
> As mentioned earlier, this kind of general statement makes sense
> and would be acceptable for us only if it gives some minimum
> guidance on what "suitable" means. It means: the codecs that are
> especially important to be considered because their support would
> solve the interoperability issue for a huge number of calls and
> because they can be made available to the browsers on a high number
> of devices:
> 
> "If other suitable audio codecs are available to the browser to use
> it is recommended that they are also included in the offer in order
> to maximize the possibility to establish the session without the
> need for audio transcoding." This is especially the case for AMR
> and AMR-WB for interoperability with 3GPP mobile devices and G.722
> for interoperability with fixed ETSI/DECT CAT-iq devices
> 
> 
> Stephane Proust
> 
> 
> 
> -----Message d'origine----- De : Andrew Allen
> [mailto:[e-mail]] Envoyé : vendredi 15 mars 2013 15:56
> À : [e-mail]; [e-mail]; [e-mail];
> PROUST Stephane OLNC/OLPS Cc : MARJOU Xavier OLNC/OLN;
> [e-mail] Objet : RE: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
> 
> Roland
> 
> I have proposed that we add the following text to address the
> interoperability concerns
> 
> "If other suitable audio codecs are available to the browser to use
> it is recommended that they are also included in the offer in order
> to maximize the possibility to establish the session without the
> need for audio transcoding."
> 
> The MTI Audio Codecs are defined to ensure a basic level of
> interoperability and will need to be always supported for that
> reason. Support for additional audio codecs is an implementation
> and business case decision and the additional audio codecs that it
> makes sense to support will change over time (as codecs become
> obsolete and new ones are developed and deployed. So additional
> audio codecs should not be specified in the RTCweb RFCs.
> 
> Andrew
> 
> -----Original Message----- From: [e-mail]
> [mailto:[e-mail]] Sent: Friday, March 15, 2013 5:45 AM 
> To: Andrew Allen; [e-mail]; [e-mail];
> [e-mail] Cc: [e-mail];
> [e-mail] Subject: AW: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
> 
> Hi Andrew, but where will you start and where will you end. The
> codec discussion appears now so why not try to solve this now? And
> one proposal is to use these codecs and I fully support it.
> 
> Roland
> 
>> -----Ursprüngliche Nachricht----- Von: [e-mail]
>> [mailto:[e-mail]] Im Auftrag von Andrew Allen 
>> Gesendet: Donnerstag, 14. März 2013 22:10 An: [e-mail];
>> [e-mail]; [e-mail] Cc:
>> [e-mail]; [e-mail] Betreff: Re: [rtcweb]
>> Agenda time request for 
>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>> 
>> 
>> Koen is right that there are many more obstacles to RTCweb and
>> legacy network interop than just a common codec. First there will
>> need to be RTCweb signaling gateways to interface between the
>> RTCweb signaling and the legacy networks (SIP, H.323 etc) and
>> there will need to be in place mechanisms for peering, federation
>> and address resolution between networks as well as service 
>> agreements in place between the players.
>> 
>> Until those are resolved supporting codecs used in those networks
>> is pointless.
>> 
>> Andrew
>> 
>> ----- Original Message ----- From: Koen Vos
>> [mailto:[e-mail]] Sent: Thursday, March 14, 2013 03:32
>> PM Central Standard Time To: Espen Berger (espeberg)
>> <[e-mail]>; [e-mail]
>> <[e-mail]> Cc: [e-mail]
>> <[e-mail]>; MARJOU Xavier OLNC/OLN 
>> <[e-mail]> Subject: Re: [rtcweb] Agenda time
>> request for draft-marjou-rtcweb-audio-codecs-for-interop-01
>> 
>>> It's interop with billions of mobile phones and with fixed
>> terminals in legacy telephony services.
>> 
>> The problem is that WebRTC and legacy services live in separate 
>> networks: the open Web vs proprietary Telco networks.
>> 
>> WebRTC connecting to a Telco network would have to go through a 
>> Gateway.  The PSTN termination providers who run these Gateways 
>> support G.711, G.729 and perhaps some other  codecs like iLBC.
>> They do not, however, support the codecs you are advocating for.
>> 
>> The lack of support for Transcoding-Free Operation by Telcos to
>> the rest of the world has been hurting interop voice quality for
>> a long time, but unfortunately we can't fix that here at the
>> IETF.
>> 
>> We can fit our cars with your costly railroad wheels, but you
>> still wouldn't let us on your tracks.
>> 
>> koen.
>> 
>> 
>> -----Original Message----- From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of 
>> [e-mail] Sent: 14. mars 2013 13:36 To:
>> Jean-Marc Valin Cc: [e-mail]; MARJOU Xavier OLNC/OLN 
>> Subject: Re: [rtcweb] Agenda time request for 
>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>> 
>> Hello
>> 
>> The short list is aligned to what is specified in 3GPP (mobile)
>> and CAT-iq (fixed). Check the related service specifications! The
>> short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to
>>  minimize interop issues and transcoding costs for telco
>> services. It's not a question of what's the favourite codec for a
>> given application. It's interop with billions of mobile phones
>> and with fixed terminals in legacy telephony services.
>> 
>> Stéphane
>> 
>> -----Message d'origine----- De : Jean-Marc Valin
>> [mailto:[e-mail]] Envoyé : jeudi 14 mars 2013 05:55 À
>> : PROUST Stephane OLNC/OLPS Cc : Andrew Allen;
>> [e-mail]; MARJOU Xavier OLNC/OLN; [e-mail]
>> Objet : Re: [rtcweb] Agenda time request for 
>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>> 
> On 03/13/2013 06:48 PM, [e-mail] wrote:
>>>> The reason is simply that AMR and AMR-WB are supported in
> billions of
>>>> devices !
> 
> Just curious, why exclude from the list other codecs with similar
> huge deployment? I can think of at least: - GSM-FR (mobile) - Speex
> (Flash) - G.729 (PSTN gateways) - iLBC (PSTN gateways) - G.726
> (DECT) - SILK (original non-Opus version in Skype)
> 
> (sorry, if I missed someone's favorite codec in this list)
> 
> It's not at all clear to me what's so special that makes AMR,
> AMR-WB and G.722 different from the other codecs in the list above.
> Not that I insist on shipping G.729 :-)
> 
> Personally, I'd favor a draft that included a lot more codecs, 
> describing for each one the benefits of supporting it. Implementers
>  could then choose which of these they care about for their
> particular situation.
> 
> Cheers,
> 
> Jean-Marc
> 
>>>> Stéphane
>>>> 
>>>> 
>>>> -----Message d'origine----- De : Andrew Allen 
>>>> [mailto:[e-mail]] Envoyé : mercredi 13 mars
>>>> 2013 23:41 À : PROUST Stephane OLNC/OLPS;
>>>> [e-mail]; [e-mail] Cc : MARJOU
>>>> Xavier OLNC/OLN;
> [e-mail] Objet
>>>> : Re: [rtcweb] Agenda time request for 
>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>> 
>>>> 
>>>> No this wouldn't be acceptable to me.
>>>> 
>>>> I don't see a reason to push a particular set of Codecs
> over any other
>>>> set of codecs supported on the device. If the device supports
>>>> the codecs and they are available to the browser then we
>>>> should
> recommend
>>>> that they be offered in the negotiation.
>>>> 
>>>> The marjou draft can advertise the merits and reasons why
>>>> they are good codecs to support.
>>>> 
>>>> 
>>>> ----- Original Message ----- From: [e-mail]
>>>>  [mailto:[e-mail]] Sent: Wednesday, March
>>>> 13, 2013 05:14 PM Central Standard Time To:
>>>> [e-mail] <[e-mail]>;
>>>> [e-mail]
> <[e-mail]>
>>>> Cc: MARJOU Xavier OLNC/OLN <[e-mail]>;
> [e-mail]
>>>> <[e-mail]> Subject: Re: [rtcweb] Agenda time
>>>> request for draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>> 
>>>> Dear Markus
>>>> 
>>>> Thanks for your attempt to help !
>>>> 
>>>> Of course each Telco can handle this directly with vendors
>>>> and browsers manufacturers at business level. But I
>>>> don't'think
> this need
>>>> of interoperability with mobile devices is specific to
>>>> Orange. I think all mobile operators will have the same issue
>>>> and
> this is why
>>>> standardization exist. It's most cost and time efficient to
> have one
>>>> common way forward for all the industry.
>>>> 
>>>> Then if the issue is that "conditional MUST/SHOULD are a too
>>>>  complicated requirement. We could also live as a compromise
>>>> with a formulation that has already been suggested on the
>>>> reflector:
>>>> 
>>>> "If other suitable audio codecs are available to the
> browser to use it
>>>> is recommended that they are also included in the offer in
>>>> order to maximize the possibility to establish the session
>>>> without
> the need for
>>>> audio transcoding" If possible with the addition of This is
> especially
>>>> the case for AMR, AMR-WB for interoperability with mobile
> devices and
>>>> G.722 for interoperability with fixed DECT CAT-iq devices
>>>> 
>>>> Would it have one chance to reach consensus ?
>>>> 
>>>> I think this Group should at least make one small step so
>>>> that the interoperability issue with mobile terminals be not
>>>> fully
> ignored in
>>>> the RTC Web specification considering the huge number of
>>>> deployed devices. At least something must be written on this
>>>> ! G.711 which is the only codec in addition to OPUS for
> interoperability
>>>> purpose is not a proper answer to this.
>>>> 
>>>> Stéphane
>>>> 
>>>> -----Message d'origine----- De : [e-mail] 
>>>> [mailto:[e-mail]] Envoyé : mercredi 13 mars
>>>> 2013 22:37 À : PROUST Stephane OLNC/OLPS;
>>>> [e-mail]; MARJOU Xavier OLNC/OLN Cc :
>>>> [e-mail] Objet : RE: [rtcweb]
> Agenda time
>>>> request for draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>> 
>>>> Hi Stephane, Xavier,
>>>> 
>>>> I understand the intent of your proposal. I'm not sure if
> the IETF is
>>>> the best venue for you to pursue it, however. Perhaps you
> as a mobile
>>>> operator should rather set it as a requirement to your
> mobile device
>>>> platforms that they open up the APIs to AMR and AMR-WB and
>>>> that at least the in-built default browser needs to support
>>>> it. If
> there are
>>>> enough operators setting such requirements directly to the
> device and
>>>> platform vendors, it probably has a bigger impact than an
>>>> IETF RFC. Getting that support for user-installed additional
>>>> browsers
> might be
>>>> more difficult, but most mobile device users stick with the
>>>> default browser anyway.
>>>> 
>>>> The RTCWEB codec document needs to definitely explain this
>>>> case and the benefits, but the conditional MUSTs or SHOULDs
>>>> you are
> proposing
>>>> are perhaps a bit too complicated. Hmm, perhaps we need to do
>>>> an _informational_ RFC as something like "Recommendations
>>>> for
> WebRTC on
>>>> Mobile Devices" addressing the codec and perhaps other
>>>> issues, that you could use as a reference in your
>>>> requirements.
>>>> 
>>>> Markus
>>>> 
>>>> 
>>>>> -----Original Message----- From: [e-mail] 
>>>>> [mailto:[e-mail]] On Behalf Of ext 
>>>>> [e-mail] Sent: 13 March, 2013 21:37 To: 
>>>>> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc:
>>>>> [e-mail] Subject: Re: [rtcweb] Agenda time request
>>>>> for draft-marjou-rtcweb-audio- codecs-for-interop-01
>>>>> 
>>>>> Hello
>>>>> 
>>>>> Our understanding is that the reason of the "no consensus"
>>>>> on additional recommended codecs was the additional costs
>>>>> for
> browsers.
>>>>> The proposal is then to make these "MUST" fully conditional
>>>>> to the case of no (or very reduced) additional costs, when
>>>>> the codecs are already available on the device and when no
>>>>> additional
> license fee is
>>>>> required
>>>>> 
>>>>> We could even live with lower level of "requirements" with
>>>>>  respectively May and Should (instead of Should and shall)
>>>>> but we think that this proposal is a way to take into
>>>>> account
> both browser
>>>>> manufacturers concerns on browsers costs and telcos
>>>>> concerns on transcoding costs and some other companies
>>>>> share this view.
>>>>> 
>>>>> Stéphane
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -----Message d'origine----- De : [e-mail] 
>>>>> [mailto:[e-mail]] De la part de Jean-Marc
> Valin Envoyé
>>>>> : mercredi 13 mars 2013 20:24 À : MARJOU Xavier OLNC/OLN Cc
>>>>> : [e-mail] Objet : Re: [rtcweb] Agenda time request
>>>>> for draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>>> 
>>>> Hi,
>>>> 
>>>> I'd really like to understand how the chairs coming to the
> conclusion
>>>> that there was *no consensus* on recommended codecs can
>>>> result in a draft that includes 3 MUSTs and 1 SHOULD. This
>>>> draft
> effectively makes
>>>> 3 new codecs MTI for a range of devices. I understand that
>>>> it's an individual draft and you can write whatever you like
>>>> in
> there, but it
>>>> definitely goes against the result of the WG discussion.
>>>> 
>>>> Cheers,
>>>> 
>>>> Jean-Marc
>>>> 
>>>> On 03/13/2013 09:14 AM, Xavier Marjou wrote:
>>>>>>> Here is a summary of the 
>>>>>>> draft-marjou-rtcweb-audio-codecs-for-interop-00
> presentation that I
>>>>>>> had prepared for yesterday's session:
>>>>>>> 
>>>>>>> - The co-authors want to underline that non-WebRTC
>>>>>>> voice
> endpoints
>>>>>>> usually use one of the following codecs: AMR, AMR-WB or
>>>>>>> G.722, which will result in massive transcoding when
>>>>>>> there will be communications between WebRTC endpoints
>>>>>>> and non-WebRTC endpoints.
>>>>>>> 
>>>>>>> - On one side, transcoding is bad for many reasons
> discussed in the
>>>>>>> draft (cost issues, intrinsic quality degradation,
>>>>>>> degraded interactivity, fallback from HD to G.711...);
>>>>>>> 
>>>>>>> - On the other side, it is recognized that
>>>>>>> implementing
> additional
>>>>>>> codecs in the browsers can generate additional costs.
>>>>>>> 
>>>>>>> - In order to reach a compromise, we would like to add
> some text in
>>>>>>> the WG draft draft-ietf-rtcweb-audio providing
> incentives for the
>>>>>>> browser to use these three codecs: make them mandatory
> to implement
>>>>>>> when there is no cost impact on the browser (e.g. if
> codec already
>>>>>>> installed, paid by the device vendor...).
>>>>>>> 
>>>>>>> Any opinion on that?
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> Xavier
>>>>>>> 
>>>>>>> PS: I will be ready to present the slides on Thursday
>>>>>>> if time permits it.
>>>>>>> 
>>>>>>> (c.f. 
>>>>>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
>>>>>>>
>>>>>>>
>
>>>>>>> 
)
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie
>>>>>>> <[e-mail] <mailto:[e-mail]>>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Magnus and I discussed this this morning, and we
> encourage you to
>>>>>>> prepare something.  If the discussion of working group
>>>>>>> last call items runs short, we may be able to fit this
>>>>>>> in at that
> time or at
>>>>>>> the end of day one if its full agenda his finished.
> This is not a
>>>>>>> commitment, however, so please try and get discussion
>>>>>>> on
> the list
>>>>>>> on the points from the draft you feel need resolution.
>>>>>>> 
>>>>>>> regards,
>>>>>>> 
>>>>>>> Ted
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
>>>>>>>  <[e-mail] <mailto:[e-mail]>>
>>>>>>> wrote:
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I would like to request agenda time for:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> The document  presents use-cases underlining why
>>>>>>>> WebRTC needs
>>>>>>> AMR-WB,  AMR
>>>>>>>> and G.722 as additional relevant voice codecs to
>>>>>>>> satisfactorily ensure interoperability with existing
>>>>>>>> systems.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> A 10-minute time slot should be sufficient for
>>>>>>>> presentation and
>>>>>>> discussion.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Regards
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -Espen
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> rtcweb
>>>> mailing list
>>>>>>>> [e-mail] <mailto:[e-mail]> 
>>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>>>> 
>>>>>>> _______________________________________________ rtcweb
>>>> mailing list
>>>>>>> [e-mail] <mailto:[e-mail]> 
>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________ rtcweb
>>>> mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>>> 
>>>> 
>>>>> _______________________________________________ rtcweb
> mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>> 
>>>>> ___________________________________________________________
>>>>>
>>>>> 
___________________________________________________________ ___
>>>>> 
>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>> informations confidentielles ou privilegiees et ne doivent
>>>>> donc pas
> etre diffuses,
>>>>> exploites ou copies sans autorisation. Si vous avez recu
> ce message
>>>>> par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
>>>>> que les pieces jointes. Les messages electroniques etant
> susceptibles
>>>>> d'alteration, France Telecom - Orange decline toute
> responsabilite si
>>>>> ce message a ete altere, deforme ou falsifie. Merci.
>>>>> 
>>>>> This message and its attachments may contain confidential
>>>>> or privileged information that may be protected by law;
>>>>> they
> should not
>>>>> be distributed, used or copied without authorisation. If
>>>>> you have received this email in error, please notify the
>>>>> sender and delete this message and its attachments. As
>>>>> emails may be altered, France Telecom - Orange is not
>>>>> liable for messages that have been
> modified,
>>>>> changed or falsified. Thank you.
>>>>> 
>>>>> _______________________________________________ rtcweb
> mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>> 
>>>> 
> ______________________________________________________________________
>>>>
> 
___________________________________________________
>>>> 
>>>> Ce message et ses pieces jointes peuvent contenir des
>>>> informations confidentielles ou privilegiees et ne doivent
>>>> donc pas etre
> diffuses,
>>>> exploites ou copies sans autorisation. Si vous avez recu ce
>>>> message par erreur, veuillez le signaler a l'expediteur et
>>>> le
> detruire ainsi
>>>> que les pieces jointes. Les messages electroniques etant
> susceptibles
>>>> d'alteration, France Telecom - Orange decline toute
> responsabilite si
>>>> ce message a ete altere, deforme ou falsifie. Merci.
>>>> 
>>>> This message and its attachments may contain confidential or
>>>>  privileged information that may be protected by law; they
> should not
>>>> be distributed, used or copied without authorisation. If you
>>>> have received this email in error, please notify the sender
>>>> and
> delete this
>>>> message and its attachments. As emails may be altered,
> France Telecom
>>>> - Orange is not liable for messages that have been
> modified, changed
>>>> or falsified. Thank you.
>>>> 
>>>> _______________________________________________ rtcweb
>>>> mailing list [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>> 
>>>> 
> ---------------------------------------------------------------------
>>>>
>>>>
>
> 
This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by
> the solicitor-client or other applicable privileges), or constitute
>  non-public information. Any use of this information by anyone
> other than the intended recipient is prohibited. If you have
> received this transmission in error, please immediately reply to
> the sender and delete this information from your system. Use,
> dissemination, distribution, or reproduction of this transmission
> by unintended recipients is not authorized and may be unlawful.
>>>> 
>>>> 
> ______________________________________________________________________
>>>>
> 
___________________________________________________
>>>> 
>>>> Ce message et ses pieces jointes peuvent contenir des
>>>> informations confidentielles ou privilegiees et ne doivent
>>>> donc pas etre
> diffuses,
>>>> exploites ou copies sans autorisation. Si vous avez recu ce
>>>> message par erreur, veuillez le signaler a l'expediteur et
>>>> le
> detruire ainsi
>>>> que les pieces jointes. Les messages electroniques etant
> susceptibles
>>>> d'alteration, France Telecom - Orange decline toute
> responsabilite si
>>>> ce message a ete altere, deforme ou falsifie. Merci.
>>>> 
>>>> This message and its attachments may contain confidential or
>>>>  privileged information that may be protected by law; they
> should not
>>>> be distributed, used or copied without authorisation. If you
>>>> have received this email in error, please notify the sender
>>>> and
> delete this
>>>> message and its attachments. As emails may be altered,
> France Telecom
>>>> - Orange is not liable for messages that have been
> modified, changed
>>>> or falsified. Thank you.
>>>> 
> 
>> 
>> ______________________________________________________________ 
>> ___________________________________________________________
>> 
>> Ce message et ses pieces jointes peuvent contenir des
>> informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous
>> avez recu ce message par erreur, veuillez le signaler a
>> l'expediteur et le detruire ainsi que les pieces jointes. Les
>> messages electroniques etant susceptibles d'alteration, France
>> Telecom - Orange decline toute responsabilite si ce message a ete
>> altere, deforme ou falsifie. Merci.
>> 
>> This message and its attachments may contain confidential or 
>> privileged information that may be protected by law; they should
>> not be distributed, used or copied without authorisation. If you
>> have received this email in error, please notify the sender and 
>> delete this message and its attachments. As emails may be
>> altered, France Telecom - Orange is not liable for messages that
>> have been modified, changed or falsified. Thank you.
>> 
>> _______________________________________________ rtcweb mailing
>> list [e-mail] 
>> https://www.ietf.org/mailman/listinfo/rtcweb 
>> _______________________________________________ rtcweb mailing
>> list [e-mail] 
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> _______________________________________________ rtcweb mailing
>> list [e-mail] 
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> ---------------------------------------------------------------------
>>
>> 
This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by
>> the solicitor-client or other applicable privileges), or
>> constitute non-public information. Any use of this information by
>> anyone other than the intended recipient is prohibited. If you
>> have received this transmission in error, please immediately
>> reply to the sender and delete this information from your system.
>> Use, dissemination, distribution, or reproduction of this
>> transmission by unintended recipients is not authorized and may
>> be unlawful. _______________________________________________ 
>> rtcweb mailing list [e-mail] 
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
> 
> ---------------------------------------------------------------------
>
> 
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
> 
> _________________________________________________________________________________________________________________________
>
>  Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi que les pieces jointes. Les messages electroniques
> etant susceptibles d'alteration, France Telecom - Orange decline
> toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should
> not be distributed, used or copied without authorisation. If you
> have received this email in error, please notify the sender and
> delete this message and its attachments. As emails may be altered,
> France Telecom - Orange is not liable for messages that have been
> modified, changed or falsified. Thank you.
> 
> 
> ---------------------------------------------------------------------
>
> 
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
> 
> _________________________________________________________________________________________________________________________
>
>  Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi que les pieces jointes. Les messages electroniques
> etant susceptibles d'alteration, France Telecom - Orange decline
> toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should
> not be distributed, used or copied without authorisation. If you
> have received this email in error, please notify the sender and
> delete this message and its attachments. As emails may be altered,
> France Telecom - Orange is not liable for messages that have been
> modified, changed or falsified. Thank you.
> 
> _______________________________________________ rtcweb mailing
> list [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRQ17tAAoJEJ6/8sItn9q9YdoH/2HVJh4g53Jj3YDnTqDlUURh
0zBFn6wfokAQ+iUS5rqai98cNZybgiC3bp2T43uvMk5S4b54wmd1faq9sVgFCOQ4
mc4Rl1T49zp+L+K3xXd0Ww02PTDrJzdYP0uHK34rl0m7SInzZvS9Wl1D7yADvwJm
Oz3Brd44O4QrKt+QBAQ6BpLv+AjAJg2RQjS262ivu0agSHqi2Tjiq6nw1C2iHzYV
wQpfLy1ND49M/+VQC9Yj5A0KgXHa1dEEJBUtHMRJ64e1ZUMhen8f3heUIarjbmT/
ZajUmawvk7GxkDdvkeMM/RkuXpB0EJKNt32SIvvujZNfgSyp985xfoJ6mLZxfoU=
=s5I2
-----END PGP SIGNATURE-----