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

[Roman Shpount <[e-mail]>]

Out of curiosity, since you are pushing so hard for AMR/AMR-WB support, how
would one connect to devices on Orange network using these codecs? Is there
currently a way to connect without going through G.711 transcoding?
_____________
Roman Shpount


On Fri, Mar 15, 2013 at 11:50 AM, <[e-mail]> wrote:

> 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
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > 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.
> > >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.13 (GNU/Linux)
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N
> > OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It
> > SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt
> > Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS
> > SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R
> > ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=
> > =K56v
> > -----END PGP SIGNATURE-----
> >
> > ______________________________________________________________
> > ___________________________________________________________
> >
> > 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.
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>