Audio and video not woriking in a web browser due to LtpaToken “undefined”

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 ( ***=all) and found that the LtpaToken was “undefined.”

REGISTER;transport=tls SIP/2.0
Content-Length: 0
Expires: 1800
Max-Forwards: 70
Cookie: LtpaToken=”undefined”
Supported: path, outbound
User-Agent: Sametime-ST9.0-Softphone
Contact: <**********:54303;transport=tls>;methods=”INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER”;reg-id=1;+sip.instance=”<urn:uuid:********************>”
Call-ID: *****************@
From: <>;tag=BCF17103-85B0EEA0
Via: SIP/2.0/TLS;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.



Portal to Sametime – SSO & LTPAToken issue

I had a customer get in touch with me about a problem they were having when trying to start Sametime Classic meetings from IBM WebSphere Portal. They have a link in Portal to a load balancer which then directed HTTP traffic to one of two Sametime Classic Meeting servers.

When logging into Portal and selecting the link a browser would launch and the user would be logged into STCenter.nsf via SSO. When scheduling a meeting the Meeting Room Client (MRC) would load but as soon as the MRC tries to connect to Sametime Community services (chat) an error appears on the user’s screen.

I took this into a development environment and replicated the behaviour. After enabling debugging on the Sametime server I saw the following output in the stusers*.txt

101117_095933.869,INF,Users   ,VpUsrAuthenticate::handleCheckUser: authenticating user with loginName=CN=Ben Williams/O=ACME by a single token
101117_095933.869,FTL,LDAP Aut,authenticating user by tokens
101117_095933.869,INF,LDAP Aut,Starting auth by tokens for [CN=Ben Williams/O=ACME] in org[]
101117_095933.869,FTL,LDAP Aut,checking LDAP format….
101117_095933.884,FTL,LDAP Aut,token verification failed. [4098]
101117_095933.884,INF,LDAP Aut,AuthTokenContext::authenticateBeforeDirSearch verifyTokenAndExtractUserId failed with reason 4098
101117_095933.884,FTL,LDAP Aut,AuthContext::start: authenticateBeforeDirSearch failed with reason 4098
101117_095933.884,INF,Users   ,VpUsrAuthenticate::checkedUser: VpUsrAuthenticate: bad login

I added debug_sso_trace_level=7 and Websess_verbose_Trace=1 to the Notes.ini but again nothing showed apart from when the browser opened STCenter.nsf, so on the Domino side of things SSO is working as expected.

Looking at the Java console output in the web browser when the MRC loaded I noticed “reverse proxy support disabled and detected” appear a few times. I observed this in the customer’s production environment and not in development so I ignored it which turned out to be a red herring.

It got me thinking about a problem I had with Sametime 8.0.2 and an LTPA parsing issue which produced similar errors although not exactly the same. That problem was fixed with a Sametime hot fix and was included in later versions of Sametime so it couldn’t be the same but must be along the same lines.

I exported the LTPAToken from the Portal deployment manager (DM) and imported it back into the Domino web SSO configuration document and restarted but this didn’t resolve the problem.

I then took more time looking at the Portal DM and noticed that Interoperability Mode was enabled which means that LTPAToken and LTPAToken2 are created.

Looking at the web SSO configuration document it was set to LTPAToken only.

After changing it to LTPAToken and LTPAToken2 and restarting things started working and users could now schedule and start meetings.