[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