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

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)