History-Info and Diversion headers in MSPL Skype for business

I am encountering some troubles with headers that the Mediation server is stripping, when I fork a call to another PBX (out of the Sfb environment).

Does anyone know how to parse sip headers through the mediation server, by using MSPL? I'm running it in a managed application, which is adding headers as following (in the OnResponse and OnRequest handlers):

// Add a ModifyHeadersSample header.
                Header newHeader = new Header("ModifyHeadersSample1", "localhost");
                e.Request.AllHeaders.Add(newHeader);


// Add a ModifyHeadersSample header.
                Header newHeader = new Header("ModifyHeadersSample", "localhost");
                e.Response.AllHeaders.Add(newHeader);

The thing is, that I want the History-Info header to be parsed from Mediation server and to the external PBX, so the history is not lost during the forwarding. I even want to be able to parse custom headers (e.g. X-MyHeader) in order to append extra information to track.

If I log the transaction, I see the headers that I added, in the Incoming Sip message on my SFB server, but it's gone on the Out Sip Request .

I'm running with following setting on the request:

            e.Request.SimpleProxy = true;
            e.ServerTransaction.EnableForking = false;

Solution

I think you are going to be out of luck here. I have found that when going through the Lync's SIP trunking setup you can lose all headers going into or out of the Lync SIP domain.

The only header that goes through untouched (at least from external sip domain into lync, I haven't checked going out) is the diversion header.

There is other ways to solve this problem tho.

Instead of using Trunk you could create a UCMA B2BUA application. In this situation you are in control of the headers on both sides so you can do what you like. The downside/upside is that UCMA is only medialess. The con of being medialess is that your endpoints in the external sip domain have to support SIPS/SRTP (or else you have to reduce the default security setup - possible but customers complain... Once security is downgraded it's very hard for customers to re-enable it) and ICE/STUN/TURN (if you wish to support edge / federated users). Supporting TURN is a funny one as Microsoft don't really really support TURN without there own extensions to TURN and they don't document them very well, so you would have to run your own TURN server.
You could write a UCMA application or Proxy application that forwards onto a gateway and writes the information you want over your own side-channel connection to the external sip domain. Then merge the data together in the external sip domain (maybe in a external sip domain B2BUA). This assume you have enough control over the external sip domain to do this.
Use the 'Diversion' header to encode your own parameters to/from the external sip domain. This only really works when you don't have a large amounts of data to sent across.

I have done all of the above for different projects so I know all of the above works except for the Diversion header coming out of a Lync gateway, what would have to be tested to check to see if that comes through ok.