Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED)

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

If we discuss two-way communication as with RTC, retransmission of media is
not a way forward!
We are already at around 500 ms round trip delay, which is close to the
tolerable limit for a conversation.

If you are thinking of streaming one-way media, that can (and do) use TCP
since a few seconds delay is no problem. That is not RTC.

/Karl


-----Ursprungligt meddelande-----
Från: [e-mail] [mailto:[e-mail]] För Bo Burman
Skickat: den 2 maj 2013 10:18
Till: [e-mail]
Ämne: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568)
and RTCWeb (UNCLASSIFIED)

I agree that delay-limited retransmission can be an appropriate
functionality also for media. Definitely for video, but maybe also for
audio. I expect that actual loss and delay requirements will depend on how
media (WebRTC) is used in the specific application use case, making it hard
to set one single delay requirement.

For SRTP traffic, would not RFC 4588 (RTP retransmission) provide a good
start, especially since you can set a maximum feasible (re-)transmission
delay limit on a per-call and per-media basis in the SDP?

/Bo B

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Roy, Radhika R CIV USARMY (US)
> Sent: den 1 maj 2013 21:02
> To: Randell Jesup; [e-mail]
> Subject: Re: [rtcweb] Network times . was SDP Security Descriptions 
> (RFC 4568) and RTCWeb (UNCLASSIFIED)
> 
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
> Inline [RRR]
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Randell Jesup
> Sent: Wednesday, May 01, 2013 2:19 PM
> To: [e-mail]
> Subject: Re: [rtcweb] Network times . was SDP Security Descriptions 
> (RFC
> 4568) and RTCWeb (UNCLASSIFIED)
> 
> On 5/1/2013 4:46 AM, Roy, Radhika R CIV USARMY (US) wrote:
> > I am responding only on a part of this email about retransmissions 
> > of audio or video packets.
> >
> > Let us not consider the retransmission of audio or video packets. 
> > Let us consider audio or video packets are sent only over UDP. Let 
> > MOS/QoS of audio or video are considered in a way that 
> > retransmissions do not take
> place.
> >
> > Then the question comes only about "data" traffic retransmissions.
> > Data traffic can tolerate much higher delays than that of audio or 
> > video. Data has only QoS (and no MOS).
> 
> It may not have MOS per-se, but unreliable data channels have 
> equivalent issues - think of a first-person realtime game - unreliable 
> position/state updates of the user and the world mean that what data is
lost (and how much data is delayed but received) has a very strong impact on
the user's perception of the world.
> 
> [RRR] Yes, we need to have NEW threshold of delays (RTT) for data
performance.
> --
> Randell Jesup
> [e-mail]
> 
> 
> 
> 
> Classification: UNCLASSIFIED
> Caveats: NONE

_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb