Just ran into another complication on this. It seems that, even when running on an IPv6 network connected via Wifi on an iOS device, PJSIP places an IPv4 address in the outbound SDP. This is even with ipv6_media_use = true. However, when ICE is disabled, the address advertised in the SDP is indeed an IPv4 address.
I don't know that there's actually a permanent issue with this, as once ICE negotiation finishes I believe it'll switch correctly (some NAT issues I'm having right now are preventing the full call setup), but until that point, it results in "operation not permitted" errors being logged all over the place as it tries to send RTP packets to the default address, which has been rewritten to an IPv6 address, presumably because it opened an IPv4 socket locally. (Note that if I don't translate the IPv4 address, then I'll get network unreachable errors since the device doesn't actually have any default route on IPv4 when connected to this network).
Any idea why the default interface selection would be different on ICE than without? Without it seems to work fine.
Best,
Colin
On Sat, Nov 5, 2016 at 10:22 AM Colin Morelli <colin.morelli@xxxxxxxxx> wrote:
Alright, after more trial and error it seems like "use ICE" is the best answer. It still requires some modifications, but currently I've written a pjsip module to intercept the SDP and add additional ICE candidates with synthesized IPv6 addresses based on the IPv4 candidates in the list, when operating on an IPv6 network. Specifically, it only operates when a) the signaling transport is using IPv6, and b) the SDP does not already contain IPv6 addresses, so it should be safe to enable in almost any environment. If I get it finished up and working correctly I'll make it available and post here.However, this seems like something that could be baked into PJSIP. Is there any reason to not do pj_getaddrinfo on the RTP addresses in the SDP and see if a synthesized IPv6 is provided by the network stack? This is already done in many other places throughout the signaling stack, but not in pjmedia.Also, another thing that has made this more complicated - it seems that pjnath only resolves STUN hosts with IPv4 addresses. In NAT64 networks there may well not be any route for IPv4 traffic, which causes STUN bindings to fail in these environments. While in a perfect world, STUN wouldn't be needed in IPv6 networks, it is absolutely helpful in NAT64 networks where the client sees an IPv6 address for itself and the servers sees an IPv4 address. For now, I'm getting around this by just putting a blackhole media IP that satisfies the ICE requirements in the SDP and letting the B2BUA figure out the address based on the packet origin.Best,ColinOn Fri, Nov 4, 2016 at 6:32 PM Colin Morelli <colin.morelli@xxxxxxxxx> wrote:Hey all,I'm trying to resolve some issues with PJSIP on iOS in a NAT64 network. I believe I have mostly everything worked out except the media transport creation. As far as I can tell, the media options for IPv6 are either "on" or "off" with no dual stack option. Is there any way with pjmedia to attempt creation of both IPv4 and IPv6 transports, or defer creation of media transports until a response SDP is received to determine which to use?Perhaps the simpler question is: how can a dual-stack client know if ipv6_media_use should be true or false until it receives a response from the remote party that it's calling, indicating if that party supports IPv6 media or not?Best,Colin
_______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip@xxxxxxxxxxxxxxx http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
