The SSRC parameter in the transport header has a few
unclarities.
- Why should a client be allowed to propose a SSRC to
the server?
- If allowed as current text indicates, what is the
requirement level on the server to follow the proposed
value. MAY or SHOULD.
First I would like to know the motivation a client has
to suggest a SSRC. This can probably not be removed but
unless there is good reasons for it I think the
requirement on a server to follow the request is MAY.
With a good motivation the level is SHOULD.
Logged In: YES
user_id=302620
Plan is to deprecate the behavior that a client is allowed
to specify SSRC to the server. See telecon minutes from 28
April 2003.
the behavior on how it shall be used will also be clarified.
See discussion on multiple SSRCs.
Logged In: YES
user_id=437699
To address this bug the following text has been added to
13.40 of bis04:
ssrc: The ssrc parameter, if included in a SETUP response,
indicates the RTP SSRC [23] value that will be used by the
media server for RTP packets within the stream. It is
expressed as an eight digit hexadecimal value. If the server
does not act as a synchronization source for stream data
(for instance, server is a translator, reflector, etc.) the
value will be the "packet sender's SSRC" that would have
been used in the RTCP Receiver Reports generated by the
server, regardless of whether the server actually generates
RTCP RRs. If there are multiple sources within the stream,
the ssrc parameter only indicates the value for a single
synchronization source. Other sources must be deduced from
the actual RTP/RTCP stream.
The functionality of specifying the ssrc parameter in a
SETUP request is deprecated as it is incompatible with the
specification of RTP in RFC 1889. If the parameter is
included in the transport header of a SETUP request, the
server MAY ignore it, and choose an appropriate SSRC for the
stream. It MAY set the ssrc parameter in the transport
header of the response.
Logged In: YES
user_id=302620
Has been resolved a long time. Closing issue.