On 02/25/11 09:01, Elwell, John wrote:

"These events and state need to include information such as: receiving DTMF in the RTP, RTP and RTCP statistics, and the state of DTLS/SRTP handshakes."

I would be inclined to say instead: "These events and state need to include information such as: receiving DTMF in the RTP, RTP and RTCP statistics, and the security status of RTP sessions."

This would bring it more into line with item 9 earlier, which refrains from mentioning a specific key management protocol.

Also a nit: "NSIS" appears twice in the same list. thanks - I'll just adopt this, it seems sensible and uncontroversial.

John

...

-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Harald Alvestrand Sent: 24 February 2011 13:45 To: RTC-Web@alvestrand.no Subject: [RTW] WG charter, take 4

This is the current charter text - it's updated somewhat based on discussions on the list.

In particular, there's now suggested language about the relationship to session management protocols. We'll make this an explicit discussion at the BOF, with the aim of getting one of three conclusions in the charter:

- The WG will not address session management protocols - The WG will choose one or more session management protocols - The WG will discuss session management protocols, and do what makes sense.

The last one is the one suggested by the current charter text; the other possible outcomes should be easier to write text for.

Comments welcome!

Harald

(Note: The below is not going out in< 80 columns, I think. Please forgive the formatting issue.)

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

Version: 4

Name: RTCWEB WG Chair(s): Cullen Jennings<fluffy@cisco.com>

Body:

Many implementations have been made that use a Web browser to support direct, interactive communications, including voice, video, collaboration, and gaming. In these implementations, the web server acts as the signaling path between these applications, using locally significant identifiers to set up the association. Up till now, such applications have typically required the installation of plugins or non-standard browser extensions. There is a desire to standardize this functionality, so that this type of application can be run in any compatible browser and allow for high-quality real-time communications experiences within the browser.

Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human.

The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming.

This working group will select and define a minimal set of protocols that will enable browsers to: have interactive real time voice and video pairwise between browsers or other devices using RTP have interactive real time application data for collaboration and gaming pairwise between browsers

Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set:

1) RTP/ RTCP

2) a baseline audio codec for high quality interactive audio. Opus will be one of the codecs considered

3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be some of the codecs considered

4) a baseline video codec. H.264 and VP8 will be some of the codecs considered

5) Diffserv based QoS

6) NAT traversal using ICE

7) media based DTMF

8) support for identifying streams' purpose using semantics labels mappable to the labels described in RFC 4574

9) Secure RTP and keying

10) support for IPv4, IPv6 and dual stack browsers

Please note the above list is only a set of candidates that the WG may consider and is not list of things that will be in the profile the set.

This group's primary aim is to enable web applications to manage real-time communication sessions with other web-context applications that implement this specification. When making choices, the working group will also consider the impact of those choices on interoperability with other devices that create or manage multimedia sessions, including the complexity imposed on any gateways which may be required.

The Working group will identify information needed for session negotiation and management in web contexts, and its output documents will describe the relationship of this to information carried in session protocols used in other standardized contexts.

The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol.

The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser to applications running in the browser. These events and state need to include information such as: receiving DTMF in the RTP, RTP and RTCP statistics, and the state of DTLS/SRTP handshakes. The output of this WG will form input to the W3C group that specifies the API, and if there are parts of the mapping between the API and the protocols that need to be done outside of the W3C, this group will do it.

The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers.

The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, LOST, Geolocation, IM& Presence, NSIS, Resource Priority. RTP Payload formats will not be done in this WG.

Deliverables: An overview document describing the architecture A scenarios document describing scenarios that are expected to be supported A profile document specifying the protocols and options that must be supported by a conforming implementation (If needed) A mapping document describing the relationship between the protocols and the W3C-defined API.

Milestones:

May 2011 Main alternatives identified in drafts

Aug 2011 WG draft with text reflecting agreement of what the profile set should be

Sept 2011 Scenarios specification to IESG as Informational

Nov 2011 Draft available of documentation specifying mapping of protocol functionality to W3C-specified API produced. This is an input to W3C API work.

Dec 2011 Profile specification to IESG as PS

Apr 2012 Mapping document submitted to the IESG as Informational (if needed)

_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

+1 (This was a past topic on the list and appeared to have good support as a distinct WG). On 2011-02-25, at 10:01 AM, Magnus Westerlund wrote:

It is already obvious that any codec selection for this is going to be a difficult and possibly take time. To avoid this from de-railing the truly fundamental parts of the RTC-WEB solution, I am suggesting that this should be taken in its own WG, or if not possible at least as a separate WG item, with its own deadlines, so that it doesn't hold up the main work.

