Activity for Stefan Becker
-
Stefan Becker modified a comment on ticket #364
Well then un-delete it, as this is a packaging problem, see [bugs:#365]
-
Well then un-delete it, as this is packaging problem, see [bugs:#365]
-
Well then un-delete it, as the this is packaging problem, see [bugs:#365]
-
Doesn't build anymore
-
Already fixed by the following commits utils: add sipe_utils_memdup() core: replace g_memdup() with sipe_utils_memdup() It is the task of a package maintainer to pick up such fixes, f.ex. as was done in Fedora Closing as INVALID.
-
Looks like pidgin-sipe was dropped from Arch Linux. Closing as WONTFIX.
-
Dead link for Arch Linux
-
Are you sure your customer actually uses SfB (Skype for Business) and not Teams? I'm not aware that there are "workspaces" in SfB. Office 365/SfB and Teams are two separate things. SIPE can only talk to SfB.
-
MS Teams is a completely different beast. It would not be a good idea to graft a completely different implementation onto the existing code base. 2nd thing (which I have to admit I haven't look into at all): is the MS Teams API public and documented? M$ could probably just say "we do the same thing as Slack, etc. Just use the web app...".
-
... or install a proxy on your local machine and point Pidgin to it. The proxy must fulfill three requirements it must be able to tunnel proxy request to another HTTP CONNECT proxy it must have a black or white list to decide when to pass on to the proxy or connect directly (i.e. proxying by itself) be transparent (well more transparent then the HTTP CONNECT proxy you obviously have)
-
Well, if login.microsoft.com is the only address that you would need proxying for, then you could try to hard-code the name in /etc/hosts to address 127.0.0.1 and then run a proxy tunnel script on port 443 on your local machine. The tunnel would then need to talk to the real HTTP CONNECT proxy to get outside. I.e. https://login.microsoft.com:443/ -> script on localhost -> HTTP CONNECT proxy -> outside.
-
Yes, the response indicates that you have an ADFS setup: <STSAuthURL>https://adfs.us.DUMMYCOMPANY.com/adfs/services/trust/2005/usernamemixed</STSAuthURL> So in your setup only HTTP would need to be proxied, which libpurple currently doesn't support. I also checked the libpurple API again and there is no programmatical way to disable proxy settings for a certain connection, i.e. so that SIPE could request no proxy for SIP connections. I don't have Pidgin in front of me, but I'm assuming that the proxy...
-
Guessing from your latest log I fear the HTTP CONNECT proxy isn't transparent enough for SIP connections. The connection is dropped while the first SIP response is received: MESSAGE END >>>>>>>>>> SIP(0x16b98d0) - 2020-08-26T14:45:57.039861Z (09:45:57) sipe: transport_input_common: new buffer length 4096 (09:45:57) sipe: transport_input_common: new buffer length 8192 (09:45:57) sipe: Server has disconnected Can you post the XML response from https://login.microsoftonline.com/getuserrealm.srf?login=DUMMYUSER@DUMMYCOMPANY.com&xml=1,...
-
The SIP server is probably correct now. SIPE tries to query the following URL https://login.microsoftonline.com/getuserrealm.srf?login=DUMMYUSER@DUMMYCOMPANY.com&xml=1 to determine the ADFS setup for your account. Your network prevents that. As I don't know your real email address I can't tell what the response is.
-
webdir.online.gov.skypeforbusiness.us:443 is a HTTP server, that can't be the correct server. Try sipdir.online.gov.skypeforbusiness.us:443 or :5061 (unlikely though...) , both ports seem to answer. Please also set the User Agent field. I'm not aware of any Lync installation that allows non-M$ clients.
-
While the 2nd attempt looks in general more successful it is in the end rejected with User is not provisioned in this deployment. i.e. the system rejects the given SIP URI. If you are sure that you are using the correct SIP URI then another suggestion indicated by both logs would be that the server auto-discover doesn't work in your case. Lync auto-discover fails in both logs, and the older DNS method results in sipint1.008f.federal.lync.com:5061 which rejects your login attempts (the port number...
-
While the 2nd attempt looks in general more successful it is in the end rejected with User is not provisioned in this deployment. i.e. the system rejects the given SIP URI. If you are sure that you are using the correct SIP URI then another suggestion indicated by both logs would be that the server auto-discover doesn't work in your case. Lync auto-discover fails in both logs, and the older DNS method results in sipint1.008f.federal.lync.com port: 5061 which rejects your login attempts (the port...
-
Thanks for the log. According to the log, attempts to acquire an authentication ticket are rejected with Error 500 and the message The SIP URI in the claim type requirements of the web ticket request does not match the SIP URI associated with the presented credentials. Your account is set up only with your E-Mail address. Are you sure your E-Mail address is also your SIP URI? Maybe it has been changed during the ugrade. The E-Mail address (as login name) & password seem to be correct, because NTLM...
-
I don't get it. Why should that be relevant? I just followed the bug reporting instructions.
-
Sipe suddenly stopped working.
-
Closing as INVALID.
-
I'm taking an educated guess here: a detailed SIPE log with libnice git HEAD will show that the private IPs are no longer returned as valid candidates by libnice, i.e. they will no longer be included in the INVITE sent by SIPE when your side initiates the call. a detailed libnice log will show that the ICE handshakre requires roughly 15 seconds to determine that the private IPs are no valid candidates. IMHO your issue is solved then.
-
libnice 0.1.14 is obsolete. I doubt they will act on the report unless you can reproduce it with 0.1.16 or even better git HEAD.
-
libpurple API does not support IPv6, hence the code was replaced, see commit purple: update sipe_backend_transport_ip_address(). The code determines the IP address from the SIP connection socket which in your log shows f.ex.: (15:36:32) sipe: transport_get_socket_info: 10.202.77.9:55432(0x55eab8fae430) So as far as I understand from your report SIPE does use the correct IP internally, e.g. in SIP message creation. The rest of the issues you describe are most likely related to libnice, not SIPE. That...
-
libpurple API does not support IPv6, hence the code was replaced, see commit purple: update sipe_backend_transport_ip_address(). The code determines the IP address from the SIP connection socket which in your log shows f.ex.: (15:36:32) sipe: transport_get_socket_info: 10.202.77.9:55432(0x55eab8fae430) So as far as I understand from your report SIPE does use the correct IP internally, e.g. in SIP message creation. The rest of the issues you describe are most likely related to libnice, not SIPE. That...
-
libpurple API does not support IPv6, hence the code was replaced, see commit purple: update sipe_backend_transport_ip_address(). The code determines the IP address from the SIP connection socket which in your lock shows f.ex.: (15:36:32) sipe: transport_get_socket_info: 10.202.77.9:55432(0x55eab8fae430) So as far as I understand from your report SIPE does use the correct IP internally, e.g. in SIP message creation. The rest of the issues you describe are most likely related to libnice, not SIPE....
-
SIPE currently ignores the local IP address configured in Pidgin, making it impossible to use with a corporate server that is reachable only via VPN
-
libpurple API does not support IPv6, hence the code was replaced, see commit purple: update sipe_backend_transport_ip_address(). The code determines the IP address from the SIP connection socket which in your lock shows f.ex.: (15:36:32) sipe: transport_get_socket_info: 10.202.77.9:55432(0x55eab8fae430) So as far as I understand from your report SIPE does use the correct IP internally, e.g. in SIP message creation. The rest of the issues you describe are most likely related to libnice, not SIPE....
-
No, not really, as there is no information to go on, e.g. version numbers of the relevant SW packages. Have you considered studying the FAQ page?
-
Is there any good reason why automake has to be 1.16?
-
I don't remember the exact reason, but this was part of the configure.ac cleanup for i18n tools. None of the tested platforms has an issue with that and normal users should use a prebuilt package or the release tarball, not build from git. Closing as NOTABUG.
-
Yeah, log shows that you can't authenticate with that account information to Office 365. You probably have to talk to your IT admins: what kind of Lync installation do you use? Internal (i.e. on company servers) or external (i.e. Office 365)? if external: what is your account for that (your log shows that you are trying to use some internal Windows AD account for authentication, which most likely won't work, because Offcie 365 doesn't have an ADFS for the given account domain) if external: have you...
-
Thanks for the log. User name and password seem to be correct, at least when trying to authenticate with NTLM against the HTTP server uccweb.ruag.com. What does not seem to work is the Lync autodiscover process. There are timeouts, that's why it takes so long (> 2 minutes according to the log). It then falls back to the old autodiscover method, which detects sips4b.ruag.com:443 as server. SIPE tries to run the authentication handshake but that fails: (11:17:42) sipe: sipe_http_parse_uri: host 'uccweb.ruag.com'...
-
Sipe audio call test always fail with message: audio test service not available
-
That's normal behaviour, i.e. the feature isn't available in your installation. I'm not sure if this is visible from the provided configuration information, i.e. if it would be possible to hide the menu. Jakub would maybe know. But as new feature development is on hold I doubt that it would ever be implemented. Closing as NOTABUG.
-
The functionality you are looking for isn't SIPE specific. Hence you need to look up the correct libpurple DBus interface and call that in your script.
-
Are you sure you are using plain xfreerdp client instead of remmina? Have you tried starting the remmina client and play with its settings, probably before startin a screen sharing session?
-
Most likely the same issue as [bugs:#359]
-
I guess the collab PPA is dead. Have you tried the link to Open Build System link from the project web page?
-
Just to make sure: what does About SIPE plugin... say? Does it include Application Sharing in the feature list? If it does, then your description doesn't sound like a missing client, but more like a network connection that can't be established. That would point to nice/farstream/gstreamer. Please make sure to read the FAQ page for a list of required gstreamer plugins. Your package list indicates several outdated components that could be causing this issue. Compare your versions with the ones available...
-
I also vaguely remember that the M$ client has some builtin magic that triggers the account migration from old contact list to UCS when the organization moves to the new system. I don't know what that magic is, hence SIPE can't trigger it. If your account is "old" and your organization moved to a newer installation then you could try to start the M$ client, login with your account and afterwards try if address search works with SIPE. If I remember correctly that should be visible in the log when...
-
Thanks for the log. But the log only shows the broken functionality (i.e. SIPE tries addressbook via SIP, not EWS search), not why it doesn't use EWS. That would happen at login time, The error 488 that you see in the other (working) logs happens when SIPE tries to subscribe to the contacts list event (vnd-microsoft-roaming-contacts). The next log line will tell you no contact list available - assuming Lync 2013+ and Unified Contact Store (UCS), i.e. SIPE will switch to Lync 2013+/UCS mode. You'll...
-
SfB should not use old-style address book, but EWS (Exchange Web Services). That is usually autoconfigured via setup information provided by your IT admins, but if it fails you can configure the email settings in the advanced tab by hand. F.ex. what happens if you go to the SIPE context menu and select "publish calendar"? Do you get an error message? If you can provide a detailed(!) --debug log (see FAQ) from your login process theb I can have a look what might be going wrong. Usually it is a mis-configuration...
-
That is rather strange, because in Fedora's pidgin-sipe.spec it says: %package -n purple-sipe Summary: Libpurple protocol plugin to connect to MS Office Communicator License: GPL-2.0-or-later Requires: gssntlmssp >= 0.5.0 i.e. when you execute dnf install pidgin-sipe on Fedora it will automatically install gssntlmssp. Did you build pidgin-sipe yourself? I don't think pam_cifscreds has anything to do with your problem.
-
Thanks for the log. The log shows a Kerberos error when SIPE tries to authenticate HTTP requests, e.g.: (17:47:28) sipe: sipe_http_parse_uri: host 's4bwebinternal.gastao.com.br' port 443 path 'WebTicket/WebTicketService.svc' ... (17:47:28) sipe: sip_sec_acquire_cred__gssapi: username 'ota.pera@GRUPOGASTAO.COM.BR' (17:47:28) sipe: sip_sec_gssapi: GSSAPI error in gss_acquire_cred_with_password (GSS): Unspecified GSS failure. Minor code may provide more information (17:47:28) sipe: sip_sec_gssapi: GSSAPI...
-
Thanks for the log. The log shows a Kerberos error when SIPE tries to authenticate HTTP requests, e.g.: (17:47:28) sipe: sipe_http_parse_uri: host 's4bwebinternal.gastao.com.br' port 443 path 'WebTicket/WebTicketService.svc' ... (17:47:28) sipe: sip_sec_acquire_cred__gssapi: username 'ota.pera@GRUPOGASTAO.COM.BR' (17:47:28) sipe: sip_sec_gssapi: GSSAPI error in gss_acquire_cred_with_password (GSS): Unspecified GSS failure. Minor code may provide more information (17:47:28) sipe: sip_sec_gssapi: GSSAPI...
-
pidgin-sipe release 1.25.0
-
Yes, Teams. My guesstimate is that our SfB subscription will be cancelled on the day after they have confirmed that external customers can participate in voice/video/presentation conference calls with Teams.
-
2 years will be shorter than you think. Just this morning our IT disabled IM & voice call features in our SfB subscription :-/
-
On a completely different subject: M$ has announced the discontinuation of SfB-Online within the next 2 years (at least that's how I understood the announcement). I.e. after that only organizations with own Lync server installation (no idea what happens with M$ hosted Lync servers...) will be able to use SfB. That means the SIPE user base will shrink to almost nothing. I'm not sure I can justify spending considerable time developing new features knowing this.
-
The pidgin 3.x branch is, by their own admission, completely borked. We won't see any progress on it until they ditch webkit1gtk and replace it with something that it is actually available/maintained on any OS. I wouldn't hold my breath though, because they knew about this for years but still haven't done anything about it. (maybe that is the reason for refusing to make a pidgin 2.x release: a concerted effort to unbork the pidgin 3.x branch e.g. by switching to webkit2gtkX)
-
The pidgin 3.x branch is, by their own admission, completely borked. We won't see any progress on it until they ditch webkit1gtk and replace it with something that it is actually available/maintained on any OS. I wouldn't hold my breath though, because they knew about this for years but still haven't done anything about it.
-
It turned out that there were even more FTBFS problems: autoreconf failed when gettext >= 0.20.0 was installed on the system. This problem did not affect OBS, but when I tried to push the FTBFS fixes to Fedora 31 & Rawhide. Fixed in git commit 3a7e482b
-
FTBFS with glib-2.0 >= 2.62.0
-
Fixed in git commit 24e6a6d7 Closing as FIXED.
-
FTBFS with glib-2.0 >= 2.62.0
-
Partial fix available in git commit d005dafc. Unfortunately there are more build errors, but not from SIPE code itself. It seems that libpurple 2.x API no longer builds with glib-2.0 >= 2.62.0, e.g. /usr/include/libpurple/media.h:214:3: error: 'GParameter' is deprecated [-Werror=deprecated-declarations] 214 | guint num_params, GParameter *params); | ^~~~~ I'll have to dig in more deeply if this can be fixed via the SIPE build.
-
FTBFS with glib-2.0 >= 2.61.0
-
Thanks. OBS confirms that it also fails on Fedora Rawhide now.
-
Nah, just a drink a beer for me when you go down to the pub next time. Now: will it work when you are in the office? Or will you have to clear the URL again? That said, it would be nice to figure out where the 'External EWS' information is encoded. Could you attach a unsafe debug log (see FAQ). Please make sure to clear the email service URL again before creating the debug log.
-
No, no, no, that URL goes into Advance tab, Email services URL field...
-
The UccApi0 log only contains the SIP messages, so it won't help in this case.
-
No worries, you at least followed the instructions and provided a usable logfile. What do you mean "wireshark traces"? All (well almost all) HTTP communcation is encrypted. Did you run a MITM attack on your Lync client to decode the traces to cleartext? Where is the information you attached? Please note that this information may already be in the SIPE log if you enable unsafe debug output. This will include the full message contents, including (sometimes) secret information like passwords. Please...
-
UCS Initialization Failed
-
Thanks for the log. Looks like your Lync installation may be incorrectly configured or your organization doesn't provide an EWS server that can be accessed from the internet: (01:03:56) sipe: process_subscribe_response: subscription 'vnd-microsoft-roaming-contacts' to 'sip:...' was rejected (01:03:56) sipe: no contact list available - assuming Lync 2013+ and Unified Contact Store (UCS) ... (01:03:56) sipe: sipe_ews_autodiscover_url: trying 'https://Autodiscover.nationwidechildrens.org/Autodiscover/Autodiscover.xml'...
-
That would require purple 2.x with media support (V&V), gstreamer, farstream and libnice to be available for the Windows platform. For Pidgin 2.x the answer is no and it is likely never going to happen, sorry. There was some work done on V&V support for Windows in purple 3.x, but I do not know about the current status.
-
Based on the provided information this is covered in the FAQ. As unsafe debug logging wasn't enable, as requested by FAQ, I'm unable to tell if the provided solution was applied correctly: ~~~~~ :::txt (22:18:14) sipe: sipe_http_transport_connected: login.microsoftonline.com:443(0254C168) (22:18:14) sipe: MESSAGE >>>>>>>>>> HTTP(0254C168) (22:18:14) sipe: transport_input_common: new buffer length 4096 (22:18:14) sipe: MESSAGE <<<<<<<<<< HTTP(0254C168) (22:18:14) sipe: sipe_http_request_response_callback:...
1 >