[sr-dev] RTPEngine in reINVITE/on-hold use case

[Richard Fuchs]

On 21/07/14 07:00 AM, Waite, Hugh wrote:
> Hi,
>
> I updated to the latest from git but it didn't improve the situation with null IP addresses from the non-webRTC client. In fact, rtpengine sent some ICE candidate lines with null IP's.
> We decided we don't need to worry about clients that use the null IP mechanism for on-hold, so I sent some simulated traffic with sipp that has real IP addresses and uses a=sendonly/inactive. These results were better.
>
> With the latest rtpengine version (as of 21/7/14), the initial invite towards Chrome uses a=setup:actpass for the DTLS handshake, as required. In the reINVITE, it uses a=setup:passive. Chrome rejects this because it isn't actpass.
> I can see the code that works out the setup direction string in sdp.c:1600 based on the active/passive flags. Should the value always be "actpass" if we are making an offer? (RFC5763 §5)

Yes it should be, call.c:1724 is supposed to take care of that. But I 
just noticed that this part can get skipped erroneously. Will fix, thx.

cheers