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
_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
