Bug?: ICE Default Candidate

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey all,

I've been working with PJSIP in a NAT64 network to work out some issues I had been having. After switching to ICE, and writing a pjsip module to synthesize IPv6 addresses on inbound SDPs, I think I've gotten everything to work except one slightly annoying issue.

The default candidate selection for the ICE transport is too simple to account for this case. It checks first for a relay candidate, then a reflexive candidate, and finally falls back on the first local host candidate. The issue is that on a NAT64 network, the first two will be IPv4 addresses (since that's still what the world will see), and the first host candidate will likely be an IPv4 also, because pjmedia creates IPv4 transports and then creates the IPv6 ones.

The result is that, until ICE negotiation is complete, pjsip tries to send IPv6 packets from a local v4 socket, and continuously fails. This results in an audio delay, even when the remote party responds with a perfectly valid and directly routable single candidate.

I'm proposing an addition to the ICE transport that will re-select a default candidate that matches the address family of the default remote candidate it is trying to send to, after receiving the remote SDP. Is this a reasonable approach?

Best,
Colin
_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
pjsip@xxxxxxxxxxxxxxx
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux