[SR-Users] rtpengine returns 0.0.0.0 even with sendrecv in offer

[Richard Fuchs]

On 12/19/14 10:02, 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.
> 
> 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?

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