SIP SDP problems with Lync and Sametime Gateway

It’s not the first time I have federated the Gateway with OCS/Lync servers, all previous federations went smoothly, this one didn’t. Prior to federating I updated to 8.5.2.1 HF2 which involves applying FP19 to WAS 7 so that it brings it to the latest and greatest and should combat any problems with Lync.

When I got round to federating I found that awareness worked and the Lync users could chat with me but I couldn’t initiate a chat with them. I enabled the following trace and delved through the trace.log.

*=info: com.ibm.rtc.gateway.*=all: com.ibm.ws.sip.stack.transaction.transport.TransportCommLayerMgr=all

Looking at the trace.log I found the following errors.

18/07/13 11:19:10:675 BST] 00000029 TransportComm 3 TransportCommLayerMgr onMessage In Message:
SIP/2.0 488 Not Acceptable Here
ms-asserted-verification-level: ms-source-verified-user=verified
Content-Length: 0
Ms-client-diagnostics: 52063;reason=”Unsupported session description”
User-Agent: UCCAPI/15.0.4454.1504 OC/15.0.4454.1506 (Microsoft Lync)
CSeq: 2 INVITE
Call-ID: 8301348675246938@*******
To: <sip:joe.bloggs@acme.com>;epid=6cefe9b8de;tag=2ef08a07f6
From: <sip:ben.williams@collaborationben.com>;tag=563671771882337_local.1373296073078_269626_344492
Via: SIP/2.0/TLS ********:5061;rport;ibmsid=local.1373296073078_269626_344492;branch=z9hG4bK309775045542683;received=********;ms-received-port=33942;ms-received-cid=F00

I didn’t get very far pouring through the log so I raised a PMR and quickly Khalid Abbas got back to me asking me to apply DLAR-97EC3X which is specifically built for OCS/Lync. This hotfix is designed to change the SDP for OCS/Lync from “5061 tcp/sip *” to “5060 sip null” and add “a=accept-types:text/plain. This related to SDP for IM Session which describes the format the Session Description Protocol must be in for Lync/OCS.

Apply this hotfix changed the SIP SDP from

v=0
o=- 0 0 IN IP4 gateway.collaborationben.com
s=session
c=IN IP4 gateway.collaborationben.com
t=0 0
m=message 5061 sip/tcp *

to

v=0
o=- 0 0 IN IP4 gateway.collaborationben.com
s=session
c=IN IP4 gateway.collaborationben.com
t=0 0
m=message 5060 sip null
a=accept-types:text/plain

This though wasn’t enough to get it working with the original 488 errors because the FQHN was still in the the SIP SDP. Finally I had to change the SIP SDP to put out an IP address rather than the FQHN. This was done by logging into the Gateway’s ISC and going to Servers – Server Types – WebSphere Application servers – RTCGWServer – Server Infrastructure – Administration – Custom Properties changing the propery “com.ibm.sametime.gateway.fqdn” replacing the FQHN with the external IP address of the Gateway.

On restart it worked as expected.

The odd thing is why did it work previously with a Lync 2010 and OCS 2007 R2 already federated but not for this new partner?

 

Leavers showing as off line through the Sametime Gateway

An internal user described a problem where as a leaver was showing as on line to IBM colleagues via their Sametime client, further more chats sent to the leaver was being received by the leaver’s manager. Our Gateway is federated with IBM’s so I can chat with them. I was a bit sceptical at first but after reproducing it I took a peek.

The manager had added the leaver’s email address to their person document so that email sent to the leaver was routed to them. Running a query for the leaver’s email address using ldapsearch resolved the email address to the  manager.Looking at the trace.log on the Gateway I could see the interaction and the email address resolving to the manager.

I created a mail in database document and added the email addresses of the leaver to it, gave it a name and then pointed the database to the manager’s mail file but still the leaver showed as on line. Looking at the trace.log again showed that

VPUsersCache  3 com.ibm.rtc.gateway.vp.util.cache.VPUsersCache getSTId Retrieved STId: {CN=Manager,O=ACME,}, for email: leaver@acme.com

This tells me that the email is being cached against the manager’s ID. After a restart of the Gateway the leaver does not show on line.

 

IBM Connections SSO not working with Metrics

The one problem I had out the back of the Metrics install which was post-Connections 4.0 was the when users clicked on the Metrics tab they were not signed into Metrics automatically. Users were faced with the following screen.

2013-08-01_092532

The User ID field was pre-populated with the users userPrincipalName (joe.bloggs@acme.com) which was not accepted. To log in to metrics the @acme.com needed to be removed leaving the users sAMAccountName which did work.

I changed the following fields in Cognos BI which worked and the user was signed in BUT it broke the daily and weekly cube refresh/build and no data appeared in Metrics.

User lookup – (userPrincipalName=${userID})
External identity mapping – (userPrincipalName=${environment(“REMOTE_USER”)})

I reverted back to using sAMAccountName so data was presented but the user had to remove the domain and log in manually.

I spoke with a colleague who performed the migration from 3.0.1 to 4.0 and it turns out that there was a change to the wimconfig.xml to allow the customer to log in with different attributes.

Replaced:
<config:attributes name=”samAccountName” propertyName=”uid”>
<config:entityTypes>PersonAccount</config:entityTypes>
</config:attributes>

With this:
<config:attributes name=”userPrincipalName” propertyName=”uid”>
<config:entityTypes>PersonAccount</config:entityTypes>
</config:attributes>
<config:attributes name=”samAccountName” propertyName=”cn”>
<config:entityTypes>PersonAccount</config:entityTypes>
</config:attributes>

So I looked more closely at it and read an interesting piece http://publib.boulder.ibm.com/infocenter/c8bi/v8r4m0/index.jsp?topic=/com.ibm.swg.im.cognos.crn_arch.8.4.0.doc/crn_arch_id4601Securing_Access_to_Cognos_Connection.html which talks about using the replace function to remove the domain name from the string. The example given is (&(uid=${replace(${environment(“REMOTE_USER”)},”ABC\\”,””)}

I added (&(sAMAccountName=${replace(${environment(“REMOTE_USER”)},”acme.com\\”,””)} to External identity mapping and changed the syntax a few times before realising that it was supposed to be stripping the domain in from a format such as ACME\Joe Bloggs. I then changed it and after a couple of goes I got the correct syntax of (sAMAccountName=${replace(${environment(“REMOTE_USER”)},”@acme.com”,””)}) and after I restarted the Cognos application server the user was able to sign in automatically and all the data was there.