Sorry, but this bug report does not follow the instructions given in the FAQ. Therefore nobody will be able to figure out if there is a problem and how to address it.
According to the policy described in the FAQ this report will be closed as INVALID. The project maintainers will consider re-opening it if the missing information has been provided by the reporter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know why M$ puts IPv6 addresses into the DNS for servers which do not accept IPv6 addresses in their protocol.
IMHO this is no regression, because the previous code was worse, i.e. it was guessing and could return e.g. 127.0.0.1 which was definitely incorrect. Now the IP address is always correct, because we request it from a connected socket.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I went to an IPV6 tunnel provider and created an account there. Now that the IPv6 tunnel is active on my machine SIPE connects to the SIP server for my company account using an IPv6 address. The debug log shows the same error message as discussed here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tested with 2 different Office 365 accounts while IPv6 tunnel was active / inactive. Works OK now for local transport IPv6 or IPv4 address.
Interestingly only the frontend servers, i.e. those that redirect to the home server after successful authentication, seem to have IPv6 addresses. The home servers in my tests only have an IPv4 address.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, but this bug report does not follow the instructions given in the FAQ. Therefore nobody will be able to figure out if there is a problem and how to address it.
According to the policy described in the FAQ this report will be closed as INVALID. The project maintainers will consider re-opening it if the missing information has been provided by the reporter.
Debug generation instructions are not clear. Do you want the command line output as the log or something else? Please clarify.
Client: Pidgin - 2.12.0
Generating debug log now
Had to upgrade back to the new version first, still generating logs
Assuming this is the log file, here ya go!
Your system connects with IPv6 to the Lync server, hence the address of the local SIP socket is also an IPv6 address:
As far as I know Lync servers do currently not accept IPv6 addresses in the SIP protocol, hence our REGISTER attempt is rejected with:
You'll need to fix your setup to connect to
sipfed2a.online.lync.comvia an IPv4 address.See also the code change included in the release 1.22.0.
Could you please be more specific? Do you mean the account settings? Are you saying I should force the server address and no longer use auto discover?
Setting sipfed2a.online.lync.com as the server address does not seem to work.
Name resolution, e.g. DNS, is a system setting. Hence any change to SIPE or Pidgin most likely won't do the trick.
One drastic measure of course would be to disable IPv6 on your system.
Other options would rely on to find the IPv4 of the server. Here is what I get on my system:
You could try to use the IPv4 address directly in SIPE or add the name & IPv4 address to your /etc/hosts to override the DNS resolution.
Tried to use 52.112.67.51, was promted to accept a new SSL certificate but no dice.
I would need to see a log from that attempt to check where it fails now.
Doesn't even seem to get as far as authenticating before the connection is reset
BTW: the log has been generated without
PURPLE_UNSAFE_DEBUG=1.You forgot to use the correct server port
443, so SIPE falls back to the default for SSL SIP port5061.Forcing the ipv4 address and port 443 is a valid workaround.
This still seems like a regression for the autodiscover setting.
Last edit: Stephen Tanner 2017-06-21
I don't know why M$ puts IPv6 addresses into the DNS for servers which do not accept IPv6 addresses in their protocol.
IMHO this is no regression, because the previous code was worse, i.e. it was guessing and could return e.g.
127.0.0.1which was definitely incorrect. Now the IP address is always correct, because we request it from a connected socket.Ticket moved from /p/sipe/bugs/325/
Can't be converted:
It could be that IPv6 addresses need a different format, see
I will need to look into that, but I won't be able to test it myself.
I went to an IPV6 tunnel provider and created an account there. Now that the IPv6 tunnel is active on my machine SIPE connects to the SIP server for my company account using an IPv6 address. The debug log shows the same error message as discussed here.
Also SDP message generation must be updated to remove hard-coded "IP4" string. IPv6 addresses require "IP6" address marker.
Implemented in git commit f6a0e9d
Tested with 2 different Office 365 accounts while IPv6 tunnel was active / inactive. Works OK now for local transport IPv6 or IPv4 address.
Interestingly only the frontend servers, i.e. those that redirect to the home server after successful authentication, seem to have IPv6 addresses. The home servers in my tests only have an IPv4 address.