+1 -----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Peter Musgrave Sent: Friday, February 25, 2011 7:07 AM To: Magnus Westerlund Cc: Harald Alvestrand; RTC-Web@alvestrand.no Subject: Re: [RTW] WG charter, take 4 +1 (This was a past topic on the list and appeared to have good support as a distinct WG). On 2011-02-25, at 10:01 AM, Magnus Westerlund wrote:

It is already obvious that any codec selection for this is going to be a difficult and possibly take time. To avoid this from de-railing the truly fundamental parts of the RTC-WEB solution, I am suggesting that this should be taken in its own WG, or if not possible at least as a separate WG item, with its own deadlines, so that it doesn't hold up the main work.

_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

I agree with basically all of these things. More concrete comments below. On Sat, Feb 26, 2011 at 2:01 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:

Hi,

Sorry for not having produced these charter comments earlier as most would apply to earlier versions also. However, I do have a number of comments on it and think the charter could be restructured to become a much better charter. But lets start with the different comments.

The most fundamental issue with the charter is that it contains to much technical solution candidates, rather than talking about the goals and and general direction for achieving them. I think one needs to extract the few higher level goals from this list and work them into the charter in other ways. Certain things we likely can select, like RTP. But there is clearly a question on what profile and extensions that should be supported.

I also think one of the biggest uncertainties and fuzziness in the charter is because the model isn't agreed on. The discussion about the session management is clear due to that the model for the work aren't agreed on. I see two ways here. Either we manage to lock down the model prior to the chartering, or we have a charter that included this model discussion. Frankly I see the later as most likely as agreement on the model will require agreement with IETF's partner in this work. Thus the charter should take a bit more height for having such model discussion.

It is already obvious that any codec selection for this is going to be a difficult and possibly take time. To avoid this from de-railing the truly fundamental parts of the RTC-WEB solution, I am suggesting that this should be taken in its own WG, or if not possible at least as a separate WG item, with its own deadlines, so that it doesn't hold up the main work. That is likely anyway a good idea for long term purpose, so that only the codec selection part can be updated, and not the fundamental part when the set of codecs become out-dated.

I had already lost interest in this group because I thought it would just end up in endless baseline codec discussions. I agree with removing the baseline codec from the charter, if only to enable the group to move forward at all. I am not sure I agree though with creating a separate WG for it. Instead I think it would make much more sense to accept that we will always have a heterogeneous codec world and create a simple codec negotiation protocol.

I still don't understand the diffserv based QoS. This seems very unrealistic to be usable from a web-browser perspective. This as no device in any setting other than being an ISP controlled device is likely to be allowed to set DSCP. I think QoS can be excluded at this stage completely. Especially as there are a lack of methods for providing end-point devices with a traffic class to DSCP mapping valid in the currently attached network.

The charter could also be clearer on the need for basic datagram and byte stream functionality between two peers. The higher motivation for it is there, but not requirements. Where I see rate control and security of those channels being the most important ones.

I am also missing a clear requirement for enabling future extensions of functionality of the RTC-WEB components in the browser.

That was another key issue I also have with the charter - I was under the impression the group is there to solve the RTC communication on the Web (!), i.e. in Web browsers using HTML5 and HTTP. The charter is, however, so much wider and I am starting to wonder if we are trying to create an unwieldy solution to an unclear problem.

I see this as important as we can hopefully arrive at the basic functionality reasonably quick, but there will be certain set of functionalities that are desirable but not quickly arrived agreed upon and specified. We need a method for enabling introduction of these in the future.

I also think one can clarify the last deliverable to actually be requirements on signaling and the API. Different functionalities will have different requirements when it comes to data objects needing exchange and also how the negotiation between the peers happens.

I am also missing a clearer requirement in ensuring that this becomes a network friendly traffic source. There is clearly need for congestion control and media adaptation as part of the basic solution.

As have been raised security is an important part of this work. I think we need to ensure that the WG first establish a security model, and then follows it in development. I fully agree that there should be no separate documents, this should be part of the general architecture, as it is such a fundamental part.

I am willing to provide an alternative charter proposal, if there is interest, attempting to take these comments into consideration.

I actually think that would be a good idea. Cheers, Silvia.

Cheers

Magnus Westerlund

---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB                | Phone  +46 10 7148287 Färögatan 6                | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

On 02/26/11 08:31, Bernard Aboba wrote:

...

