19 Dec
2014
19 Dec
'14
4:47 p.m.
On 12/19/14 09:33, Juha Heinanen wrote:
Richard Fuchs writes:
Yes I understand, but 1) the mechanism of using 0.0.0.0 to put a call on
hold must remain operational and intact for those clients which use it,
and 2) if the offering client sends 0.0.0.0 in the SDP, then the
rewritten SDP should also contain 0.0.0.0, no matter what the purpose
behind it is.
cheers
On 12/19/14 03:32, Juha Heinanen wrote:
what i understand from rfc3264 is that 0.0.0.0 address in initial invite
does not mean that the call is on hold. 0.0.0.0 is used because webrtc
client does not know its ip address:
RFC 2543 [10] specified that placing a user on hold was accomplished
by setting the connection address to 0.0.0.0. Its usage for putting
a call on hold is no longer recommended, since it doesn't allow for
RTCP to be used with held streams, doesn't work with IPv6, and breaks
with connection oriented media. However, it can be useful in an
initial offer when the offerer knows it wants to use a particular set
of media streams and formats, but doesn't know the addresses and
ports at the time of the offer.
also, if the call would on hold, there would be sendonly attribute in
the sdp, which is not the case in my example, which had sendrecv. i got mozilla to generate sdp with sendrecv, but
still rtpengine does
not replace 0.0.0.0 address on o and c lines. why?
Because 0.0.0.0 means steam is on hold and so should be left in place.