[jitsi-users] Jitsi (sip) clients screen-share : both behind NAT box issue


#1

HI

     I have following setup use sip for screen share:

      Client A <--> NAT-A box -- > sip-proxy/rtp-proxy --> NAT-B--> Client B

    of course they are in ipv4 network.

     A want to screen-share to B: currently Jitsi uses one-way video (A to B ) to achieve that.

     The sip-proxy detect both A/B are behind NAT boxes, so it will manipulate the sdp inside the invite/200-OK, and use rtp-proxy to do the trick,
which means A/B will send/receive the rtp stream from rtp-proxy.

     In order for this to work, the rtp proxy assumes the NAT boxes (most of them on the market?) to support symmetric rtp
<http://www.voip-info.org/wiki/view/RTPProxy>
     Now since it is a one-way video, B never send out video stream, so the rtp-proxy will not get the correct ip/port to send the video stream to B.

     The final result is that B can not show the A's screen.

      To solve the issue, Is it possible that Jitsi send some dummy/emtpy rtp pkt from the B's video port? Essential it become a two-way video, but A send the main video stream, B just occasionally send out some dummy/empty rtp in order to keep the NAT punch hole.

some more detail about the rtp proxy etc could be found at:

http://www.voip-info.org/wiki/view/RTP+Symmetric
http://www.voip-info.org/wiki/view/RTPProxy

Kind regards

min


#2

Hey Min,

HI

    I have following setup use sip for screen share:

     Client A <--> NAT-A box -- > sip-proxy/rtp-proxy --> NAT-B--> Client B

   of course they are in ipv4 network.
  
    A want to screen-share to B: currently Jitsi uses one-way video (A
to B ) to achieve that.

    The sip-proxy detect both A/B are behind NAT boxes, so it will
manipulate the sdp inside the invite/200-OK, and use rtp-proxy to do the
trick,
which means A/B will send/receive the rtp stream from rtp-proxy.

    In order for this to work, the rtp proxy assumes the NAT boxes (most
of them on the market?) to support symmetric rtp
<http://www.voip-info.org/wiki/view/RTPProxy>
    Now since it is a one-way video, B never send out video stream, so
the rtp-proxy will not get the correct ip/port to send the video stream
to B.

    The final result is that B can not show the A's screen.

     To solve the issue, Is it possible that Jitsi send some
dummy/emtpy rtp pkt from the B's video port?

We are already doing that. We send three empty datagrams to punch holes
in the NAT. Could it be that your RTP proxy is performing some sort of
assertions on them and discarding them for some reason?

Emil

···

On 10.07.12 16:39, Min Wang wrote:

Essential it become a
two-way video, but A send the main video stream, B just occasionally
send out some dummy/empty rtp in order to keep the NAT punch hole.

some more detail about the rtp proxy etc could be found at:

http://www.voip-info.org/wiki/view/RTP+Symmetric
http://www.voip-info.org/wiki/view/RTPProxy

Kind regards

min

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#3

Hi Emil:

