UCMA 4 and back to backing a file transfer request

Question

OK, I know that file transfer isn't technically supported on UCMA 4.0, but I wanted to take another look at it and see whether there was a way to b2b a file transfer request. After all, there's no reason that it shouldn't work if the messaging is correct,
right? The scenario I have is A <-b2b-> app <-b2b->B.  I have an IM conversation going on between A and B, so now I'm trying to set it up so that A can send a file to B. 
So far I've extended the platform to accept file transfer requests by creating my own call and factory classes, and then registering them using RegisterPlatformExtension.  This means that when A sends a file, the INVITE gets delivered to my application. 
Now I'm taking that INVITE and creating a new b2b call.  A file transfer request looks something like this:
TL_INFO(TF_PROTOCOL) [0]16A8.4B28::02/10/2015-19:53:05.007.001d492f (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[3939761282] $$begin_record
Trace-Correlation-Id: 3939761282
Instance-Id: FDB3
Direction: incoming
Peer: 10.0.154.20:49282
Message-Type: request
Start-Line: INVITE sip:[email protected] SIP/2.0
From: <sip:[email protected]>;tag=eafd3e699d;epid=ccd5657cac
To: <sip:[email protected]>
Call-ID: 0acf0330423241258576d7c5cc42aa01
CSeq: 1 INVITE
Contact: <sip:[email protected];opaque=user:epid:d2lIs-103l2YSpDwCSajtAAA;gruu>
Via: SIP/2.0/TLS 10.0.154.20:49282
Max-Forwards: 70
Content-Length: 1920
Content-Type: multipart/mixed;boundary="----=_NextPart_000_0026_01D04541.4641C2D0"
Message-Body:
------=_NextPart_000_0026_01D04541.4641C2D0
Content-Type: application/sdp
Content-Transfer-Encoding: 7bit
Content-ID: <[email protected]>
Content-Dis; handling=optional; ms-proxy-2007fallback
v=0
o=- 0 0 IN IP4 192.168.200.71
s=session
c=IN IP4 192.168.200.71
b=CT:99980
t=0 0
m=data 21300 TCP/RTP/SAVP 127
a=ice-ufrag:lYAu
a=ice-pwd:y0gkW4r9zGSW6E2VdtMprlEh
a=candidate:1 1 TCP-PASS 2120613887 192.168.200.71 10856 typ host
a=candidate:1 2 TCP-PASS 2120613374 192.168.200.71 10856 typ host
a=candidate:2 1 TCP-ACT 2121006591 192.168.200.71 21300 typ host
a=candidate:2 2 TCP-ACT 2121006078 192.168.200.71 21300 typ host
a=candidate:3 1 TCP-PASS 2120612863 10.0.154.20 31624 typ host
a=candidate:3 2 TCP-PASS 2120612350 10.0.154.20 31624 typ host
a=candidate:4 1 TCP-ACT 2121005567 10.0.154.20 3921 typ host
a=candidate:4 2 TCP-ACT 2121005054 10.0.154.20 3921 typ host
a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:4CZbzYM/GYDbygj8JwMTodKo85C4Xx7TMzeMIuBU|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:Ohlo65gDsUvxCF39A382Rl4vGL+SG9R/lUEYU/br|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:EZ7Zm3K0H/WW5K49LAk9/C0T8x8nhkumJOycSek7|2^31
a=setup:active
a=connection:new
a=rtcp:21300
a=mid:1
a=sendonly
a=rtpmap:127 x-data/90000
------=_NextPart_000_0026_01D04541.4641C2D0
Content-Type: application/ms-filetransfer+xml
Content-Transfer-Encoding: quoted-printable
Content-ID: <[email protected]>
Content-Dis; handling=optional
<request xmlns=3D"http://schemas.microsoft.com/rtc/2009/05/filetransfer" =
requestId=3D"13">
<publishFile>
<fileInfo embedded=3D"true">
<id>{67190A30-C59F-480D-96DD-5F3941C39C49}</id>
<name>dbchange.log</name>
<size>3609</size>
</fileInfo>
</publishFile>
</request>
------=_NextPart_000_0026_01D04541.4641C2D0--
$$end_record
I've got my b2bed invite looking almost identical to the original invite by creating a custom MIME type on the CallEstablishOptions for the back to back call using something like this:
Regex r = new Regex(@"^((.|\n)*)(\<request)((.|\n)*)(request\>)((.|\n)*)$");
Match m=r.Match(args.RequestData.GetMessageBodyString());
content=string.Format("Content-Transfer-Encoding: quoted-printable\r\n{0}{1}{2}",m.Groups[3],m.Groups[4],m.Groups[6]);
opt.CustomMimeParts.Add(new MimePartContentDescription(new ContentType("application/ms-filetransfer+xml"),System.Text.ASCIIEncoding.UTF8.GetBytes(content)));
opt.CustomMimeParts[0].ContentDispositionHeader = new SignalingHeader("Content-Disposition", "render; handling=optional");
So far the only differences I can see in my outbound message vs the original SDP are that the Content-Transfer-Encoding might not be seen as a header (since the SignalingHeaders property on the MimePartContentDescription is read only), and the Content-Transfer-Encoding
on the first MIME part (created by the BackToBackCall) is missing (even though I specified it on the PassThroughHeaders).  Even with all of this though, I still get a 488 on client B when I attempt the transfer (even though the invite goes through). 
What I'm wondering though, is whether there's any way at all to get this working the way I'd expect, where a file gets transferred directly between A and B, without my bot having to receive it first.  The other approach I've looked at is binding my
own media provider class to customize the SDP, but if this MIME part approach isn't going to work, then I have a feeling the media provider won't work either. 
Any suggestions on where to look next? 
Thanks!
Chris

Answer 1

Chris,
I am trying to do something similar to this and from what I have read and in talking to MS is that you need to extend the Call and Flow class which it looks like you have been able to do. Could I bother you to share what you have written? Maybe we can help
each other out on this. I am basically trying to create an application that will be able to capture a file transfer and save it, then send the original request on to the intended recipient.
Thanks in advance,
Anthony