[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] RTSP: Proxies and handling of unknown methods, headers and transport parameters
Thanks for the quick feedback.
I will try to write up some text changes for this today.
HAAS Christian skrev:
> Hello!
>
> -----Original Message-----
> From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On Behalf Of
> Magnus Westerlund
>
>> Methods:
>> [...]
>> Thus I suggest that we leave this as currently specified. Any objections?
>
> Sounds ok; I don't even see a problem with logging proxies, since their prime
> purpose is to log any message - and a minimum feature is grouping them
> together according to CSeq and/or Session Ids, which should be enough for any
> extension.
So you would like to point out that there are an exception for a very
particular sort of proxies?
>
>
>> Headers:
>> [...]
>> My proposal for proxies is that they forward unknown headers and when
>> defining a header that a proxy needs to understand one uses a feature
>> tag that is put in the Proxy-Require header. [...]
>
> Ok. Would there be some guidelines as to which types of proxies to consider
> for specifying a new feature (and its tag)?
Yes, I intended so.
>
>
>> Transport specifications:
>> [...]
>> A RTSP agent receiving a request with a Transport header SHALL
>> ignore all transport specifications that contains unknown transport
>> parameters. That way in case there are multiple transport
>> specifications in the header the entity can strip away the ones
>> that contains unknown things. [...]
>
> Does "strip away" for a (concerned) proxy mean filtering the unknown
> transport type out before passing the message on? (Or just "don't try to
> interpret, just pass it on")?
Yes, that becomes a requirement if you are pinning or translating the
transport. You will be required to understand what the client requests
because it will be the proxy that responds to what it does.
> For clarity, I'd suggest the writing that a concerned proxy removes
> transports unknown to it - if that leaves the header empty, an immediate
> Transport Not Supported response is generated.
> This is of course highly dependant on intercepting (and the presence of)
> corresponding Required headers...
>
Yes.
Cheers
Magnus Westerlund
IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Färögatan 6 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic