[jitsi-users] screen share , through rtp-proxy


#1

Hi:

I have following two cases:

(a) client1 send h.264 directly to client2, the quality is great.

(b) but if client1 send h.264 to a rtp-proxy, then the rtp-proxy relay the packets to client2, the quality is not good at all. ( some blocks are not display clearly etc).

   There is no packet loss according to the trace files .

   here are the results from wireshark stream anaylysis for (b)

(1) sender (client1):

H.264 to rtp-proxy:

Max delta = 145.71 ms at packet no. 108
Max jitter = 2.95 ms. Mean jitter = 3.39 ms.
Max skew = -17.38 ms.
Total RTP packets = 3340 (expected 3340)
Lost RTP packets = 0 (0.00%)
Sequence errors = 0
Duration 65.55 s (-82 ms clock drift, corresponding to 89887 Hz (-0.13%)

(2) at the rtp-proxy:

H.264 stream get from sender:
Max delta = 144.40 ms at packet no. 154
Max jitter = 4.86 ms. Mean jitter = 3.81 ms.
Max skew = -23.09 ms.
Total RTP packets = 3340 (expected 3340)
Lost RTP packets = 0 (0.00%)
Sequence errors = 0
Duration 65.55 s (-26 ms clock drift, corresponding to 89964 Hz (-0.04%)

H.264 sending to receiver:

Max delta = 144.12 ms at packet no. 155
Max jitter = 5.06 ms. Mean jitter = 5.53 ms.
Max skew = -38.04 ms.
Total RTP packets = 3324 (expected 3324)
Lost RTP packets = 0 (0.00%)
Sequence errors = 0
Duration 65.27 s (-26 ms clock drift, corresponding to 89964 Hz (-0.04%)

( the 3340-3324 = 16 packtes are the packets after sip bye, so should be not matter?)

(3) receiver (client2):
H.264 stream from the rtp-proxy:

Max delta = 143.87 ms at packet no. 167
Max jitter = 5.04 ms. Mean jitter = 5.56 ms.
Max skew = -37.63 ms.
Total RTP packets = 3324 (expected 3324)
Lost RTP packets = 0 (0.00%)
Sequence errors = 0
Duration 65.27 s (-165 ms clock drift, corresponding to 89773 Hz (-0.25%)

      Anything could be wrong? If needed, I have whole trace files.

thanks.

min


#2

Hey Min,

You may want to play with the value of the maximum allowed bandwidth in
the Video settings page. Try setting a higher value.

Hope this helps,
Emil

···

On 05.07.12 13:15, Min Wang wrote:

Hi:

I have following two cases:

(a) client1 send h.264 directly to client2, the quality is great.

(b) but if client1 send h.264 to a rtp-proxy, then the rtp-proxy relay
the packets to client2, the quality is not good at all. ( some blocks
are not display clearly etc).

   There is no packet loss according to the trace files .

   here are the results from wireshark stream anaylysis for (b)

(1) sender (client1):

H.264 to rtp-proxy:

Max delta = 145.71 ms at packet no. 108
Max jitter = 2.95 ms. Mean jitter = 3.39 ms.
Max skew = -17.38 ms.
Total RTP packets = 3340 (expected 3340)
Lost RTP packets = 0 (0.00%)
Sequence errors = 0
Duration 65.55 s (-82 ms clock drift, corresponding to 89887 Hz (-0.13%)

(2) at the rtp-proxy:

H.264 stream get from sender:
Max delta = 144.40 ms at packet no. 154
Max jitter = 4.86 ms. Mean jitter = 3.81 ms.
Max skew = -23.09 ms.
Total RTP packets = 3340 (expected 3340)
Lost RTP packets = 0 (0.00%)
Sequence errors = 0
Duration 65.55 s (-26 ms clock drift, corresponding to 89964 Hz (-0.04%)

H.264 sending to receiver:

Max delta = 144.12 ms at packet no. 155
Max jitter = 5.06 ms. Mean jitter = 5.53 ms.
Max skew = -38.04 ms.
Total RTP packets = 3324 (expected 3324)
Lost RTP packets = 0 (0.00%)
Sequence errors = 0
Duration 65.27 s (-26 ms clock drift, corresponding to 89964 Hz (-0.04%)

( the 3340-3324 = 16 packtes are the packets after sip bye, so should be
not matter?)

(3) receiver (client2):
H.264 stream from the rtp-proxy:

Max delta = 143.87 ms at packet no. 167
Max jitter = 5.04 ms. Mean jitter = 5.56 ms.
Max skew = -37.63 ms.
Total RTP packets = 3324 (expected 3324)
Lost RTP packets = 0 (0.00%)
Sequence errors = 0
Duration 65.27 s (-165 ms clock drift, corresponding to 89773 Hz (-0.25%)

      Anything could be wrong? If needed, I have whole trace files.

thanks.

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

I have tried the Jitsi: 1.1-nightly.build.4103 on Linux amd 64 bit version. ( configured with sip etc)

The enable remote control seems not working: after checked the enable remote control checkbox, at remote PC, moving the mouse, the mouse does not move at all at the local PC?

Anything need to be configured or this feature is known not working at this stage?

thanks.

min


#4

HI Emil:

     thanks for the quick response.

     it works now! It was due to the rtp-proxy's bug that truncate the rtp pkt >=1024 bytes.

min

···

On 07/06/2012 12:24 PM, Emil Ivov wrote:

Hey Min,

You may want to play with the value of the maximum allowed bandwidth in
the Video settings page. Try setting a higher value.

Hope this helps,
Emil

On 05.07.12 13:15, Min Wang wrote:
   

Hi:

I have following two cases:

(a) client1 send h.264 directly to client2, the quality is great.

(b) but if client1 send h.264 to a rtp-proxy, then the rtp-proxy relay
the packets to client2, the quality is not good at all. ( some blocks
are not display clearly etc).

    There is no packet loss according to the trace files .

    here are the results from wireshark stream anaylysis for (b)

(1) sender (client1):

H.264 to rtp-proxy:

Max delta = 145.71 ms at packet no. 108
Max jitter = 2.95 ms. Mean jitter = 3.39 ms.
Max skew = -17.38 ms.
Total RTP packets = 3340 (expected 3340)
Lost RTP packets = 0 (0.00%)
Sequence errors = 0
Duration 65.55 s (-82 ms clock drift, corresponding to 89887 Hz (-0.13%)

(2) at the rtp-proxy:

H.264 stream get from sender:
Max delta = 144.40 ms at packet no. 154
Max jitter = 4.86 ms. Mean jitter = 3.81 ms.
Max skew = -23.09 ms.
Total RTP packets = 3340 (expected 3340)
Lost RTP packets = 0 (0.00%)
Sequence errors = 0
Duration 65.55 s (-26 ms clock drift, corresponding to 89964 Hz (-0.04%)

H.264 sending to receiver:

Max delta = 144.12 ms at packet no. 155
Max jitter = 5.06 ms. Mean jitter = 5.53 ms.
Max skew = -38.04 ms.
Total RTP packets = 3324 (expected 3324)
Lost RTP packets = 0 (0.00%)
Sequence errors = 0
Duration 65.27 s (-26 ms clock drift, corresponding to 89964 Hz (-0.04%)

( the 3340-3324 = 16 packtes are the packets after sip bye, so should be
not matter?)

(3) receiver (client2):
H.264 stream from the rtp-proxy:

Max delta = 143.87 ms at packet no. 167
Max jitter = 5.04 ms. Mean jitter = 5.56 ms.
Max skew = -37.63 ms.
Total RTP packets = 3324 (expected 3324)
Lost RTP packets = 0 (0.00%)
Sequence errors = 0
Duration 65.27 s (-165 ms clock drift, corresponding to 89773 Hz (-0.25%)

       Anything could be wrong? If needed, I have whole trace files.

thanks.

min


#5

Hi Min,

I have no problem with remote access under the same Jitsi version with debian 64 bits (there is no particular configuration for this functionality).

- Does the remote peer used the same Jitsi version?
- What is the protocol used (SIP or XMPP)?
- If the issue continues, may I ask you to provide the log files [0]?

Regards,
Vincent

[0] https://jitsi.org/index.php/Documentation/FAQ#logs

···

On 07/06/2012 05:00 PM, Min Wang wrote:

Hi

I have tried the Jitsi: 1.1-nightly.build.4103 on Linux amd 64 bit
version. ( configured with sip etc)

The enable remote control seems not working: after checked the enable
remote control checkbox, at remote PC, moving the mouse, the mouse does
not move at all at the local PC?

Anything need to be configured or this feature is known not working at
this stage?

thanks.

min

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org


#6

Hi Vincent
      thanks a lot.

      The same version are used on debian 6. the protocol is SIP.

      Yes, I tried again, still not working.

       Please see the attached log files ( I guess those are the log file you mentioned? the log file are from Jitsi->options-> logging)

       client1 --> sip/kamailio proxy (and rtp-proxy) --> client2

       the client1 is called testuser1
             client2 is called testuser2

        If you need further packet level traces, let me know.

thanks again.

min

client1-2012-07-06@17.44.05-logs.zip (162 KB)

client2-2012-07-06@17.43.47-logs.zip (945 KB)

···

On 07/06/2012 05:34 PM, Vincent Lucas wrote:

Hi Min,

I have no problem with remote access under the same Jitsi version with debian 64 bits (there is no particular configuration for this functionality).

- Does the remote peer used the same Jitsi version?
- What is the protocol used (SIP or XMPP)?
- If the issue continues, may I ask you to provide the log files [0]?

Regards,
Vincent

[0] https://jitsi.org/index.php/Documentation/FAQ#logs

On 07/06/2012 05:00 PM, Min Wang wrote:

Hi

I have tried the Jitsi: 1.1-nightly.build.4103 on Linux amd 64 bit
version. ( configured with sip etc)

The enable remote control seems not working: after checked the enable
remote control checkbox, at remote PC, moving the mouse, the mouse does
not move at all at the local PC?

Anything need to be configured or this feature is known not working at
this stage?

thanks.

min


#7

Hey Min,

Jitsi uses NOTIFY requests to notify the remote party of mouse and key
events. Could you please check if those go from one party to the other?

Emil

···

On 06.07.12 17:53, Min Wang wrote:

Hi Vincent
      thanks a lot.

      The same version are used on debian 6. the protocol is SIP.

      Yes, I tried again, still not working.

       Please see the attached log files ( I guess those are the log
file you mentioned? the log file are from Jitsi->options-> logging)

       client1 --> sip/kamailio proxy (and rtp-proxy) --> client2

       the client1 is called testuser1
             client2 is called testuser2

        If you need further packet level traces, let me know.

thanks again.

min

On 07/06/2012 05:34 PM, Vincent Lucas wrote:

Hi Min,

I have no problem with remote access under the same Jitsi version with
debian 64 bits (there is no particular configuration for this
functionality).

- Does the remote peer used the same Jitsi version?
- What is the protocol used (SIP or XMPP)?
- If the issue continues, may I ask you to provide the log files [0]?

Regards,
Vincent

[0] https://jitsi.org/index.php/Documentation/FAQ#logs

On 07/06/2012 05:00 PM, Min Wang wrote:

Hi

I have tried the Jitsi: 1.1-nightly.build.4103 on Linux amd 64 bit
version. ( configured with sip etc)

The enable remote control seems not working: after checked the enable
remote control checkbox, at remote PC, moving the mouse, the mouse does
not move at all at the local PC?

Anything need to be configured or this feature is known not working at
this stage?

thanks.

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


#8

Hi Emil

     Thanks a lot for the info.

     Since I have left the office, so do not have that 64bit test environment.
     but I used the my local KVM tested the 32bit 4103 version on the windows-xp and did the trace.

     Here is the finding:

   (1) the Jitsi configure is configured to use " Enable SIMPLE mode"

   (2) when jitsi screen share, it try to subscribe event: remote-control,
       since our sip proxy does not support it, so it rejected it, never relay to the client2.

      thus the client2 will never send out any NOTIFY.

      so it is our proxy's issue.

    (3) I just did the quick google search for remote-control, seems could not find where the remote-control event package is defined? Could you point out the right documents about this?

kind regards.

min

···

On 07/06/2012 05:55 PM, Emil Ivov wrote:

Hey Min,

Jitsi uses NOTIFY requests to notify the remote party of mouse and key
events. Could you please check if those go from one party to the other?

Emil

On 06.07.12 17:53, Min Wang wrote:
   

Hi Vincent
       thanks a lot.

       The same version are used on debian 6. the protocol is SIP.

       Yes, I tried again, still not working.

        Please see the attached log files ( I guess those are the log
file you mentioned? the log file are from Jitsi->options-> logging)

        client1 --> sip/kamailio proxy (and rtp-proxy) --> client2

        the client1 is called testuser1
              client2 is called testuser2

         If you need further packet level traces, let me know.

thanks again.

min

On 07/06/2012 05:34 PM, Vincent Lucas wrote:
     

Hi Min,

I have no problem with remote access under the same Jitsi version with
debian 64 bits (there is no particular configuration for this
functionality).

- Does the remote peer used the same Jitsi version?
- What is the protocol used (SIP or XMPP)?
- If the issue continues, may I ask you to provide the log files [0]?

Regards,
Vincent

[0] https://jitsi.org/index.php/Documentation/FAQ#logs

On 07/06/2012 05:00 PM, Min Wang wrote:
       

Hi

I have tried the Jitsi: 1.1-nightly.build.4103 on Linux amd 64 bit
version. ( configured with sip etc)

The enable remote control seems not working: after checked the enable
remote control checkbox, at remote PC, moving the mouse, the mouse does
not move at all at the local PC?

Anything need to be configured or this feature is known not working at
this stage?

thanks.

min
         


#9

Hey Min,

Hi Emil

     Thanks a lot for the info.

     Since I have left the office, so do not have that 64bit test
environment.
     but I used the my local KVM tested the 32bit 4103 version on the
windows-xp and did the trace.

     Here is the finding:

   (1) the Jitsi configure is configured to use " Enable SIMPLE mode"

   (2) when jitsi screen share, it try to subscribe event: remote-control,
       since our sip proxy does not support it, so it rejected it, never
relay to the client2.

      thus the client2 will never send out any NOTIFY.

      so it is our proxy's issue.

    (3) I just did the quick google search for remote-control, seems
could not find where the remote-control event package is defined? Could
you point out the right documents about this?

The event package is called "remote-control".

We haven't published it in a document yet though.

Cheers,
Emil

···

On 06.07.12 19:15, Min Wang wrote:

kind regards.

min

On 07/06/2012 05:55 PM, Emil Ivov wrote:

Hey Min,

Jitsi uses NOTIFY requests to notify the remote party of mouse and key
events. Could you please check if those go from one party to the other?

Emil

On 06.07.12 17:53, Min Wang wrote:
   

Hi Vincent
       thanks a lot.

       The same version are used on debian 6. the protocol is SIP.

       Yes, I tried again, still not working.

        Please see the attached log files ( I guess those are the log
file you mentioned? the log file are from Jitsi->options-> logging)

        client1 --> sip/kamailio proxy (and rtp-proxy) --> client2

        the client1 is called testuser1
              client2 is called testuser2

         If you need further packet level traces, let me know.

thanks again.

min

On 07/06/2012 05:34 PM, Vincent Lucas wrote:
     

Hi Min,

I have no problem with remote access under the same Jitsi version with
debian 64 bits (there is no particular configuration for this
functionality).

- Does the remote peer used the same Jitsi version?
- What is the protocol used (SIP or XMPP)?
- If the issue continues, may I ask you to provide the log files [0]?

Regards,
Vincent

[0] https://jitsi.org/index.php/Documentation/FAQ#logs

On 07/06/2012 05:00 PM, Min Wang wrote:
       

Hi

I have tried the Jitsi: 1.1-nightly.build.4103 on Linux amd 64 bit
version. ( configured with sip etc)

The enable remote control seems not working: after checked the enable
remote control checkbox, at remote PC, moving the mouse, the mouse does
not move at all at the local PC?

Anything need to be configured or this feature is known not working at
this stage?

thanks.

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


#10

HI Emil:

    thanks for the infor!

       Another thing I noticed is: that subscribe (event=remote-control) is sent within the invite-initiated dialog.

     It is legimate from RFC, but would it be simpler/easier to send the subscribe (event=remote-control) without using the existing invite dialog? Let this subscribe to setup its own dialog?

     One potential reason is: sip proxy may want subscribe/notify take different route-set ( than the one setup by the invite intiated dialog ).
e.g.: sip proxy may route voice/video invite to a SBC, but just relay subscribe/notify without SBC.

     there were some discussion about it.

      https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-June/013198.html

      Any advantage to send that subscribe within the invite-initiated dialog?

kind regards.

min

···

On 07/06/2012 11:38 PM, Emil Ivov wrote:

Hey Min,

On 06.07.12 19:15, Min Wang wrote:
   

Hi Emil

      Thanks a lot for the info.

      Since I have left the office, so do not have that 64bit test
environment.
      but I used the my local KVM tested the 32bit 4103 version on the
windows-xp and did the trace.

      Here is the finding:

    (1) the Jitsi configure is configured to use " Enable SIMPLE mode"

    (2) when jitsi screen share, it try to subscribe event: remote-control,
        since our sip proxy does not support it, so it rejected it, never
relay to the client2.

       thus the client2 will never send out any NOTIFY.

       so it is our proxy's issue.

     (3) I just did the quick google search for remote-control, seems
could not find where the remote-control event package is defined? Could
you point out the right documents about this?
     

The event package is called "remote-control".

We haven't published it in a document yet though.

Cheers,
Emil
   

kind regards.

min

On 07/06/2012 05:55 PM, Emil Ivov wrote:
     

Hey Min,

Jitsi uses NOTIFY requests to notify the remote party of mouse and key
events. Could you please check if those go from one party to the other?

Emil

On 06.07.12 17:53, Min Wang wrote:

Hi Vincent
        thanks a lot.

        The same version are used on debian 6. the protocol is SIP.

        Yes, I tried again, still not working.

         Please see the attached log files ( I guess those are the log
file you mentioned? the log file are from Jitsi->options-> logging)

         client1 --> sip/kamailio proxy (and rtp-proxy) --> client2

         the client1 is called testuser1
               client2 is called testuser2

          If you need further packet level traces, let me know.

thanks again.

min

On 07/06/2012 05:34 PM, Vincent Lucas wrote:

Hi Min,

I have no problem with remote access under the same Jitsi version with
debian 64 bits (there is no particular configuration for this
functionality).

- Does the remote peer used the same Jitsi version?
- What is the protocol used (SIP or XMPP)?
- If the issue continues, may I ask you to provide the log files [0]?

Regards,
Vincent

[0] https://jitsi.org/index.php/Documentation/FAQ#logs

On 07/06/2012 05:00 PM, Min Wang wrote:

Hi

I have tried the Jitsi: 1.1-nightly.build.4103 on Linux amd 64 bit
version. ( configured with sip etc)

The enable remote control seems not working: after checked the enable
remote control checkbox, at remote PC, moving the mouse, the mouse does
not move at all at the local PC?

Anything need to be configured or this feature is known not working at
this stage?

thanks.

min


#11

HI:

    Just FYI Actually there is a RFC 5057, which suggests:

    Handling multiple usages within a single dialog is complex and
    introduces scenarios where the right thing to do is not clear.
    Implementations should avoid entering into multiple usages whenever
    possible. New applications should be designed to never introduce
    multiple usages.

    There are some accepted SIP practices, including transfer, that
    currently require multiple usages. Recent work, most notably GRUU,
    makes those practices unnecessary. The standardization of those
    practices and the implementations should be revised as soon as
    possible to use only single-usage dialogs.

kind regards.

min

···

On 07/07/2012 12:20 AM, Min Wang wrote:

HI Emil:

   thanks for the infor!

      Another thing I noticed is: that subscribe (event=remote-control) is sent within the invite-initiated dialog.

    It is legimate from RFC, but would it be simpler/easier to send the subscribe (event=remote-control) without using the existing invite dialog? Let this subscribe to setup its own dialog?

    One potential reason is: sip proxy may want subscribe/notify take different route-set ( than the one setup by the invite intiated dialog ).
e.g.: sip proxy may route voice/video invite to a SBC, but just relay subscribe/notify without SBC.

    there were some discussion about it.

     https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-June/013198.html

     Any advantage to send that subscribe within the invite-initiated dialog?

kind regards.

min

On 07/06/2012 11:38 PM, Emil Ivov wrote:

Hey Min,

On 06.07.12 19:15, Min Wang wrote:

Hi Emil

      Thanks a lot for the info.

      Since I have left the office, so do not have that 64bit test
environment.
      but I used the my local KVM tested the 32bit 4103 version on the
windows-xp and did the trace.

      Here is the finding:

    (1) the Jitsi configure is configured to use " Enable SIMPLE mode"

    (2) when jitsi screen share, it try to subscribe event: remote-control,
        since our sip proxy does not support it, so it rejected it, never
relay to the client2.

       thus the client2 will never send out any NOTIFY.

       so it is our proxy's issue.

     (3) I just did the quick google search for remote-control, seems
could not find where the remote-control event package is defined? Could
you point out the right documents about this?

The event package is called "remote-control".

We haven't published it in a document yet though.

Cheers,
Emil

kind regards.

min

On 07/06/2012 05:55 PM, Emil Ivov wrote:

Hey Min,

Jitsi uses NOTIFY requests to notify the remote party of mouse and key
events. Could you please check if those go from one party to the other?

Emil

On 06.07.12 17:53, Min Wang wrote:

Hi Vincent
        thanks a lot.

        The same version are used on debian 6. the protocol is SIP.

        Yes, I tried again, still not working.

         Please see the attached log files ( I guess those are the log
file you mentioned? the log file are from Jitsi->options-> logging)

         client1 --> sip/kamailio proxy (and rtp-proxy) --> client2

         the client1 is called testuser1
               client2 is called testuser2

          If you need further packet level traces, let me know.

thanks again.

min

On 07/06/2012 05:34 PM, Vincent Lucas wrote:

Hi Min,

I have no problem with remote access under the same Jitsi version with
debian 64 bits (there is no particular configuration for this
functionality).

- Does the remote peer used the same Jitsi version?
- What is the protocol used (SIP or XMPP)?
- If the issue continues, may I ask you to provide the log files [0]?

Regards,
Vincent

[0] https://jitsi.org/index.php/Documentation/FAQ#logs

On 07/06/2012 05:00 PM, Min Wang wrote:

Hi

I have tried the Jitsi: 1.1-nightly.build.4103 on Linux amd 64 bit
version. ( configured with sip etc)

The enable remote control seems not working: after checked the enable
remote control checkbox, at remote PC, moving the mouse, the mouse does
not move at all at the local PC?

Anything need to be configured or this feature is known not working at
this stage?

thanks.

min


#12

Hey Min,

Thanks for pointing this out. Interesting matter indeed.

The main reason for keeping this within the dialog is that remote control
messages directly refer to it and have no sense outside of its context.
Desktop streaming is no more but a video flow and remote control messages
are just feedback on that flow.

More specifically, if they didn't belong to a dialog, we wouldn't always
know what to match them to. Imagine a user sharing two separate parts of
their screen (or two separate screens for that matter) in two simultaneous
calls to someone else. Incoming remote control messages in this case would
be ambiguous without the dialog. I admit the use case is a stretch but I
see no reason not to support ... given that support doesn't cost much.

That being said we'd still be in trouble if both regions were shared over
the same dialog ... so I guess we'd still need a way to reference a
specific stream.

Out of curiosity, is this thing causing you specific problems or was this
more of a design question?

Cheers,

Emil

HI:

   Just FYI Actually there is a RFC 5057, which suggests:

   Handling multiple usages within a single dialog is complex and
   introduces scenarios where the right thing to do is not clear.
   Implementations should avoid entering into multiple usages whenever
   possible. New applications should be designed to never introduce
   multiple usages.

   There are some accepted SIP practices, including transfer, that
   currently require multiple usages. Recent work, most notably GRUU,
   makes those practices unnecessary. The standardization of those
   practices and the implementations should be revised as soon as
   possible to use only single-usage dialogs.

kind regards.

min

HI Emil:

   thanks for the infor!

      Another thing I noticed is: that subscribe (event=remote-control)

is sent within the invite-initiated dialog.

    It is legimate from RFC, but would it be simpler/easier to send

the subscribe (event=remote-control) without using the existing invite
dialog? Let this subscribe to setup its own dialog?

    One potential reason is: sip proxy may want subscribe/notify take

different route-set ( than the one setup by the invite intiated dialog ).

e.g.: sip proxy may route voice/video invite to a SBC, but just relay

subscribe/notify without SBC.

    there were some discussion about it.

https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-June/013198.html

     Any advantage to send that subscribe within the invite-initiated

dialog?

kind regards.

min

Hey Min,

Hi Emil

      Thanks a lot for the info.

      Since I have left the office, so do not have that 64bit test
environment.
      but I used the my local KVM tested the 32bit 4103 version on the
windows-xp and did the trace.

      Here is the finding:

    (1) the Jitsi configure is configured to use " Enable SIMPLE mode"

    (2) when jitsi screen share, it try to subscribe event:

remote-control,

        since our sip proxy does not support it, so it rejected it,

never

relay to the client2.

       thus the client2 will never send out any NOTIFY.

       so it is our proxy's issue.

     (3) I just did the quick google search for remote-control, seems
could not find where the remote-control event package is defined? Could
you point out the right documents about this?

The event package is called "remote-control".

We haven't published it in a document yet though.

Cheers,
Emil

kind regards.

min

Hey Min,

Jitsi uses NOTIFY requests to notify the remote party of mouse and key
events. Could you please check if those go from one party to the

other?

Emil

Hi Vincent
        thanks a lot.

        The same version are used on debian 6. the protocol is SIP.

        Yes, I tried again, still not working.

         Please see the attached log files ( I guess those are the

log

file you mentioned? the log file are from Jitsi->options-> logging)

         client1 --> sip/kamailio proxy (and rtp-proxy) -->

client2

         the client1 is called testuser1
               client2 is called testuser2

          If you need further packet level traces, let me know.

thanks again.

min

Hi Min,

I have no problem with remote access under the same Jitsi version

with

debian 64 bits (there is no particular configuration for this
functionality).

- Does the remote peer used the same Jitsi version?
- What is the protocol used (SIP or XMPP)?
- If the issue continues, may I ask you to provide the log files

[0]?

Regards,
Vincent

[0] https://jitsi.org/index.php/Documentation/FAQ#logs

Hi

I have tried the Jitsi: 1.1-nightly.build.4103 on Linux amd 64 bit
version. ( configured with sip etc)

The enable remote control seems not working: after checked the

enable

remote control checkbox, at remote PC, moving the mouse, the mouse

does

not move at all at the local PC?

Anything need to be configured or this feature is known not

working at

···

On Jul 7, 2012 12:08 PM, "Min Wang" <ser.basis@gmail.com> wrote:

On 07/07/2012 12:20 AM, Min Wang wrote:

On 07/06/2012 11:38 PM, Emil Ivov wrote:

On 06.07.12 19:15, Min Wang wrote:

On 07/06/2012 05:55 PM, Emil Ivov wrote:

On 06.07.12 17:53, Min Wang wrote:

On 07/06/2012 05:34 PM, Vincent Lucas wrote:

On 07/06/2012 05:00 PM, Min Wang wrote:

this stage?

thanks.

min


#13

HI Emil

      Thanks a lot for the explaination.

The main reason for keeping this within the dialog is that remote control messages directly refer to it and have no sense outside of its context. Desktop streaming is no more but a video flow and remote control messages are just feedback on that flow.

More specifically, if they didn't belong to a dialog, we wouldn't always know what to match them to. Imagine a user sharing two separate parts of their screen (or two separate screens for that matter) in two simultaneous calls to someone else. Incoming remote control messages in this case would be ambiguous without the dialog. I admit the use case is a stretch but I see no reason not to support ... given that support doesn't cost much.

That being said we'd still be in trouble if both regions were shared over the same dialog ... so I guess we'd still need a way to reference a specific stream.

          The following is just my naive thoughts, may not make any sense at all, so please bear with me.:slight_smile:

          Let us say if we try to follow the RFC 5057, use single-usage dialogs ( that means one dialog only for one purpose ).

          client1 ------------------------> client2

          for screen share area 1:

          there will be two dialogs for area1:
          (1.a) invite initiated dialog, mainly for the video stream
          (1.b) subscribe-initiated dialog:

                  client1 send subscribe to client2

                  SUBSCRIBE: sip:client2
                  event: remote-control, id=streamid-for-area1
                  ..

                  once client2 received it, from the id it could associated the area1 with id=streamid-for-area1.
                  Now mouse move at client2, if there is just one area, it is easy, just send NOTIFY back using that (1.b) dialog.

           Now if there is another screen share area 2, there will be another 2 dialogs

          (2.a) invite initiated dialog,
          (2.b) subscribe initiated dialog:
               SUBSCRIBE: client2
               event: remote-control, id=streamid-for-area2

           The difficult part seems to be : how client2 know one paticular mouse move belong to which area?

           if this this not the issue, notify will follow the subscribe-initated dialog route-set back to client1, so matching the NOTIFY with areas seems should not be an issue. ?

          Or I may misunderstand or over-simplified something here. ?

Out of curiosity, is this thing causing you specific problems or was this more of a design question?

               We have a sip proxy which handle the invite/subscribe differently.
               to be specific: the INVITE is routed to a SBC (back2back sip agent) which can do some fancy things, but may not be able to handle/pass the SUBSCRIBE/NOTIFY transparently.

               The SUBSCRIBE/NOTIFY are routed without going through the SBC.

               The issue is: if subscribe is sent within the invite dialog, it follow the same route-set path as INVITE, thus hit the SBC which can not handle it.

kind regards.

min

···

Cheers,

Emil

On Jul 7, 2012 12:08 PM, "Min Wang" <ser.basis@gmail.com > <mailto:ser.basis@gmail.com>> wrote:
>
> HI:
>
> Just FYI Actually there is a RFC 5057, which suggests:
>
> Handling multiple usages within a single dialog is complex and
> introduces scenarios where the right thing to do is not clear.
> Implementations should avoid entering into multiple usages whenever
> possible. New applications should be designed to never introduce
> multiple usages.
>
> There are some accepted SIP practices, including transfer, that
> currently require multiple usages. Recent work, most notably GRUU,
> makes those practices unnecessary. The standardization of those
> practices and the implementations should be revised as soon as
> possible to use only single-usage dialogs.
>
> kind regards.
>
> min
>
> On 07/07/2012 12:20 AM, Min Wang wrote:
>>
>> HI Emil:
>>
>> thanks for the infor!
>>
>> Another thing I noticed is: that subscribe (event=remote-control) is sent within the invite-initiated dialog.
>>
>> It is legimate from RFC, but would it be simpler/easier to send the subscribe (event=remote-control) without using the existing invite dialog? Let this subscribe to setup its own dialog?
>>
>> One potential reason is: sip proxy may want subscribe/notify take different route-set ( than the one setup by the invite intiated dialog ).
>> e.g.: sip proxy may route voice/video invite to a SBC, but just relay subscribe/notify without SBC.
>>
>> there were some discussion about it.
>>
>> https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-June/013198.html

>>
>> Any advantage to send that subscribe within the invite-initiated dialog?
>>
>> kind regards.
>>
>> min
>>
>> On 07/06/2012 11:38 PM, Emil Ivov wrote:
>>>
>>> Hey Min,
>>>
>>> On 06.07.12 19:15, Min Wang wrote:
>>>>
>>>> Hi Emil
>>>>
>>>> Thanks a lot for the info.
>>>>
>>>> Since I have left the office, so do not have that 64bit test
>>>> environment.
>>>> but I used the my local KVM tested the 32bit 4103 version on the
>>>> windows-xp and did the trace.
>>>>
>>>> Here is the finding:
>>>>
>>>> (1) the Jitsi configure is configured to use " Enable SIMPLE mode"
>>>>
>>>> (2) when jitsi screen share, it try to subscribe event: remote-control,
>>>> since our sip proxy does not support it, so it rejected it, never
>>>> relay to the client2.
>>>>
>>>> thus the client2 will never send out any NOTIFY.
>>>>
>>>> so it is our proxy's issue.
>>>>
>>>> (3) I just did the quick google search for remote-control, seems
>>>> could not find where the remote-control event package is defined? Could
>>>> you point out the right documents about this?
>>>
>>> The event package is called "remote-control".
>>>
>>> We haven't published it in a document yet though.
>>>
>>> Cheers,
>>> Emil
>>>>
>>>> kind regards.
>>>>
>>>> min
>>>>
>>>> On 07/06/2012 05:55 PM, Emil Ivov wrote:
>>>>>
>>>>> Hey Min,
>>>>>
>>>>> Jitsi uses NOTIFY requests to notify the remote party of mouse and key
>>>>> events. Could you please check if those go from one party to the other?
>>>>>
>>>>> Emil
>>>>>
>>>>> On 06.07.12 17:53, Min Wang wrote:
>>>>>
>>>>>> Hi Vincent
>>>>>> thanks a lot.
>>>>>>
>>>>>> The same version are used on debian 6. the protocol is SIP.
>>>>>>
>>>>>> Yes, I tried again, still not working.
>>>>>>
>>>>>> Please see the attached log files ( I guess those are the log
>>>>>> file you mentioned? the log file are from Jitsi->options-> logging)
>>>>>>
>>>>>> client1 --> sip/kamailio proxy (and rtp-proxy) --> client2
>>>>>>
>>>>>> the client1 is called testuser1
>>>>>> client2 is called testuser2
>>>>>>
>>>>>> If you need further packet level traces, let me know.
>>>>>>
>>>>>> thanks again.
>>>>>>
>>>>>> min
>>>>>>
>>>>>> On 07/06/2012 05:34 PM, Vincent Lucas wrote:
>>>>>>
>>>>>>> Hi Min,
>>>>>>>
>>>>>>> I have no problem with remote access under the same Jitsi version with
>>>>>>> debian 64 bits (there is no particular configuration for this
>>>>>>> functionality).
>>>>>>>
>>>>>>> - Does the remote peer used the same Jitsi version?
>>>>>>> - What is the protocol used (SIP or XMPP)?
>>>>>>> - If the issue continues, may I ask you to provide the log files [0]?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Vincent
>>>>>>>
>>>>>>> [0] https://jitsi.org/index.php/Documentation/FAQ#logs
>>>>>>>
>>>>>>> On 07/06/2012 05:00 PM, Min Wang wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> I have tried the Jitsi: 1.1-nightly.build.4103 on Linux amd 64 bit
>>>>>>>> version. ( configured with sip etc)
>>>>>>>>
>>>>>>>> The enable remote control seems not working: after checked the enable
>>>>>>>> remote control checkbox, at remote PC, moving the mouse, the mouse does
>>>>>>>> not move at all at the local PC?
>>>>>>>>
>>>>>>>> Anything need to be configured or this feature is known not working at
>>>>>>>> this stage?
>>>>>>>>
>>>>>>>> thanks.
>>>>>>>>
>>>>>>>> min
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>


#14

Hey Min,

HI Emil

     Thanks a lot for the explaination.

The main reason for keeping this within the dialog is that remote
control messages directly refer to it and have no sense outside of its
context. Desktop streaming is no more but a video flow and remote
control messages are just feedback on that flow.

More specifically, if they didn't belong to a dialog, we wouldn't
always know what to match them to. Imagine a user sharing two separate
parts of their screen (or two separate screens for that matter) in two
simultaneous calls to someone else. Incoming remote control messages
in this case would be ambiguous without the dialog. I admit the use
case is a stretch but I see no reason not to support ... given that
support doesn't cost much.

That being said we'd still be in trouble if both regions were shared
over the same dialog ... so I guess we'd still need a way to reference
a specific stream.

         The following is just my naive thoughts, may not make any
sense at all, so please bear with me.:slight_smile:

         Let us say if we try to follow the RFC 5057, use
single-usage dialogs ( that means one dialog only for one purpose ).

         client1 ------------------------> client2

         for screen share area 1:
        
         there will be two dialogs for area1:
         (1.a) invite initiated dialog, mainly for the video stream
         (1.b) subscribe-initiated dialog:
               
                 client1 send subscribe to client2
                
                 SUBSCRIBE: sip:client2
                 event: remote-control, id=streamid-for-area1
                 ..

                 once client2 received it, from the id it could
associated the area1 with id=streamid-for-area1.
                 Now mouse move at client2, if there is just one area,
it is easy, just send NOTIFY back using that (1.b) dialog.
               
          Now if there is another screen share area 2, there will be
another 2 dialogs
           
         (2.a) invite initiated dialog,
         (2.b) subscribe initiated dialog:
              SUBSCRIBE: client2
              event: remote-control, id=streamid-for-area2

The problem is that there is currently no such thing as a stream ID, or,
as I mentioned in my previous mail, there is no way to reference a
specific area the way you do in your example above.

I just had a quick look at KPML (since what we do is pretty similar to
that) and they do seem to use a SUBSCRIBE initiated dialog for KPML
events. They also refer to the call dialog through an "Event" header
containing the Dialog ID of the main call.

They also seem to mention the case where multiple audio streams may be
monitorable ... but I didn't quite understand the solution to that.
Would need to look into it later.

So, to sum it all up, I do agree that it would be better design to take
key and mouse events in a separate dialog, but I am not quite sure when
we will be able to attend to this.

Could you please open an issue?

It is probably also worth mentioning that we were discussing the
possibility of using PseudoTCP for such things and if we do, the above
would be obsoleted.

Cheers,
Emil

···

On 07.07.12 16:33, Min Wang wrote:

          The difficult part seems to be : how client2 know one
paticular mouse move belong to which area?

          if this this not the issue, notify will follow the
subscribe-initated dialog route-set back to client1, so matching the
NOTIFY with areas seems should not be an issue. ?

         Or I may misunderstand or over-simplified something here. ?

Out of curiosity, is this thing causing you specific problems or was
this more of a design question?

              We have a sip proxy which handle the invite/subscribe
differently.
              to be specific: the INVITE is routed to a SBC (back2back
sip agent) which can do some fancy things, but may not be able to
handle/pass the SUBSCRIBE/NOTIFY transparently.

              The SUBSCRIBE/NOTIFY are routed without going through the SBC.

              The issue is: if subscribe is sent within the invite
dialog, it follow the same route-set path as INVITE, thus hit the SBC
which can not handle it.

kind regards.

min

Cheers,

Emil

On Jul 7, 2012 12:08 PM, "Min Wang" <ser.basis@gmail.com >> <mailto:ser.basis@gmail.com>> wrote:
>
> HI:
>
> Just FYI Actually there is a RFC 5057, which suggests:
>
>
> Handling multiple usages within a single dialog is complex and
> introduces scenarios where the right thing to do is not clear.
> Implementations should avoid entering into multiple usages whenever
> possible. New applications should be designed to never introduce
> multiple usages.
>
> There are some accepted SIP practices, including transfer, that
> currently require multiple usages. Recent work, most notably GRUU,
> makes those practices unnecessary. The standardization of those
> practices and the implementations should be revised as soon as
> possible to use only single-usage dialogs.
>
>
> kind regards.
>
>
>
> min
>
>
>
> On 07/07/2012 12:20 AM, Min Wang wrote:
>>
>> HI Emil:
>>
>> thanks for the infor!
>>
>> Another thing I noticed is: that subscribe
(event=remote-control) is sent within the invite-initiated dialog.
>>
>> It is legimate from RFC, but would it be simpler/easier to
send the subscribe (event=remote-control) without using the existing
invite dialog? Let this subscribe to setup its own dialog?
>>
>> One potential reason is: sip proxy may want subscribe/notify
take different route-set ( than the one setup by the invite intiated
dialog ).
>> e.g.: sip proxy may route voice/video invite to a SBC, but just
relay subscribe/notify without SBC.
>>
>> there were some discussion about it.
>>
>>
https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-June/013198.html

>>
>>
>> Any advantage to send that subscribe within the
invite-initiated dialog?
>>
>>
>>
>> kind regards.
>>
>>
>> min
>>
>> On 07/06/2012 11:38 PM, Emil Ivov wrote:
>>>
>>> Hey Min,
>>>
>>> On 06.07.12 19:15, Min Wang wrote:
>>>>
>>>> Hi Emil
>>>>
>>>> Thanks a lot for the info.
>>>>
>>>> Since I have left the office, so do not have that 64bit test
>>>> environment.
>>>> but I used the my local KVM tested the 32bit 4103 version
on the
>>>> windows-xp and did the trace.
>>>>
>>>> Here is the finding:
>>>>
>>>> (1) the Jitsi configure is configured to use " Enable SIMPLE
mode"
>>>>
>>>>
>>>> (2) when jitsi screen share, it try to subscribe event:
remote-control,
>>>> since our sip proxy does not support it, so it rejected
it, never
>>>> relay to the client2.
>>>>
>>>> thus the client2 will never send out any NOTIFY.
>>>>
>>>> so it is our proxy's issue.
>>>>
>>>>
>>>> (3) I just did the quick google search for remote-control,
seems
>>>> could not find where the remote-control event package is defined?
Could
>>>> you point out the right documents about this?
>>>
>>> The event package is called "remote-control".
>>>
>>> We haven't published it in a document yet though.
>>>
>>> Cheers,
>>> Emil
>>>>
>>>>
>>>>
>>>>
>>>> kind regards.
>>>>
>>>>
>>>> min
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 07/06/2012 05:55 PM, Emil Ivov wrote:
>>>>>
>>>>> Hey Min,
>>>>>
>>>>> Jitsi uses NOTIFY requests to notify the remote party of mouse
and key
>>>>> events. Could you please check if those go from one party to the
other?
>>>>>
>>>>>
>>>>> Emil
>>>>>
>>>>> On 06.07.12 17:53, Min Wang wrote:
>>>>>
>>>>>> Hi Vincent
>>>>>> thanks a lot.
>>>>>>
>>>>>>
>>>>>> The same version are used on debian 6. the protocol is SIP.
>>>>>>
>>>>>> Yes, I tried again, still not working.
>>>>>>
>>>>>> Please see the attached log files ( I guess those are
the log
>>>>>> file you mentioned? the log file are from Jitsi->options->
logging)
>>>>>>
>>>>>> client1 --> sip/kamailio proxy (and rtp-proxy) -->
client2
>>>>>>
>>>>>> the client1 is called testuser1
>>>>>> client2 is called testuser2
>>>>>>
>>>>>> If you need further packet level traces, let me know.
>>>>>>
>>>>>>
>>>>>> thanks again.
>>>>>>
>>>>>>
>>>>>>
>>>>>> min
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 07/06/2012 05:34 PM, Vincent Lucas wrote:
>>>>>>
>>>>>>> Hi Min,
>>>>>>>
>>>>>>> I have no problem with remote access under the same Jitsi
version with
>>>>>>> debian 64 bits (there is no particular configuration for this
>>>>>>> functionality).
>>>>>>>
>>>>>>> - Does the remote peer used the same Jitsi version?
>>>>>>> - What is the protocol used (SIP or XMPP)?
>>>>>>> - If the issue continues, may I ask you to provide the log
files [0]?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Vincent
>>>>>>>
>>>>>>> [0] https://jitsi.org/index.php/Documentation/FAQ#logs
>>>>>>>
>>>>>>> On 07/06/2012 05:00 PM, Min Wang wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> I have tried the Jitsi: 1.1-nightly.build.4103 on Linux amd
64 bit
>>>>>>>> version. ( configured with sip etc)
>>>>>>>>
>>>>>>>> The enable remote control seems not working: after checked
the enable
>>>>>>>> remote control checkbox, at remote PC, moving the mouse, the
mouse does
>>>>>>>> not move at all at the local PC?
>>>>>>>>
>>>>>>>>
>>>>>>>> Anything need to be configured or this feature is known not
working at
>>>>>>>> this stage?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> thanks.
>>>>>>>>
>>>>>>>> min
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>


#15

HI Emil

Thanks again.

I have created the issue at:

http://java.net/jira/browse/JITSI-1056

BTW, we managed to pass the SUBSCRIBE/NOTIFY through our proxy. Now the remote control is working with our platform. that is a cool feature.

Now new issue:

  do you have any idea how much bandwidth the mouse/keyboard stream will consume?

  On the proxy server, we have a module to protect DOS attack. The mouse move cause a lot of NOTIFY, and it is easily being tagged as DOS attack.
  Of course we have to improve this.
  But at the same time is it possible to have some configurable parameters to control how much the mouse event/per second etc can be sent, does it make sense in terms of remote-control?

kind regards

min

···

On 07/10/2012 01:04 PM, Emil Ivov wrote:

Hey Min,

On 07.07.12 16:33, Min Wang wrote:
   

HI Emil

      Thanks a lot for the explaination.
     

The main reason for keeping this within the dialog is that remote
control messages directly refer to it and have no sense outside of its
context. Desktop streaming is no more but a video flow and remote
control messages are just feedback on that flow.

More specifically, if they didn't belong to a dialog, we wouldn't
always know what to match them to. Imagine a user sharing two separate
parts of their screen (or two separate screens for that matter) in two
simultaneous calls to someone else. Incoming remote control messages
in this case would be ambiguous without the dialog. I admit the use
case is a stretch but I see no reason not to support ... given that
support doesn't cost much.

That being said we'd still be in trouble if both regions were shared
over the same dialog ... so I guess we'd still need a way to reference
a specific stream.

          The following is just my naive thoughts, may not make any
sense at all, so please bear with me.:slight_smile:

          Let us say if we try to follow the RFC 5057, use
single-usage dialogs ( that means one dialog only for one purpose ).

          client1 ------------------------> client2

          for screen share area 1:

          there will be two dialogs for area1:
          (1.a) invite initiated dialog, mainly for the video stream
          (1.b) subscribe-initiated dialog:

                  client1 send subscribe to client2

                  SUBSCRIBE: sip:client2
                  event: remote-control, id=streamid-for-area1
                  ..

                  once client2 received it, from the id it could
associated the area1 with id=streamid-for-area1.
                  Now mouse move at client2, if there is just one area,
it is easy, just send NOTIFY back using that (1.b) dialog.

           Now if there is another screen share area 2, there will be
another 2 dialogs

          (2.a) invite initiated dialog,
          (2.b) subscribe initiated dialog:
               SUBSCRIBE: client2
               event: remote-control, id=streamid-for-area2
     

The problem is that there is currently no such thing as a stream ID, or,
as I mentioned in my previous mail, there is no way to reference a
specific area the way you do in your example above.

I just had a quick look at KPML (since what we do is pretty similar to
that) and they do seem to use a SUBSCRIBE initiated dialog for KPML
events. They also refer to the call dialog through an "Event" header
containing the Dialog ID of the main call.

They also seem to mention the case where multiple audio streams may be
monitorable ... but I didn't quite understand the solution to that.
Would need to look into it later.

So, to sum it all up, I do agree that it would be better design to take
key and mouse events in a separate dialog, but I am not quite sure when
we will be able to attend to this.

Could you please open an issue?

It is probably also worth mentioning that we were discussing the
possibility of using PseudoTCP for such things and if we do, the above
would be obsoleted.

Cheers,
Emil

           The difficult part seems to be : how client2 know one
paticular mouse move belong to which area?

           if this this not the issue, notify will follow the
subscribe-initated dialog route-set back to client1, so matching the
NOTIFY with areas seems should not be an issue. ?
     
          Or I may misunderstand or over-simplified something here. ?

Out of curiosity, is this thing causing you specific problems or was
this more of a design question?

               We have a sip proxy which handle the invite/subscribe
differently.
               to be specific: the INVITE is routed to a SBC (back2back
sip agent) which can do some fancy things, but may not be able to
handle/pass the SUBSCRIBE/NOTIFY transparently.

               The SUBSCRIBE/NOTIFY are routed without going through the SBC.

               The issue is: if subscribe is sent within the invite
dialog, it follow the same route-set path as INVITE, thus hit the SBC
which can not handle it.

kind regards.

min

Cheers,

Emil

On Jul 7, 2012 12:08 PM, "Min Wang"<ser.basis@gmail.com >>> <mailto:ser.basis@gmail.com>> wrote:
       

HI:

    Just FYI Actually there is a RFC 5057, which suggests:

    Handling multiple usages within a single dialog is complex and
    introduces scenarios where the right thing to do is not clear.
    Implementations should avoid entering into multiple usages whenever
    possible. New applications should be designed to never introduce
    multiple usages.

    There are some accepted SIP practices, including transfer, that
    currently require multiple usages. Recent work, most notably GRUU,
    makes those practices unnecessary. The standardization of those
    practices and the implementations should be revised as soon as
    possible to use only single-usage dialogs.

kind regards.

min

On 07/07/2012 12:20 AM, Min Wang wrote:
         

HI Emil:

    thanks for the infor!

       Another thing I noticed is: that subscribe
           

(event=remote-control) is sent within the invite-initiated dialog.
       

     It is legimate from RFC, but would it be simpler/easier to
           

send the subscribe (event=remote-control) without using the existing
invite dialog? Let this subscribe to setup its own dialog?
       

     One potential reason is: sip proxy may want subscribe/notify
           

  take different route-set ( than the one setup by the invite intiated
dialog ).
       

e.g.: sip proxy may route voice/video invite to a SBC, but just
           

relay subscribe/notify without SBC.
       

     there were some discussion about it.

  https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-June/013198.html

      Any advantage to send that subscribe within the
           

invite-initiated dialog?
       

kind regards.

min

On 07/06/2012 11:38 PM, Emil Ivov wrote:
           

Hey Min,

On 06.07.12 19:15, Min Wang wrote:
             

Hi Emil

       Thanks a lot for the info.

       Since I have left the office, so do not have that 64bit test
environment.
       but I used the my local KVM tested the 32bit 4103 version
               

on the
       

windows-xp and did the trace.

       Here is the finding:

     (1) the Jitsi configure is configured to use " Enable SIMPLE
               

mode"
       

     (2) when jitsi screen share, it try to subscribe event:
               

remote-control,
       

         since our sip proxy does not support it, so it rejected
               

it, never
       

relay to the client2.

        thus the client2 will never send out any NOTIFY.

        so it is our proxy's issue.

      (3) I just did the quick google search for remote-control,
               

seems
       

could not find where the remote-control event package is defined?
               

Could
       

you point out the right documents about this?
               

The event package is called "remote-control".

We haven't published it in a document yet though.

Cheers,
Emil
             

kind regards.

min

On 07/06/2012 05:55 PM, Emil Ivov wrote:
               

Hey Min,

Jitsi uses NOTIFY requests to notify the remote party of mouse
                 

and key
       

events. Could you please check if those go from one party to the
                 

other?
       

Emil

On 06.07.12 17:53, Min Wang wrote:

Hi Vincent
         thanks a lot.

         The same version are used on debian 6. the protocol is SIP.

         Yes, I tried again, still not working.

          Please see the attached log files ( I guess those are
                   

the log
       

file you mentioned? the log file are from Jitsi->options->
                   

logging)
       

          client1 --> sip/kamailio proxy (and rtp-proxy) -->
                   

client2
       

          the client1 is called testuser1
                client2 is called testuser2

           If you need further packet level traces, let me know.

thanks again.

min

On 07/06/2012 05:34 PM, Vincent Lucas wrote:

Hi Min,

I have no problem with remote access under the same Jitsi
                     

version with
       

debian 64 bits (there is no particular configuration for this
functionality).

- Does the remote peer used the same Jitsi version?
- What is the protocol used (SIP or XMPP)?
- If the issue continues, may I ask you to provide the log
                     

files [0]?
       

Regards,
Vincent

[0] https://jitsi.org/index.php/Documentation/FAQ#logs

On 07/06/2012 05:00 PM, Min Wang wrote:

Hi

I have tried the Jitsi: 1.1-nightly.build.4103 on Linux amd
                       

64 bit
       

version. ( configured with sip etc)

The enable remote control seems not working: after checked
                       

the enable
       

remote control checkbox, at remote PC, moving the mouse, the
                       

mouse does
       

not move at all at the local PC?

Anything need to be configured or this feature is known not
                       

working at
       

this stage?

thanks.

min


#16

Hi Min,

HI Emil

Thanks again.

I have created the issue at:

http://java.net/jira/browse/JITSI-1056

BTW, we managed to pass the SUBSCRIBE/NOTIFY through our proxy. Now the
remote control is working with our platform. that is a cool feature.

Now new issue:

do you have any idea how much bandwidth the mouse/keyboard stream will
consume?

No exactly, but for example the mouse move event is sent at a maximum of 1 message per 50 ms. The other events (mouse click and keyboard events) are sent once they occurred.

Hope this helps.

Regards,
Vincent

···

On 07/10/2012 03:08 PM, Min Wang wrote:

On the proxy server, we have a module to protect DOS attack. The mouse
move cause a lot of NOTIFY, and it is easily being tagged as DOS attack.
Of course we have to improve this.
But at the same time is it possible to have some configurable parameters
to control how much the mouse event/per second etc can be sent, does it
make sense in terms of remote-control?

kind regards

min

On 07/10/2012 01:04 PM, Emil Ivov wrote:

Hey Min,

On 07.07.12 16:33, Min Wang wrote:

HI Emil

Thanks a lot for the explaination.

The main reason for keeping this within the dialog is that remote
control messages directly refer to it and have no sense outside of its
context. Desktop streaming is no more but a video flow and remote
control messages are just feedback on that flow.

More specifically, if they didn't belong to a dialog, we wouldn't
always know what to match them to. Imagine a user sharing two separate
parts of their screen (or two separate screens for that matter) in two
simultaneous calls to someone else. Incoming remote control messages
in this case would be ambiguous without the dialog. I admit the use
case is a stretch but I see no reason not to support ... given that
support doesn't cost much.

That being said we'd still be in trouble if both regions were shared
over the same dialog ... so I guess we'd still need a way to reference
a specific stream.

The following is just my naive thoughts, may not make any
sense at all, so please bear with me.:slight_smile:

Let us say if we try to follow the RFC 5057, use
single-usage dialogs ( that means one dialog only for one purpose ).

client1 ------------------------> client2

for screen share area 1:

there will be two dialogs for area1:
(1.a) invite initiated dialog, mainly for the video stream
(1.b) subscribe-initiated dialog:

client1 send subscribe to client2

SUBSCRIBE: sip:client2
event: remote-control, id=streamid-for-area1
..

once client2 received it, from the id it could
associated the area1 with id=streamid-for-area1.
Now mouse move at client2, if there is just one area,
it is easy, just send NOTIFY back using that (1.b) dialog.

Now if there is another screen share area 2, there will be
another 2 dialogs

(2.a) invite initiated dialog,
(2.b) subscribe initiated dialog:
SUBSCRIBE: client2
event: remote-control, id=streamid-for-area2

The problem is that there is currently no such thing as a stream ID, or,
as I mentioned in my previous mail, there is no way to reference a
specific area the way you do in your example above.

I just had a quick look at KPML (since what we do is pretty similar to
that) and they do seem to use a SUBSCRIBE initiated dialog for KPML
events. They also refer to the call dialog through an "Event" header
containing the Dialog ID of the main call.

They also seem to mention the case where multiple audio streams may be
monitorable ... but I didn't quite understand the solution to that.
Would need to look into it later.

So, to sum it all up, I do agree that it would be better design to take
key and mouse events in a separate dialog, but I am not quite sure when
we will be able to attend to this.

Could you please open an issue?

It is probably also worth mentioning that we were discussing the
possibility of using PseudoTCP for such things and if we do, the above
would be obsoleted.

Cheers,
Emil

The difficult part seems to be : how client2 know one
paticular mouse move belong to which area?

if this this not the issue, notify will follow the
subscribe-initated dialog route-set back to client1, so matching the
NOTIFY with areas seems should not be an issue. ?

Or I may misunderstand or over-simplified something here. ?

Out of curiosity, is this thing causing you specific problems or was
this more of a design question?

We have a sip proxy which handle the invite/subscribe
differently.
to be specific: the INVITE is routed to a SBC (back2back
sip agent) which can do some fancy things, but may not be able to
handle/pass the SUBSCRIBE/NOTIFY transparently.

The SUBSCRIBE/NOTIFY are routed without going through the SBC.

The issue is: if subscribe is sent within the invite
dialog, it follow the same route-set path as INVITE, thus hit the SBC
which can not handle it.

kind regards.

min

Cheers,

Emil

On Jul 7, 2012 12:08 PM, "Min Wang"<ser.basis@gmail.com >>>> <mailto:ser.basis@gmail.com>> wrote:

HI:

Just FYI Actually there is a RFC 5057, which suggests:

Handling multiple usages within a single dialog is complex and
introduces scenarios where the right thing to do is not clear.
Implementations should avoid entering into multiple usages whenever
possible. New applications should be designed to never introduce
multiple usages.

There are some accepted SIP practices, including transfer, that
currently require multiple usages. Recent work, most notably GRUU,
makes those practices unnecessary. The standardization of those
practices and the implementations should be revised as soon as
possible to use only single-usage dialogs.

kind regards.

min

On 07/07/2012 12:20 AM, Min Wang wrote:

HI Emil:

thanks for the infor!

Another thing I noticed is: that subscribe

(event=remote-control) is sent within the invite-initiated dialog.

It is legimate from RFC, but would it be simpler/easier to

send the subscribe (event=remote-control) without using the existing
invite dialog? Let this subscribe to setup its own dialog?

One potential reason is: sip proxy may want subscribe/notify

take different route-set ( than the one setup by the invite intiated
dialog ).

e.g.: sip proxy may route voice/video invite to a SBC, but just

relay subscribe/notify without SBC.

there were some discussion about it.

https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-June/013198.html

Any advantage to send that subscribe within the

invite-initiated dialog?

kind regards.

min

On 07/06/2012 11:38 PM, Emil Ivov wrote:

Hey Min,

On 06.07.12 19:15, Min Wang wrote:

Hi Emil

Thanks a lot for the info.

Since I have left the office, so do not have that 64bit test
environment.
but I used the my local KVM tested the 32bit 4103 version

on the

windows-xp and did the trace.

Here is the finding:

(1) the Jitsi configure is configured to use " Enable SIMPLE

mode"

(2) when jitsi screen share, it try to subscribe event:

remote-control,

since our sip proxy does not support it, so it rejected

it, never

relay to the client2.

thus the client2 will never send out any NOTIFY.

so it is our proxy's issue.

(3) I just did the quick google search for remote-control,

seems

could not find where the remote-control event package is defined?

Could

you point out the right documents about this?

The event package is called "remote-control".

We haven't published it in a document yet though.

Cheers,
Emil

kind regards.

min

On 07/06/2012 05:55 PM, Emil Ivov wrote:

Hey Min,

Jitsi uses NOTIFY requests to notify the remote party of mouse

and key

events. Could you please check if those go from one party to the

other?

Emil

On 06.07.12 17:53, Min Wang wrote:

Hi Vincent
thanks a lot.

The same version are used on debian 6. the protocol is SIP.

Yes, I tried again, still not working.

Please see the attached log files ( I guess those are

the log

file you mentioned? the log file are from Jitsi->options->

logging)

client1 --> sip/kamailio proxy (and rtp-proxy) -->

client2

the client1 is called testuser1
client2 is called testuser2

If you need further packet level traces, let me know.

thanks again.

min

On 07/06/2012 05:34 PM, Vincent Lucas wrote:

Hi Min,

I have no problem with remote access under the same Jitsi

version with

debian 64 bits (there is no particular configuration for this
functionality).

- Does the remote peer used the same Jitsi version?
- What is the protocol used (SIP or XMPP)?
- If the issue continues, may I ask you to provide the log

files [0]?

Regards,
Vincent

[0] https://jitsi.org/index.php/Documentation/FAQ#logs

On 07/06/2012 05:00 PM, Min Wang wrote:

Hi

I have tried the Jitsi: 1.1-nightly.build.4103 on Linux amd

64 bit

version. ( configured with sip etc)

The enable remote control seems not working: after checked

the enable

remote control checkbox, at remote PC, moving the mouse, the

mouse does

not move at all at the local PC?

Anything need to be configured or this feature is known not

working at

this stage?

thanks.

min

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org