We are already doing that. We send three empty datagrams to punch holes
in the NAT. Could it be that your RTP proxy is performing some sort of
assertions on them and discarding them for some reason?

    thanks for the infor.

    I double checked our trace. Yes, you are right.

    From the trace on the receiving side, it did send 2 empty udp packets ( instead of 3 , I am using 4013 build) .

    And the rtp-proxy did received one of this udp packets. so another is is lost :(!

    Considering the udp lost, could you double check it will send 3 instead of 2?

    Since this udp packets received ( at # 557 ) , rather later than the sending H.264 stream starting packets ( #137 packet), so our rtp-proxy seems confused where to send the packets.

    I will talk to our rtpproxy people.

Kind regards.

min


#4

Hey Min,

Hi Emil:

We are already doing that. We send three empty datagrams to punch holes
in the NAT. Could it be that your RTP proxy is performing some sort of
assertions on them and discarding them for some reason?

    thanks for the infor.

    I double checked our trace. Yes, you are right.

    From the trace on the receiving side, it did send 2 empty udp
packets ( instead of 3 , I am using 4013 build) .

    And the rtp-proxy did received one of this udp packets. so
another is is lost :(!

    Considering the udp lost, could you double check it will send 3
instead of 2?

Just checked and it appears we actually only send one packet per
component (i.e. one for RTP and one for RTCP). Not sure I thought we
tripled them. Maybe we should though.

    Since this udp packets received ( at # 557 ) , rather later than the
sending H.264 stream starting packets ( #137 packet), so our rtp-proxy
seems confused where to send the packets.

This would be weird since audio and video flows themselves are not
synchronous and are likely to start at different times. All RTP proxies
should hence be prepared to handle this. A bit more on hosted NAT
traversal and latching:

http://tools.ietf.org/html/draft-ivov-mmusic-latching

Hope this helps,
Emil

···

On 13.07.12 11:24, Min Wang wrote:

    I will talk to our rtpproxy people.

Kind regards.

min

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#5

HI Emil:
         thanks a lot.

      From the trace on the receiving side, it did send 2 empty udp
packets ( instead of 3 , I am using 4013 build) .

     And the rtp-proxy did received one of this udp packets. so
another is is lost :(!

     Considering the udp lost, could you double check it will send 3
instead of 2?
     

Just checked and it appears we actually only send one packet per
component (i.e. one for RTP and one for RTCP). Not sure I thought we
tripled them. Maybe we should though.

      Oh. I guess it would be a good idea to triple them giving that it is so important for the NAT traversal.
      Also does jitsi ( or need to ?) keep on sending out those empty packets periodically in order to keep NAT punch open ?

      my previous trace file of those 2 packets is probably due to the wireshark using ANY device and the NIC was set as bridged mode. The packet seems to be captured twiced. I still not fully understand it yet. But it is the question should go to wireshark mailinglist. Of course if any one here know the reason, please let me know.

     Since this udp packets received ( at # 557 ) , rather later than the
sending H.264 stream starting packets ( #137 packet), so our rtp-proxy
seems confused where to send the packets.
     

This would be weird since audio and video flows themselves are not
synchronous and are likely to start at different times. All RTP proxies
should hence be prepared to handle this. A bit more on hosted NAT
traversal and latching:

http://tools.ietf.org/html/draft-ivov-mmusic-latching
   
        Great. I will try to read the document.

min

···

Hope this helps,
Emil

     I will talk to our rtpproxy people.

Kind regards.

min


#6

Hey Min,

HI Emil:
         thanks a lot.

      From the trace on the receiving side, it did send 2 empty udp
packets ( instead of 3 , I am using 4013 build) .

     And the rtp-proxy did received one of this udp packets. so
another is is lost :(!

     Considering the udp lost, could you double check it will send 3
instead of 2?
     

Just checked and it appears we actually only send one packet per
component (i.e. one for RTP and one for RTCP). Not sure I thought we
tripled them. Maybe we should though.

      Oh. I guess it would be a good idea to triple them giving that
it is so important for the NAT traversal.

Yup, we'll probably do that.

      Also does jitsi ( or need to ?) keep on sending out those empty
packets periodically in order to keep NAT punch open ?

I wouldn't think so. Most NATs would keep a binding open as long as
there's traffic flowing in either direction.

      my previous trace file of those 2 packets is probably due to the
wireshark using ANY device and the NIC was set as bridged mode. The
packet seems to be captured twiced. I still not fully understand it
yet. But it is the question should go to wireshark mailinglist. Of
course if any one here know the reason, please let me know.

Well you should have indeed seen two packets - 1 for RTP and 1 for RTCP.
Isn't this the case?

Cheers,
Emil

···

On 13.07.12 16:29, Min Wang wrote:

     Since this udp packets received ( at # 557 ) , rather later than the
sending H.264 stream starting packets ( #137 packet), so our rtp-proxy
seems confused where to send the packets.
     

This would be weird since audio and video flows themselves are not
synchronous and are likely to start at different times. All RTP proxies
should hence be prepared to handle this. A bit more on hosted NAT
traversal and latching:

http://tools.ietf.org/html/draft-ivov-mmusic-latching
   

        Great. I will try to read the document.

min

Hope this helps,
Emil

     I will talk to our rtpproxy people.

Kind regards.

min


#7

hi Emil:
      thanks.

       my previous trace file of those 2 packets is probably due to the
wireshark using ANY device and the NIC was set as bridged mode. The
packet seems to be captured twiced. I still not fully understand it
yet. But it is the question should go to wireshark mailinglist. Of
course if any one here know the reason, please let me know.
     

Well you should have indeed seen two packets - 1 for RTP and 1 for RTCP.
Isn't this the case?

        I did see 2 dummy packets for rtp (30220)
        and another 2 dummy packets for rtcp (30221)

       kind regards.

min


#8

Hole punch packet count is now increased to 3 starting from revision
9739. Let's see how this goes.

Emil

···

On 13.07.12 16:38, Min Wang wrote:

hi Emil:
      thanks.

       my previous trace file of those 2 packets is probably due to the
wireshark using ANY device and the NIC was set as bridged mode. The
packet seems to be captured twiced. I still not fully understand it
yet. But it is the question should go to wireshark mailinglist. Of
course if any one here know the reason, please let me know.
     

Well you should have indeed seen two packets - 1 for RTP and 1 for RTCP.
Isn't this the case?

        I did see 2 dummy packets for rtp (30220)
        and another 2 dummy packets for rtcp (30221)

       kind regards.

min

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#9

HI Emil:
       I tested several times of screen share using the build 4122, it seems works well.

       Thanks for the changes.

min

···

On 07/14/2012 12:23 AM, Emil Ivov wrote:

Hole punch packet count is now increased to 3 starting from revision
9739. Let's see how this goes.

Emil

On 13.07.12 16:38, Min Wang wrote:
   

hi Emil:
       thanks.
     

        my previous trace file of those 2 packets is probably due to the
wireshark using ANY device and the NIC was set as bridged mode. The
packet seems to be captured twiced. I still not fully understand it
yet. But it is the question should go to wireshark mailinglist. Of
course if any one here know the reason, please let me know.

Well you should have indeed seen two packets - 1 for RTP and 1 for RTCP.
Isn't this the case?

         I did see 2 dummy packets for rtp (30220)
         and another 2 dummy packets for rtcp (30221)

        kind regards.

min