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