This is sort of a follow up to a post from earlier this month on impersonation, and how you can get UCMA to insert the referred-by header into an INVITE. I was working on an application that used this technique, and everything was working great on the dev system. When we moved to final testing on the production server though, things started failing again. Long story short, running OCSLogger on both the dev system and the prod system revealed two different INVITE contents: one had the referred-by header, and one didn’t (Note-Running the Lync logging tool on the client is a great way to get a SIP trace that isn’t as noisy if you just care about one endpoint).
Now, the way this manifested itself was strange-the Lync server trace showed the invite being routed to the edge server (?), and then failing with the error “: 1017;reason=”Cannot route From and To domains in this combination”;source=”sipfed.computer-talk.com””. This made very little sense, and examining the outbound routing traces confirmed that the referred-by information was missing. The question is-why wasn’t this being added? The code specifically set a bunch of headers before creating the INVITE, and they were all there (not that it matters much, but those were Replaces and MS-Sensitivity). So what happened?
Well, I don’t actually have as good an answer as I’d like to this question, but I did notice that there were pending updates on the system. It turns out that it was installed with the UCMA bits from the Lync ISO, and hadn’t had any patches installed on Lync (just on Windows). The Lync environment was up to date, so I decided to let it install all the pending patches, including the June 2012 UCMA3 update. System came back up, tried the call again, and everything was fine. Checked the client trace, and there’s the Referred-by header.
Of course, now the question is, what did that update do? Nothing in the patch notes for any of the UCMA updates mentioned the Referred-by header or Transferor property specifically, but there was one update that referenced joining conferences using a PSTN endpoint. This behaviour could be caused by UCMA neglecting to insert the header, so perhaps this fixed my problem as well? I suppose the only way to know for sure would be to ask someone on the product team, or to try removing/applying updates one at a time until I can isolate the exact change that made this work, but for now I’m just glad that things are doing what they’re supposed to. If anyone has any insights into what’s going on here though, I’d love to hear them, so leave a comment or send me an email. For now though, the lesson of the day is to make sure that your servers are all at the same patch level-sometimes it can make a big difference.