That was another key issue I also have with the charter - I was under the impression the group is there to solve the RTC communication on the Web (!), i.e. in Web browsers using HTML5 and HTTP. The charter is, however, so much wider and I am starting to wonder if we are trying to create an unwieldy solution to an unclear problem.

[BA] The charter does not in fact cover a number of issues relevant to RTC communication over HTTP, such as something as basic as encoding. While peer-to-peer media over UDP is to be preferred where available, the reality is that today "HTTP failover" has become an essential feature of today's most successful realtime web services.

So ironically, the charter both underspecifies and overspecifies the work, at the same time. Bernard, can you formulate a section for the "list of technologies to be considered" that captures the technology of "HTTP failover"?

What are the other issues you don't feel are covered?

...

I am willing to provide an alternative charter proposal, if there is interest, attempting to take these comments into consideration.

I would support the development of an alternative proposal.

I would also welcome alternative text for sections of the current charter. While alternative proposals are one way to go, some of us think that the stuff that is in the current charter is stuff that needs to be in any charter going forward. The result is likely to be a synthesis of ideas; we can get there either by iterating or by proposing alternatives. Harald

On Sat, Feb 26, 2011 at 8:02 PM, Harald Alvestrand <harald@alvestrand.no> wrote:

Changing subjects to reflect main point, as usual....

On 02/26/11 04:16, Silvia Pfeiffer wrote:

...

I agree with basically all of these things. More concrete comments below.

On Sat, Feb 26, 2011 at 2:01 AM, Magnus Westerlund <magnus.westerlund@ericsson.com>  wrote:

...

Hi,

Sorry for not having produced these charter comments earlier as most would apply to earlier versions also. However, I do have a number of comments on it and think the charter could be restructured to become a much better charter. But lets start with the different comments.

The most fundamental issue with the charter is that it contains to much technical solution candidates, rather than talking about the goals and and general direction for achieving them. I think one needs to extract the few higher level goals from this list and work them into the charter in other ways. Certain things we likely can select, like RTP. But there is clearly a question on what profile and extensions that should be supported.

I also think one of the biggest uncertainties and fuzziness in the charter is because the model isn't agreed on. The discussion about the session management is clear due to that the model for the work aren't agreed on. I see two ways here. Either we manage to lock down the model prior to the chartering, or we have a charter that included this model discussion. Frankly I see the later as most likely as agreement on the model will require agreement with IETF's partner in this work. Thus the charter should take a bit more height for having such model discussion.

It is already obvious that any codec selection for this is going to be a difficult and possibly take time. To avoid this from de-railing the truly fundamental parts of the RTC-WEB solution, I am suggesting that this should be taken in its own WG, or if not possible at least as a separate WG item, with its own deadlines, so that it doesn't hold up the main work. That is likely anyway a good idea for long term purpose, so that only the codec selection part can be updated, and not the fundamental part when the set of codecs become out-dated.

I had already lost interest in this group because I thought it would just end up in endless baseline codec discussions. I agree with removing the baseline codec from the charter, if only to enable the group to move forward at all.

I am not sure I agree though with creating a separate WG for it.

Instead I think it would make much more sense to accept that we will always have a heterogeneous codec world and create a simple codec negotiation protocol.

I think we have consensus that we will have codec negotiation in any realistic scenario (whether the actual negotiation protocol is in scope or out of scope is a current matter of debate).

I think we need a baseline codec set, for all the normal reasons. I think that among us, we have experience enough in managing working group discussions that it's possible to discuss things one subject at a time.

Developing yet another protocol suite that requires external profiling in order to achieve interoperability is something I find deeply distasteful.

With a codec negotiation protocol, you don't need a profile to clients interoperable: either the clients support a common codec or they don't. In latter case no communication is possible. I agree that the goal of a common baseline codec across all applications is an ideal to aspire to. However, experience from HTML5 shows that unless all vendors are on the same page, you can end up in endless discussions about this topic without any real effect. The choice of codec seems to be more of a business issue than a technical interoperability issue.

...

...

I still don't understand the diffserv based QoS. This seems very unrealistic to be usable from a web-browser perspective. This as no device in any setting other than being an ISP controlled device is likely to be allowed to set DSCP. I think QoS can be excluded at this stage completely. Especially as there are a lack of methods for providing end-point devices with a traffic class to DSCP mapping valid in the currently attached network.

The charter could also be clearer on the need for basic datagram and byte stream functionality between two peers. The higher motivation for it is there, but not requirements. Where I see rate control and security of those channels being the most important ones.

