When testing audio and video via a web browser of mobile phone I would see the following error in a browser when trying to use audio and video in a meeting. Using the thick client worked.
Looking at the SIP Proxy Registrars SystemOut.log I saw the following exceptions.
[2/11/14 18:08:43:660 GMT] 000000a7 LdapPasswordS I LdapPasswordServer CWSCT0359I: Hashed Credential attributes not found.
[2/11/14 18:08:43:661 GMT] 000000a7 SIPDigestServ E SIPDigestService CWSCT0340E: Error – cannot retrieve password attribute.
I enabled trace on the SIP PR ( *=info:com.ibm.ws.security.*=all:com.ibm.ws.sip.*=all) and found that the LtpaToken was “undefined.”
REGISTER sip:prcf.collaborationben.com;transport=tls SIP/2.0
Supported: path, outbound
CSeq: 1 REGISTER
From: WebAVClient-Ben.Williams%40collaborationben.com <sip:WebAVClient-Ben.Williamsemail@example.com>;tag=BCF17103-85B0EEA0
Via: SIP/2.0/TLS 188.8.131.52:54303;branch=z9hG4bK42f99901F8B8AD8E
I also saw that when I logged in as an LDAP user the trace showed my file system administrative user.
The LtpaToken must be working because the SIP PR is in the same cell as the majority of the other application servers and awareness works which means SSO must be working but the above shows that it isn’t. Odd.
I also noticed that if I authenticated with the Community server first and then switched to the meeting server URL, audio and video worked. It was the LtpaToken being provided by the WAS application server that was a problem.
I tried a couple of things such as changing the realm name to match the LDAP server as opposed to the default (defaultWIMFileBasedRealm) but this did not work.
Thankfully Khalid arranged a call with development and he asked me to uncheck “Set security cookies to HTTPOnly to help prevent cross-site scripting attacks.”
After I resynchronised and stopped and started all the application servers and proxies I could then use audio and video in my clients!
This should be making its way into a Technote soon.