[Bug 793441] rtsp-stream: client transport is not updated for multicast clients

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=793441

Sebastian Dröge (slomo) <slomo at coaxion.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #369330|none                        |reviewed
             status|                            |

--- Comment #44 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
Comment on attachment 369330
  --> https://bugzilla.gnome.org/attachment.cgi?id=369330
Let the first multicast request decide the ttl socket value

The spec says the following about this (RTSP 1.0):

   This request header indicates which transport protocol is to be used
   and configures its parameters such as destination address,
   compression, multicast time-to-live and destination port for a single
   stream. It sets those values not already determined by a presentation
   description.

For RTSP 2.0 it says the same but additionally also:

   ttl:  multicast time-to-live for IPv4.  When included in requests,
         the value indicates the TTL value that the client requests the
         server to use.  In a response, the value actually being used by
         the server is returned.  A server will need to consider what
         values that are reasonable and also the authority of the user
         to set this value.  Corresponding functions are not needed for
         IPv6 as the scoping is part of the IPv6 multicast address
         [RFC4291].


So I think always using the first one is not necessarily right. We should
probably use the maximum that is requested by a client, and have a server-side
limit for the maximum value a client can possibly request.

What do you think? This also seems relatively easy to implement.


The other important part is that we must report the actual TTL in the response
to the client, but I think that's already done correctly or not?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.