I’m doing some playing around with Asterisk behind a cloud load balancer. One scenario I tested was using a SIP IPv4 UDP transport and RTP IPv6 media.
The issue I’ve encountered is that when setting the external_media_address to an IPv6 address the SDP produced by asterisk is incorrectly setting the address type to IP4 instead of IP6 which causes the Bria softphone I’m testing with to immediately cancel the call.
What do you think this will accomplish? Because I doubt this can be done. You can’t mix IPv4 and IPv6 in the SIP message. You’re doing one or the other.
What do you think this will accomplish? Because I doubt this can be done. You can’t mix IPv4 and IPv6 in the SIP message. You’re doing one or the other.
At a protocol level SIP and RTP are completely separate and it definitely is possible to use SIP signalling over IPv4 and RTP over IPv6. I’m able to do this already with other set ups.
My post is to point out that the SDP produced by Asterisk is invalid. Irrespective of anything else SDP requires that the network type matches the advertised address. The line below from the Asterisk SDP answer is wrong:
I don’t think external_media_address has ever been tested/used for IPv6. As well, having IPv6 for SDP and IPv4 for signaling while supported by SIP isn’t really supported by us. I asked about this at a SIPit event, and other vendors and teams agreed at having them both be the same.
Ok, thanks for clarifying. At least it’s not something I’m configuring wrong.
I don’t think external_media_address has ever been tested/used for IPv6.
It has now .
It does seem to work fine except for the bug mentioned above. If I use a different SIP client that ignores the mismatch between the internet type and the actual address in the SDP I do get RTP from Asterisk via IPv6.
I suspect this is not something that will crop up very often with standard SIP calls but if there’s a bug somewhere in the SDP processing it may also crop up with SIP + ICE.