#89 Improve "Join scheduled conference" dialog

[Daniel]

With Skype for Business M$ once again changed the approach for https:// conference URLs. They now point to a dynamic web page which doesn't contain the SIP URI anymore or doesn't even provide it anymore. Unfortunately the fallback URL parsing code doesn't work either which leads to a non-descript DNS failure error message.

• remove the fallback URL parsing code. It is useless today
• add a new, better error message if the HTML code doesn't contain a SIP URI
• update the dialog to enter alternatively meeting organizer and meeting ID

original text follows

Hi,
My company is using Office365 and our published Lync/Skype meeting URLs are similar to the following:

https://meet.lync.com/companyname/firstname.lastname/LRRR1MQ0

With pidgin-sipe 1.20.0, this URL gets parsed as follows (shown from the pidgin --debug log):

MESSAGE END <<<<<<<<<< HTTP - 2015-12-01T19:14:07.345791Z
(11:14:07) sipe: sipe_conf_lync_url_cb: no focus URI found. Falling back to parsing Lync URL 'https://meet.lync.com/companyname/firstname.lastname/LRRR1MQ0'
(11:14:07) sipe: sipe_chat_get_name: added new: Chat #1
(11:14:07) stun: using server 
(11:14:07) sipe: SIP transactions count:1 after addition
(11:14:07) sipe: 
MESSAGE START >>>>>>>>>> SIP - 2015-12-01T19:14:07.347833Z
INVITE sip:firstname.lastname@lync.com;gruu;opaque=app:conf:focus:id:LRRR1MQ0 SIP/2.0

Unfortunately, this SIP URL is wrong:

• Incorrect guess by parse_lync_join_url: sip:firstname.lastname@lync.com;gruu;opaque=app:conf:focus:id:LRRR1MQ0
• Working SIP URL: sip:firstname.lastname@companyname.com;gruu;opaque=app:conf:focus:id:LRRR1MQ0

If I'm interpreting this MS bug report correctly, a URL like https://meet.lync.com/companyname/username/meetingID should indeed have username@companyname.com as the organizer, but perhaps there are counterexamples which other users are aware of. Here is a simple patch that will look for lync.com URLs and transform the organizer name from @lync.com to @companyname.com:

diff --git a/src/core/sipe-conf.c b/src/core/sipe-conf.c
index 14b73cb..9a539f1 100644
--- a/src/core/sipe-conf.c
+++ b/src/core/sipe-conf.c
@@ -319,8 +319,14 @@ parse_lync_join_url(const gchar *uri)

                gchar **domain_parts = g_strsplit(parts[0], ".", 2);

-               /* we need to drop the first sub-domain from the URL */
-               if (domain_parts[0] && domain_parts[1]) {
+               if (strcmp(domain_parts[1], "lync.com") == 0) {
+                       const gchar *company_name = parts[parts_count - 3];
+                       focus_uri = g_strdup_printf("sip:%s@%s.com;gruu;opaque=app:conf:focus:id:%s",
+                                                   organizer_alias,
+                                                   company_name,
+                                                   conference_id);
+               } else if (domain_parts[0] && domain_parts[1]) {
+                       /* we need to drop the first sub-domain from the URL */
                        focus_uri = g_strdup_printf("sip:%s@%s;gruu;opaque=app:conf:focus:id:%s",
                                                    organizer_alias,
                                                    domain_parts[1],

Feels like an ugly hack to me, but it seems that almost everything to do with Lync meeting URLs is an ugly hack :-(.

Thanks,
Dan

Possibly-related older bugs:
http://sourceforge.net/p/sipe/bugs/273/
https://sourceforge.net/p/sipe/bugs/245/

[Daniel]

The patch works as expected and I pushed it here: http://repo.or.cz/siplcs.git/commit/12695c61f9a19198a18e78f85ed47076c89b5f63

[Stefan Becker]

If you want to hack your local copy, fine. But please do not mis-use our openness to push hacks to upstream. Reverted hack.

This is Microsoft problem and I do not see why SIPE should hack around this. Please use a Web browser to extract the URI from the dynamic HTML code.

Closing as duplicate of [bugs:#292]

Related forum discussion: [fd0c0a7f]

[Daniel]

Hi Stefan,
My apologies for committing so quickly, but the contributor instructions appear to encourage quickly pushing working patches to the mob branch.

I agree that this is a problem created by Microsoft's inconsistent and non-transparent URLs, however I disagree that this is an excessively narrow fix: this problem quite likely affects all users of Lync with the cloud-hosted Office365 and a custom company domain name.

• The MS bug report I linked above provides evidence that my patch interprets meet.lync.com URLs in the way MS intends (braindead, arbitrary... but as intended).
• This is not a dupe of [bugs:#292]: that bug report applies to a Lync server hosted by an individual company, rather than an Office365 cloud-hosted server.
• Also unlike the situation of [bugs:#292], the Office365 meeting URLs (meet.lync.com) lead to pages that do not contain the correct "focus URI" anywhere, so "extract[ing] the URI from the dynamic HTML code" as in features:#82 is not a viable solution.

Unfortunately it seems necessary to do some kind of educated-guessing based on the URL in this case; I believe that this is exactly what the parse_lync_join_url function is intended to do.

[Stefan Becker]

This is a dupe of [bugs:#292]: "dynamic HTML" means that you need a web browser so that you can click on a Javascript-powered element on the page to get the URI.

Anyway, your hack did not implement what the MS KB entry says.

[Daniel]

I understood what you meant by dynamic HTML. I can only speak definitively about my own company's meet.lync.com pages, but the JavaScript therein does not produce sip: URIs at all. Rather, it produces lync15:URLs which don't contain the same fields; they certainly do not contain the user.name@companyname.com organizer field at all.

Here's another way I look at it:

1. When we have a URI like https://join.ucrtc.hpe.com/meet/user.name/ID (from [bugs:#292]), numerous past examples make it clear that SIPE should try user.name@ucrtc.hpe.com as a guess for the correct organizer address (just as you implemented it in b09ab4b2).
2. However, when we have a URI like https://meet.lync.com/companyname/user.name/ID, then this heuristic will not work, since the organizer address is very likely to be user.name@companyname.com and is almost certainly not user.name@lync.com.

It appears that the URI-to-organizer-address guessing algorithm is simply different for company-hosted Lync vs. Office365-hosted Lync.

The ambiguity and inconsistency of these URLs is totally Microsoft's fault... however since there's a clear pattern in both cases above, it seems to me that it makes sense for this package to try its best to guess the organizer ID in both cases.

[Stefan Becker]

Can you please provide a proper URL example? The one given in the description only leads to an error page.

[Stefan Becker]

Thanks for providing the real example via e-mail.

This convinces me that the hack will not work for everbody, i.e. it will make things worse than they are today. The only way forward I see is to remove the old fall-back URL-parsing code and replace it with a clear error message to the user to get the URI via some other means.

[Daniel]

Yes, I do think a clearer error message would be helpful.

If you want to get rid of the URI-parsing code altogether... how about instead giving the dialog box an option to input the conference organizer and ID, instead of the focus-URI?

Meeting URL: ____________________________ (e.g. conf:, sip:)
  or
Organizer: ____________________________ (e.g. first.last@company.com)
Conference ID: __________________________ (e.g SRV56P43)

[Stefan Becker]

Ticket moved from /p/sipe/bugs/300/

Can't be converted:

• _milestone: 1.20.x

[Stefan Becker]

Implemented in git commit c47a61b

I would appreciate feedback if the new dialog works for you.

Closing

[Daniel]

Thank you! The new dialog works for me, and the clearer error message is certainly an improvement.