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

[Richard Fuchs]

On 12/19/14 09:33, Juha Heinanen wrote:
> Richard Fuchs writes:
> 
>> On 12/19/14 03:32, Juha Heinanen wrote:
>>> 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.
> 
> 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.

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