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

2 maj 2013 kl. 10:41 skrev "Karl Stahl" <karl.stahl@intertex.se>:

> If we discuss two-way communication as with RTC, retransmission of media is
> not a way forward!
When discussion retransmission of media you have to separate audio,
video and other types of media. For audio, it doesn't really help. For video
it might prevent a full frame update request, which is a good thing.

/O
> 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: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För Bo Burman
> Skickat: den 2 maj 2013 10:18
> Till: rtcweb@ietf.org
> Ä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: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On 
>> Behalf Of Roy, Radhika R CIV USARMY (US)
>> Sent: den 1 maj 2013 21:02
>> To: Randell Jesup; rtcweb@ietf.org
>> Subject: Re: [rtcweb] Network times . was SDP Security Descriptions 
>> (RFC 4568) and RTCWeb (UNCLASSIFIED)
>> 
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>> 
>> Inline [RRR]
>> 
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On 
>> Behalf Of Randell Jesup
>> Sent: Wednesday, May 01, 2013 2:19 PM
>> To: rtcweb@ietf.org
>> 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
>> randell-ietf@jesup.org
>> 
>> 
>> 
>> 
>> Classification: UNCLASSIFIED
>> Caveats: NONE
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb