When the client has support for IPv6 the generated session description for initializing a audio call also includes IPv6 addresses in the candidate-attributes and in the session name and origin fields which is (most probably) the cause for the rejection with an "Unsupported session description" error.
With IPv6 enabled on the client try to start an audio call, but it gets rejected with "SIP/2.0 488 Not Acceptable Here" => 52063;reason="Unsupported session description" (see log excerpts).
Disable IPv6 on the (linux) client e.g. with
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
Retry an audio call and it works.
I tried to find the cause (and a fix as well) by inspecting the debug logs. Comparing the logs of incoming (=from a MS lync client) and outgoing (=to a MS lync client) calls the only major difference I could spot was the handling of IPv6 addresses in the sip session description.
I noticed that the MS lync client used "a=x-candidate-ipv6" as attribute for IPv6 addresses instead of just "a=candidate" (see also http://msdn.microsoft.com/en-us/library/hh642615(v=office.12).aspx).
Then I saw that the session name and origin fields also used an IPv6 address in them but as "IP4", which is obviously wrong. Therefore I tried disabling IPv6 on my host which then worked (see above).
Then I patched src/core/sdpmsg.c to use "x-candidate-ipv6"/"IP6" in the corresponding fields when dealing with a IPv6 address. But unfortunately that didn't help so I assume that either there needs to be some more modification to be done or (our) lync server doesn't support IPv6 properly.
But as the IPv6 addresses in the session descriptions are the only major differences I'm now quite sure that's the root cause for this problem (although the bug title now sounds more like voodoo...).
My guess is that that farstream/gstreamer/libnice/libpurple also need to support IPv6 to get this to work.
If they don't then the only possible work around in the code would be to detect IPv6 addresses and leave them out from the SDP message completely.
This was working in 1.17.0. The IPv6 candidate addresses were sent there but not the obviously bogus session name and origin fields. A quick hack to fix the latter by sending a hardcoded Legacy IP address instead of msg->ip doesn't work, though. I'll attempt to bisect and find where the regression was introduced.
Moving from an unsorted list, that is sorted when it is dumped, to a sorted candidate list changed the value of
msg->ip
insipe_media_to_sdpmsg()
. IMHO the code only happened to work by luck before, i.e. candidates with IPv4 addresses were added to the list first.This regression was introduced in 1.18.1.
This should be fixed in git commit 3966130 which updates the code to reject any IPv6 address strings.
@reporters: please verify the fix, because I never had any account where V&V worked.
Hey Stefan,
I tested [396613] with IPv6 enabled on the host and it worked for me and the call got successfully established.
So from my side this bug is now fixed, thank you very much! =)
Thanks for the feedback. CLOSING
Works here too. Apologies for the delayed response; I don't seem to be receiving all update emails from SourceForce for some reason.
Thanks.