I am also missing a clear requirement for enabling future extensions of functionality of the RTC-WEB components in the browser.

That was another key issue I also have with the charter - I was under the impression the group is there to solve the RTC communication on the Web (!), i.e. in Web browsers using HTML5 and HTTP. The charter is, however, so much wider and I am starting to wonder if we are trying to create an unwieldy solution to an unclear problem.

I am sorry that you have misunderstood. The effort was started in order to enable real-time browser-to-browser communication, which HTTP is fundamentally unsuitable for; HTTP-server-mediated communication is (to a large degree) possible to achieve without standardization.

I doubt both of these statements about HTTP are true any longer. During the time of creation or RTP/RTSP, I would have agreed. However, with HTTP streaming through byte ranges and with Web sockets that keep connections open, I wonder if these claims about HTTP are so true any more. I can understand that you want to allow the use of RTP/RTSP as well, seeing as that's been the traditional way of doing live streaming. However, I would want us to keep an open mind about the actual protocols and technologies being used. The Web runs after all over HTTP and if HTTP turns out to be usable for this use case - even if there may be some disadvantages to it - I would not want to exclude it. My main interest in this activity is to see RTC work with HTML5. Cheers, Silvia.

(Changing subject again, since this has strayed from the baseline thread) On 02/26/11 19:47, Bernard Aboba wrote:

Silvia Pfeiffer said:

"I doubt both of these statements about HTTP are true any longer."

[BA] In fact, they haven't been true for quite a while.

Every day users participate in interactive sessions over HTTP, largely in circumstances where use of UDP media is not possible. Because of the prevalence of highly restrictive enterprise firewalls that do not permit passing of UDP, the ability to support realtime communications over HTTP is now considered a practical requirement for business-oriented services, such as web conferencing.

Although realtime communications over HTTP is largely used as a fallback, measurements show surprisingly high audio quality in the majority of sessions, probably because many sessions take place over well-provisioned enterprise networks.

The Google Talk numbers I've seen published elsewhere are that ~5-10% of sessions run over TCP, relayed through a server, because UDP doesn't get there. The reasons to prefer point-to-point UDP if possible include: - Much lower delay when the endpoints are close to each other, network-wise - Much cheaper provisioning for the service provider The lower delay is the factor with the largest impact on comfort of conversation, I think; as long as we don't encounter congestion, the audio quality shouldn't be that much different. When we encounter congestion, audio-over-TCP will experience this as jitter, while audio-over-UDP will experience this as packet loss, so the experience may be different. There are many tricks available for lessening the impact of both.

The Google Talk numbers I've seen published elsewhere are that ~5-10% of sessions run over TCP, relayed through a server, because UDP doesn't get there.

[BA] On Live Meeting, it is quite frequent for at least one user in a conference to require a non-UDP alternative. Where UDP outbound is not allowed, we are finding that often TCP outbound is not allowed either, and only HTTP (and sometimes not even HTTPS) will work.

The reasons to prefer point-to-point UDP if possible include: - Much lower delay when the endpoints are close to each other, network-wise - Much cheaper provisioning for the service provider

No argument. It doesn't make sense to prefer TCP or HTTP transport if UDP is available.

On Sat, Feb 26, 2011 at 6:51 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>wrote:

On Sun, Feb 27, 2011 at 10:37 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

...

(Changing subject again, since this has strayed from the baseline thread)

On 02/26/11 19:47, Bernard Aboba wrote:

...

Silvia Pfeiffer said:

"I doubt both of these statements about HTTP are true any longer."

[BA] In fact, they haven't been true for quite a while.

Every day users participate in interactive sessions over HTTP, largely in circumstances where use of UDP media is not possible. Because of the prevalence of highly restrictive enterprise firewalls that do not permit passing of UDP, the ability to support realtime communications over HTTP is now considered a practical requirement for business-oriented services, such as web conferencing.

Although realtime communications over HTTP is largely used as a fallback, measurements show surprisingly high audio quality in the majority of sessions, probably because many sessions take place over well-provisioned enterprise networks.

The Google Talk numbers I've seen published elsewhere are that ~5-10% of sessions run over TCP, relayed through a server, because UDP doesn't get there.

The reasons to prefer point-to-point UDP if possible include: - Much lower delay when the endpoints are close to each other, network-wise - Much cheaper provisioning for the service provider

The lower delay is the factor with the largest impact on comfort of conversation, I think; as long as we don't encounter congestion, the audio quality shouldn't be that much different.

When we encounter congestion, audio-over-TCP will experience this as jitter,

