[SIPForum-discussion] TCP framing handling for content sharing

[ashish khowal]

Hi all,

I am struggling to understand the right behavior that needs to be
implemented here. My query is:

Scenario:

My client is running a application sharing in Lync -environment from
internal lync to external lync using our firewall engine which we support.
Audio video call works fine but as soon as client starts desktop sharing .
Issue starting to happen as RTP packet encapsulated in TCP frame was not
properly handled.

As per RFC 4571 and MS-TURN specs

If we look at normal STUN TCP packets in a Microsoft environment, the data
starts with 4 bytes of STUN TCP framing then 2 bytes of length for the RTP
packet(RFC 4571), then the RTP packet itself.

Now my STUN TCP packet starts like this:

03 00 05 50 04 BC 80 7F 71 FB 1B 58 AD 42 BB 09 A7 45 8C B1 94 B1 94 D1 94
D1 94 D1 94 D2 9C D1 94 D1 94 B1 94 91 94 90 8C 70 8C 4F 84 2F 84 0F 84 0F



where starting 03 --> end-end message

3rd and 4th byte: 05 50 -->payload length --> 1360 bytes

5th and 6th byte : 04 BC -->RTP length -->1212 bytes

Now once 1212 bytes are read , I am left 148 bytes and after the 1212 bytes
are over , this is the packet

04 BC 80 7F 71 FC 1B 58 AD 42 BB 09 A7 45 9C F7 BD D7 BD CF 73 75 AD 0D .



How should we treat this continuos frame in the packet, should i treat it
like next RTP frame itself or as part of end-end message since it still has
148 bytes left ??

If we treat it as separate RTP frame and considering the structure of RTP
framing

The Framing Method

   Figure 1 defines the framing method.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    ---------------------------------------------------------------
   |             LENGTH            |  RTP or RTCP packet ...       |
    ---------------------------------------------------------------

        Figure 1: The bit field definition of the framing method

   A 16-bit unsigned integer LENGTH field, coded in network byte order
   (big-endian), begins the frame.  If LENGTH is non-zero, an RTP or
   RTCP packet follows the LENGTH field.


04 BC should be length having 1212 bytes but since this total packet had
payload length of 1360 so we are moving it to some partial buffer so that
when the next packet comes we are prepending  these 148 bytes from partial
buffer to new packet.

But I observe that next packet comes out to be end-end packet as first byte
is 03 : (Note that these are just first 50 bytes of packet)

03 00 05 50 5B 10 7C 06 9B AA 52 BE F7 FB DE FB DE 31 F7 B6 FF B6 FF B6 FF
FE FF 0B D6 ED CD 6E E6 53 F7 32 F7 12 F7 4D DE 79 CE 79 CE 58 CE 38 C6 38

payload length:1360

Now when I am prepending it with left over bytes from partial buffer the
packet will be

04 BC 80 7F 71 FC 1B 58 AD 42 BB 09 A7 45 9C F7 BD D7 BD CF 73 75 AD 0D
..........till 148 bytes..

+

03 00 05 50 5B 10 7C 06 9B AA 52 BE F7 FB DE FB DE 31 F7 B6 FF B6 FF B6 FF
FE FF 0B D6 ED CD 6E E6 53 F7 32 F7 12 F7 4D DE 79 CE 79 CE 58 CE 38 C6 38

so the total length of new packet becomes 148+1360=1508 bytes

But here we can see when I started with 04 BC 80 7f then it is not an
end-end packet so it will read till 04 BC bytes and it will then perform in
this way.

Now,I am not able to understand if this is correct behavior to adjust the
packet in such  a way, since the new packet comes out to be starting from
03 00 05 50(end-end packet) which does not seems to be like continous of
previous packet left over bytes having length 04 BC.

I am not sure how to implement this . If anybody has any idea or reference
to handle this situation then please comment.
-- 
Thanks and Regards
Ashish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20150711/fb69f455/attachment-0002.html>