Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

[Dan Wing <[e-mail]>]

On Sep 21, 2013, at 2:44 PM, Karl Stahl <[e-mail]> wrote:

> Yet another thing related to
> draft-ietf-rtcweb-use-cases-and-requirements-11:
> It is about payload type, PT=, in SDP and RTP, so I am copying MMUSIC
> 
> Network service providers have expressed an interest to know whether packets
> carry audio or video, to be able to handle them differently in the network
> (e.g. quality wise). PT is visible outside the encrypted payload in RTP,
> however if dynamic payload types PT:96-127 are used, you cannot know what
> the payload is without knowledge of the SDP (which we for WebRTC must assume
> the network provider has no knowledge of).
> 
> In http://www.ietf.org/assignments/rtp-parameters/rtp-parameters.xml I see
> no PTs defined for Opus, VP8, H.264 etc. considered for WebRTC.
> 
> So, can we have payload types assigned to codecs that will be recommended
> for WebRTC (PT:35-71 are unassigned)?
> Or can we at least split dynamic payload types PT:96-127 into groups for
> audio and video codecs?
> 
> 
> I relation to that simple request, one may wonder how the network anyway can
> know what is carried in an UPD packet (the RTP header is no reserved field -
> it could be the payload of something else).
> 
> Quality related requirements F38, A23 and A26 in the use case draft,
> nowadays only seem to relate to the browsers, not assuming that diffserve
> bits or similar are conveyed to the network. That is realistic, since most
> operating systems don't allow quality markings (diffserve, TOS) of packets.
> However, 3.2.1.  Simple Video Communication Service, mentions "The web
> service monitors the quality of the service (focus on quality of audio and
> video) the end-users experience.". I don't understand how "The *web service*
> monitors" based on the listed requirements. Should it be "The *browsers*
> monitors"?
> 
> What are then the possibilities for a network to classify traffic for
> quality or other purposes?

I agree there is a problem here, and have been trying to convince others there is a problem that needs to be solved.  So far, there appears to be scant agreement there is a problem.  See thread on TSVWG starting at http://www.ietf.org/mail-archive/web/tsvwg/current/msg12182.html.  The solution I am pitching is an extension to PCP, draft-wing-pcp-flowdata.  Another solution is MALICE which adds information to the ICE connectivity checks (bandwidth, drop preference, etc.) which can be DPI'd by network devices.

But before getting deep on solutions, we first we need some consensus that some flows need different handling than other flows, and then acquiescence that existing techniques do not solve the problem (RSVP, NSIS, Diffserv).  Unfortunately the industry doesn't yet seem to agree there is even a problem.

-d


> 
> 3G/4G networks have DPIs (Deep Packet Inspection) - such box may guess what
> encrypted RTP traffic is... or may not...
> 
> Real time communication protocols using ICE as a pre-protocol to establish
> media paths give a possibility though. If the network provider offers a TURN
> server at his access, and enforces the TURN server to be used (by eating
> STUN packets), then the RTP flows set up through the TURN server could
> classify and mark packets. Then it is useful to know whether it is an audio
> or video packet by looking at the payload type.
> 
> A LAN firewall, can also include a TURN-server, that in addition to
> classifying and marking packets for the transport network (if honored -
> which rarely is the case on the Internet today), it can also prioritize and
> traffic shape so the RTP traffic at least is undisturbed through a data
> crowded Internet access.
> 
> A more difficult request comes from networks using bandwidth reservation
> (RSVP) for quality, like mobile and cable networks. Such networks would
> benefit from knowing the bandwidth used, but that is not fixes for advanced
> codecs like the ones considered for WebRTC. One way would be to reserve
> maximum bandwidth, and possibly repeat the reservation if less is actually
> used.
> 
> /Karl
> 
> 
> -----Ursprungligt meddelande-----
> Från: [e-mail] [mailto:[e-mail]] För Karl
> Stahl
> Skickat: den 21 september 2013 02:16
> Till: [e-mail];
> [e-mail]
> Ämne: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
> 
> While reading the draft-ietf-rtcweb-use-cases-and-requirements-11, here are
> a few "telephony related" WebRTC things I think should be clarified in the
> use cases. 
> 
> 
> 3.2.1.  Simple Video Communication Service 3.2.1.1.  Description ...  
> The invited user might accept or reject the session. 
> [Suggest adding] The invited user might accept only audio, rejecting video
> (even if a camera is enabled). A user may also select to initiate an audio
> session, without video.
> 
> And in API requirements:
>   ----------------------------------------------------------------
>   A1      The Web API must provide means for the application to ask the
> browser for permission to use cameras and microphones, individually as input
> devices. (One must be able to answer with voice only - declining video.)
>   ----------------------------------------------------------------
> Same under
> 6.2.  Browser Considerations
> ...
> The browser is expected to provide mechanisms for users to revise and even
> completely revoke consent to use device resources such as camera and
> microphone. [Suggest adding] Specifically, a user must be given the
> opportunity to only accept audio in a video call invitation.
> 
> 
> 
> 3.2.12.  Multiparty video communication
> 3.2.12.1.  Description
> ...
> [Suggest adding] It is essential that automatic adjustments of microphone
> volume is disabled, or microphones not spoken into are muted. (This is a
> serious problem with most soft clients (SIP clients) of today, plaguing
> conferences with ever increasing noise from silent participants.)
> 
> And in API requirements:
>   ----------------------------------------------------------------
>   A15     The Web API must provide means for the web application to adjust
> the level in audio streams.
>  ----------------------------------------------------------------
>   Axx     The Web API must provide means to disable any automatic volume
> adjustment in the sent audio streams. (To avoid disturbing noise in
> conferences - making many softclients unusable). 
>   ----------------------------------------------------------------
> 
> 
> 
> 3.2.6.  Simple Video Communication Service, access change 3.2.6.1.
> Description ...
> the user has to start a trip during the session. The communication device
> automatically changes to use WiFi when the Ethernet cable is removed and
> then moves to cellular access to the Internet when moving out of WiFi
> coverage.  The session continues even though the access method changes.
> 
> [Question] Is this some sort of roaming without network support (please
> clarify)? Getting a new access will also give the client a new IP address,
> won't it? How could then the session continue? The browsers will have no
> signaling connection and cannot renegotiate a media connection, can they?
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb