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

["Karl Stahl" <[e-mail]>]

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?

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