UCMA 4 and back to backing a file transfer request

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:ice@cb.local SIP/2.0
From: <sip:chris@cb.local>;tag=eafd3e699d;epid=ccd5657cac
To: <sip:ice@cb.local>
Call-ID: 0acf0330423241258576d7c5cc42aa01

CSeq: 1 INVITE
Contact: <sip:chris@cb.local;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: <872f839bcc9d57a9f973bb65bca94e3b@cb.local>
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: <e117a84c0d3748169cd2424878a387ac@840df3e87ee848c09dafd2435f842eda>

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

Latest Images

Trending Articles

Latest Images