19 Dec
2014
19 Dec
'14
5:34 p.m.
On 12/19/14 10:02, Juha Heinanen wrote:
Richard Fuchs writes:
I don't see how it would make a difference. If Firefox sends 0.0.0.0 and
rtpengine replaces it with its own address, then the receiving client
can send media to rtpengine, but rtpengine would have nowhere to forward
it to. After the answer, ICE processing may commence and determine an IP
address, after which I expect Firefox to send an updated offer with the
address filled in. At this point, media should start to flow no matter what.
I'm not sure how much of a valid use-case this is, or if it'd be just a
Firefox-specific workaround, but my all means, give it a try and see if
it makes a difference.
cheers
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.
So with current implementation of rtpengine there is no hope if Firefox
webrtc client needs rtpengine services?
If so, would it be possible have a new flag that tells rtpengine to
replace also 0.0.0.0 address if there is no sendonly attribute in sdp?