[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lemonade] WGLC streaming - update; comments



Neil,
I have some comments vs. Yours.

>> 3. Section 1, paragraph one: "Email clients on resource..:"
>> I am not sure how streaming helps network contstrained devices since 
>> streaming might be more network-demanding in some cases than a slow 
>> fetch. I thought the whole reason of doing streaming was:
>> not to download and store stream-able attachments at all. I've seen 
>> streaming on slow networks, and I can tell that I would rather wait 
>> longer to retrieve it slowly in the background without streaming.
>> Looking at the phone and waiting for new frames to be drawn is
>> just: bad. Even today, in my office where there is gigabits of 
>> bandwidth I still have to wait for some streams for pre-load 
>more than 
>> half of the movies (not because there is a network limit, 
>not because 
>> there is a client limit, but because there are limitations on the 
>> server.) Therefore, I suggest removing any hints about doing this 
>> because there is not enough bandwidth.

>I'm not sure I agree. There are plenty of scenarios where 
>streaming is more network efficient. If someone sends me a 
>very high definition movie or audio clip, but that clip is 
>streamed to my device rather than retrieved, I can 
>watch/listen to it in a fraction of the time it would have 
>taken to download it, because streaming almost always means 
>transcoding to a lower quality suitable for the device.

Hmm, yes. But then I have to say that I do not know what You mean by
constrained network. I've never seen a clip played without hickups - and
in some cases I did not even want to watch it: having to wait 1-5secs
for a few frames to arrive (video looks like a slideshow). I think
streaming saves sudden spikes in bandwidth (a more balanced network
utilization): download all vs. download frame-by-frame.
But I guess arguing over this is not worth our time since it's not a
major issue.

>> 8. Question regarding Figure 1: Shouldn't all arrows be 
>double-headed?
>
>Theoretically yes, but I hoping to make initiation implicitly clear.

Could we decribe this fact somehow? (To aviod questions like mine.)

>> 21. 2.5 last paragraph:
>> 404 does not seem to be sufficient - a single status code 
>covering all 
>> possible errors is not very useful. Is there any way to indicate to 
>> the client what very wrong (really)?
>
>Theoretically the media server could return a number of SIP 
>error code, but this document doesn't attempt to cover all of 
>them. It just explains what that particular error code means.

It is more like an example then, right?

Thank You Neil!

_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade