Re: [Wish] Initial comments on draft-murillo-whip-02

[Christer Holmberg <[e-mail]>]

Hi,

>> I would prefer to add as few optionalities to the protocol as possible. It would be trivial for the server
>> to just return the current URL and not to have to test each interoperability with each client for both 
>> when the location header is present or not.
>> 
>>I just think it is not a good idea to make changes to core HTTP, so in my opinion it is more about HTTP interoperability than WHIP interoperability.
>
>And, what if you are using an HTTP library that will remove the header if the endpoint isn't changed?
>
>Can you point me to the HTTP spec that defines that behaviour of the Link attribute? 

I assume you mean Location header? I have not commented on any Link attribute :)

The semantics of the Location header, in a 201 (Created) response is that a NEW resource has been created. As far as I know, if a new resource is NOT created, HTTP does not mandate a Location header to be included in the 201 response.

I can look if this is explicitly defined somewhere, but if there is someone having better HTTP knowledge than myself he/she may want to chime in.

---

>> In terms of features, the WHIP protocol matches the ones offered by RTMP which is still widely used
>> and offered on most profesional hardware encoders and main open source broadcasting software
>> (i.e. ffmpeg/OBS/vmixer/...). Not sure how that is not suited for "professional usages". 
>>
> RTMP supports PAUSE, RESUME etc commands, doesn't it? :)
>
> Hard to know as AMF commands on top of RTMP are quite undocumented. If you do some archeology on action script reference you can see that the play/pause are commands send from the player to the media server when reproducing a video, they are not intended to be used for the publish command:
>
> https://protect2.fireeye.com/v1/url?k=972f57bf-c8b46e83-972f1724-86b1886cfa64-94d0ba57ffd7f0e9&q=1&e=6b5239de-60be-4332-8f7c-cc2e3371d5b9&u=https%3A%2F%2Fhelp.adobe.com%2Fen_US%2FFlashPlatform%2Freference%2Factionscript%2F3%2Fflash%2Fnet%2FNetStream.html%23publish%28%29

You may be right, and I haven't debugged any RTMP app in order to see what exactly is sent. Just because my app has a button that says "PAUSE" it doesn't mean it triggers an RTMP Pause command :) 

However, my main issue is not the specific PAUSE and RESUME commands, but the generic ability of being able to send commands in the first place. 

>> Let me explain how the sport event ingestion software I am using works:
>>
>> First you establish the session, choose what sports event you are going to stream etc.
>>
>> After that, the media ingestion starts. But, the server does not start the broadcasting of the media yet. It only broadcasts the stream to the one doing the ingestion, so that he/she can check that everything works.
>>
>> After that, the user sends a command to the server to start the actual broadcasting.
>>
>> Etc.
>>
>> So, the user has explicit control of when the actual broadcasting begins, even if the media ingestion has began earlier.
>>
>> As I am not the implementer of the software I don't know all the protocol level details, other than it uses RTMP.
>
> That workflow makes a lot of sense, but not sure how it maps the pause/resume operation. Typically you will control it from a control panel on the server side which is not at the encoder. 

The above is probably a bad example for PAUSE/RESUME. In the app there is a "PAUSE/RESUME" button, but it does not affect the media ingestion and broadcasting. It only affects the sports game watch (which runs in the server).

But, the example shows the usage of commands for controlling different steps (ingest-no-broadcast, ingest-with-broadcast etc). In WHIP, as far as the server is concerned, the ingestion and broadcasting will start once the O/A and ICE procedure has concluded.

---

>>> Regarding the metadata exchanged during the session, which could be done either by datachannel
>>> or by a new whip protocol extension with another http url, 
>>
>> I had a datachannel in mind, and that's why I asked about it earlier :)
>>
>> But, if commands are outside the scope of WHIP, I think it would be good to explcitly say it.
>
> The way I see it, the problem again is defining and standardizing the metadata, not about how to transport it. We can state that it is not supported by this WHIP version.

I was not thinking about standardizing all metadata, but more about a framework with e.g., an IANA registry where commands/meta-data can be registered.

BUT, having said all that, if the community thinks it's outside the scope of this WHIP version, I will not argue against that. I do think it would be good to document, though, because I think it is useful information for implementers evaluating different protocols etc.

Regards,

Christer