Most of the implementations I have seen will simply go into buffering mode when they run out of data and then delay the display of that data until they are pretty sure they can play continuously for a bit. With HTTP adaptive streaming, the server would be notified of the problem and start pushing lower bandwidth packets that are then less likely to cause buffering mode again.

The buffering approach is certainly more easily usable in broadcast-type applications rather than meeting-type applications where all participants need to receive the audio (and video) in real-time to be able to reasonably partake. This can, however, also be achieved with HTTP adaptive streaming if the byte range requests are small enough and can be cancelled to be replaced by a request to the next required time.

This link has a paper with an interesting read in this space and analysing some of the problems with HTTP adaptive streaming:

http://blog.streamingmedia.com/the_business_of_online_vi/2011/02/new-data-re...

I'm aware that HTTP (or TCP) is not typically the best protocol to do RTC. What I am trying to say though is that we should not completely discout TCP (and therefore HTTP).

...

while audio-over-UDP will experience this as packet loss, so the experience may be different.

There are many tricks available for lessening the impact of both.

I agree and I'd hate us to exclude TCP (and therefore HTTP) from our discussions.

Agree. It's important to provide the best possible performance, but more important to ensure that things work at all. So I think that means we'll prefer to run over UDP, possibly provide a fallback to TCP/HTTPS, and ultimately fallback to WebSockets. I say possibly, for TCP, since I'm not yet sure whether it would provide a significantly better outcome than using WebSockets.

Cheers, Silvia. _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

Hi, I just want to say that I am involved in discussions with Harald and Cullen about my comments on the charter. I do hope that by early next week there will be something to show from this discussion. Cheers Magnus Magnus Westerlund skrev 2011-02-25 16:01:

Hi,

Sorry for not having produced these charter comments earlier as most would apply to earlier versions also. However, I do have a number of comments on it and think the charter could be restructured to become a much better charter. But lets start with the different comments.

The most fundamental issue with the charter is that it contains to much technical solution candidates, rather than talking about the goals and and general direction for achieving them. I think one needs to extract the few higher level goals from this list and work them into the charter in other ways. Certain things we likely can select, like RTP. But there is clearly a question on what profile and extensions that should be supported.

I also think one of the biggest uncertainties and fuzziness in the charter is because the model isn't agreed on. The discussion about the session management is clear due to that the model for the work aren't agreed on. I see two ways here. Either we manage to lock down the model prior to the chartering, or we have a charter that included this model discussion. Frankly I see the later as most likely as agreement on the model will require agreement with IETF's partner in this work. Thus the charter should take a bit more height for having such model discussion.

It is already obvious that any codec selection for this is going to be a difficult and possibly take time. To avoid this from de-railing the truly fundamental parts of the RTC-WEB solution, I am suggesting that this should be taken in its own WG, or if not possible at least as a separate WG item, with its own deadlines, so that it doesn't hold up the main work. That is likely anyway a good idea for long term purpose, so that only the codec selection part can be updated, and not the fundamental part when the set of codecs become out-dated.

I still don't understand the diffserv based QoS. This seems very unrealistic to be usable from a web-browser perspective. This as no device in any setting other than being an ISP controlled device is likely to be allowed to set DSCP. I think QoS can be excluded at this stage completely. Especially as there are a lack of methods for providing end-point devices with a traffic class to DSCP mapping valid in the currently attached network.

The charter could also be clearer on the need for basic datagram and byte stream functionality between two peers. The higher motivation for it is there, but not requirements. Where I see rate control and security of those channels being the most important ones.

I am also missing a clear requirement for enabling future extensions of functionality of the RTC-WEB components in the browser. I see this as important as we can hopefully arrive at the basic functionality reasonably quick, but there will be certain set of functionalities that are desirable but not quickly arrived agreed upon and specified. We need a method for enabling introduction of these in the future.

I also think one can clarify the last deliverable to actually be requirements on signaling and the API. Different functionalities will have different requirements when it comes to data objects needing exchange and also how the negotiation between the peers happens.

I am also missing a clearer requirement in ensuring that this becomes a network friendly traffic source. There is clearly need for congestion control and media adaptation as part of the basic solution.

As have been raised security is an important part of this work. I think we need to ensure that the WG first establish a security model, and then follows it in development. I fully agree that there should be no separate documents, this should be part of the general architecture, as it is such a fundamental part.

I am willing to provide an alternative charter proposal, if there is interest, attempting to take these comments into consideration.

Cheers

Magnus Westerlund

---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

-- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------