turnserver-devel — Discussions on development of TurnServer

[Turnserver-devel] bug in allocate response?

[sthustfo <sth...@gm...>]

Hi Seb,

I am using turnserver-0.5 and seeing that the 401 response to allocate
request does not have the fingerprint attribute. This might be the case
with other responses as well, but I have not checked.

But RFC 5389 sec 10.2.3 mentions that

The client looks for the MESSAGE-INTEGRITY attribute in the response (either
success or failure). If present, the client computes the message integrity
over
the response as defined in Section 15.4, using the same password it
utilized for
the request. If the resulting value matches the contents of the MESSAGE-
INTEGRITY attribute, the response is considered authenticated. RFC4250 If
the
value does not match, or if MESSAGE-INTEGRITY was absent, the response MUST
be
discarded, as if it was never received. This means that retransmits, if
applicable, will continue.

So as per the above statement, the stun/ice client might just discard the
401 response and wait for the proper 401 response for ever. Looking at the
security perspective as well, I think adding the message-integrity
attribute makes sense even when sending error response messages.

Let me know what you think.

Thanks,
sthustfo

Re: [Turnserver-devel] Patch for the listen socket of tmpuser

[Sebastien V. <se...@ji...>]

Hi Ryo,

Thank you very much for the patch, it will be commited shortly.

Best regards,
--
Seb

Le 28/11/11 08:36, Ryo Sato a écrit :
> Hello Seb,
>
> This patch fixes that the listen socket of tmpuser is closed when "daemon" is
> "true" in turnserver.conf.
>
> Regards,
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
>
>
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel

[Turnserver-devel] Patch for the listen socket of tmpuser

[Ryo S. <sat...@gm...>]

Hello Seb,

This patch fixes that the listen socket of tmpuser is closed when "daemon" is
"true" in turnserver.conf.

Regards,
-- 
Ryo Sato <sat...@gm...>

[Turnserver-devel] Patch to support turnserver -p pidfile

[Ken C. <ke...@gm...>]

The vivox.pidfile.patch does two things:
1. does chdir("/") instead of chdir("./") when running in daemon mode.
 There is not much point in changing to the current directory, and there is
good reason for a daemon to chdir("/").  I think this must have been a typo.
2. adds support for "turnserver -p pidfile".  This is required to keep
clean track of more than one instance of turnserver running on a box.  On
my 8-core boxes I am sure I can get more steam out of 4 turnservers than I
can out of 1.  I don't include the new Fedora init script in the patch;
that patch is ugly and I will attach that as a complete file.

Notes on the init script:
* If you have only 1 turnserver, its config file and pid file will be
  /etc/turnserver.conf
  /var/run/turnserver.pid
If you have multiple, then you specify a PORTS="3478 3578" in
/etc/sysconfig/turnserver, and the config and pid files have a port_number
suffix:
  /etc/turnserver3478.conf
  /etc/turnserver3479.conf
  /var/run/turnserver3478.pid
  /var/run/turnserver3479.pid

-- 
-Ken

Re: [Turnserver-devel] Patch to fix descriptor leak

[Sebastien V. <se...@ji...>]

Hi Ken,

Thanks for the patch.

IIRC we call getpeername/getsockname to retrieve destination/source 
address needed by turnserver_listen_recv (called from 
turnserver_process_tcp_stream function).

Regards,
--
Seb

Le 11/11/11 03:36, Ken Cox a écrit :
> If the remote disconnects without refreshing their allocations to 0, 
> then we leak a descriptor.  Here is a patch to fix this leak.  I 
> suspect there is another one but I haven't found it yet.  But 
> wait...why in the simple case do we call getpeername/getsockname 
> anyway?  It seems this is needed only for TLS and for an unencrypted 
> socket this is unnecessary work.
>
> Regards,
> -Ken
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
>
>
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel

Re: [Turnserver-devel] Patch for turn_test_client error handling

[Sebastien V. <se...@ji...>]

Hi Ken,

Thank you very much, your patch will be commited shortly.

Regards,
--
Seb

Le 09/11/11 21:37, Ken Cox a écrit :
> I made this patch after I accidentally typed -p password and got the 
> unhelpful message
>
>   getaddrinfo: Success
>
> Cheers,
> -- 
> -Ken
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
>
>
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel

[Turnserver-devel] Patch for turn_test_client error handling

[Ken C. <ke...@gm...>]

I made this patch after I accidentally typed -p password and got the
unhelpful message

  getaddrinfo: Success

Cheers,
-- 
-Ken

Re: [Turnserver-devel] Revised patch to add additional syslog details

[Sebastien V. <se...@ji...>]

Hi Ken,

All of your patches has been commited in SVN trunk.

Thank you very much for your work on TurnServer.

Regards,
--
Seb

2011/11/2 Ken Cox <ke...@gm...>

> This patch supersedes the prior syslog patch.  It
> * Removes the use of __func__ (which is C99 but not supported by
> Microsoft compilers)
> * Changes logging levels so that messages that are interesting to the
> Operations team are NOTICE and above.
>  NOTICE - server stop/start
>  WARNING - quota exceeded
>  ERR - system failed in some way
> * Adds logging for allocation REFRESH
> * Logs error details for various socket-related errors
>
> Regards
> --
> -Ken
>
>
> ------------------------------------------------------------------------------
> RSA&#174; Conference 2012
> Save $700 by Nov 18
> Register now&#33;
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel
>
>

Re: [Turnserver-devel] Patch for TCP nodelay and reuseaddr

[Ken C. <ke...@gm...>]

Hello Seb,

We made the TCP_NODELAY change after audio quality testing.  We were
using TCP from client to turnserver, UDP to the VoIP server, and we
heard jitter in the audio.  After the change it got noticeably better.
 I didn't measure but I could; that would be an interesting test.

Regards,
Ken

On Wed, Nov 2, 2011 at 10:26 AM, Sebastien Vincent <se...@ji...> wrote:
> Hi Ken,
>
> Thanks again for patch.
>
> I will commit all of them in a few hours.
>
> BTW just to know, do you have tested an audio call to measure the impact of
> TCP_NODELAY ? Or you just know that TCP_NODELAY is better for realtime
> applications like VoIP ?
>
> Regards,
> --
> Seb
>
> Le 02/11/11 15:18, Ken Cox a écrit :
>
> This small patch enables the use of SO_REUSEADDR on the TCP listening
> socket (allowing restart of crashed server), and TCP_NODELAY on all
> TCP sockets (improving quality of audio relayed via TCP).
>
>
>
> ------------------------------------------------------------------------------
> RSA&#174; Conference 2012
> Save $700 by Nov 18
> Register now&#33;
> http://p.sf.net/sfu/rsa-sfdev2dev1
>
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel
>
>
> ------------------------------------------------------------------------------
> RSA&#174; Conference 2012
> Save $700 by Nov 18
> Register now&#33;
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel
>
>



-- 
-Ken

Re: [Turnserver-devel] Patch for TCP nodelay and reuseaddr

[Sebastien V. <se...@ji...>]

Hi Ken,

Thanks again for patch.

I will commit all of them in a few hours.

BTW just to know, do you have tested an audio call to measure the impact 
of TCP_NODELAY ? Or you just know that TCP_NODELAY is better for 
realtime applications like VoIP ?

Regards,
--
Seb

Le 02/11/11 15:18, Ken Cox a écrit :
> This small patch enables the use of SO_REUSEADDR on the TCP listening
> socket (allowing restart of crashed server), and TCP_NODELAY on all
> TCP sockets (improving quality of audio relayed via TCP).
>
>
>
> ------------------------------------------------------------------------------
> RSA® Conference 2012
> Save $700 by Nov 18
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev1
>
>
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel

[Turnserver-devel] Revised patch to add additional syslog details

[Ken C. <ke...@gm...>]

This patch supersedes the prior syslog patch.  It
* Removes the use of __func__ (which is C99 but not supported by
Microsoft compilers)
* Changes logging levels so that messages that are interesting to the
Operations team are NOTICE and above.
  NOTICE - server stop/start
  WARNING - quota exceeded
  ERR - system failed in some way
* Adds logging for allocation REFRESH
* Logs error details for various socket-related errors

Regards
-- 
-Ken

[Turnserver-devel] Patch for TCP nodelay and reuseaddr

[Ken C. <ke...@gm...>]

This small patch enables the use of SO_REUSEADDR on the TCP listening
socket (allowing restart of crashed server), and TCP_NODELAY on all
TCP sockets (improving quality of audio relayed via TCP).

-- 
-Ken

Re: [Turnserver-devel] Patch to syslog details for server failures

[Sebastien V. <se...@ji...>]

Hi Ken,

I agree with you, this kind of logging is interresting. I am also OK 
with the WARNING/INFO stuff.

However IIRC the __func__ macro is not POSIX (it is GNU specific) and I 
really want turnserver code to be C99/POSIX compliant. You can see in 
src/dbg.c that I use the file name and line number for debug info. I 
know it is a little bit more difficult to find the function that cause 
the error quickly. Another way to do is a wrapper function that will use 
__func__ it the system is GNU compliant and file/line number for POSIX 
only ones. For the strerror, I prefer to use get_error function (from 
src/util_sys.h) that will use reentrant version of strerror.

Anyway it is a good idea and I look forward to your future patch.

Regards,
--
Seb

Le 01/11/11 18:37, Ken Cox a écrit :
> As mentioned in a recent forum post
> (https://sourceforge.net/projects/turnserver/forums/forum/849587/topic/4787754/index/page/1)
> the server can respond 500 and the reason can be a bit hard to
> determine.  My Operations friends would have a fit if I suggested that
> to debug a 500 server error they used 'gdb' or 'strace'.  So I propose
> to do this: add syslog logging for many server error conditions.  Now
> the diagnosis process is simple: watch for syslog errors.  For
> example, my 500 error was caused by too many open files and now I see
> this in the log as
>
> Nov  1 12:47:54 s_...@xx... TurnServer[27493]: Unable to allocate
> socket: Too many open files
>
> Attached is a proposed pattern of logging.  The basic zen is
> 1) log at a level above INFO if the message is interesting to a system
> administrator, e.g. exceeding allocation quota.  This way the
> interesting messages don't get lost in the sea of INFO messages.
> 2) Include strerror(errno) in the message if available, and __func__
> if it helps disambiguate the caller.
>
> It does not provide anywhere near complete coverage but if noone
> objects I will continue and cover other paths.  Not all error paths
> need to be covered of course.  For example we might not want an error
> inside socket_create() because it is called multiple times in a loop
> inside  turnserver_process_allocate_request().
>
>
>
> ------------------------------------------------------------------------------
> RSA® Conference 2012
> Save$700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
>
>
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel

[Turnserver-devel] Patch to syslog details for server failures

[Ken C. <ke...@gm...>]

As mentioned in a recent forum post
(https://sourceforge.net/projects/turnserver/forums/forum/849587/topic/4787754/index/page/1)
the server can respond 500 and the reason can be a bit hard to
determine.  My Operations friends would have a fit if I suggested that
to debug a 500 server error they used 'gdb' or 'strace'.  So I propose
to do this: add syslog logging for many server error conditions.  Now
the diagnosis process is simple: watch for syslog errors.  For
example, my 500 error was caused by too many open files and now I see
this in the log as

Nov  1 12:47:54 s_...@xx... TurnServer[27493]: Unable to allocate
socket: Too many open files

Attached is a proposed pattern of logging.  The basic zen is
1) log at a level above INFO if the message is interesting to a system
administrator, e.g. exceeding allocation quota.  This way the
interesting messages don't get lost in the sea of INFO messages.
2) Include strerror(errno) in the message if available, and __func__
if it helps disambiguate the caller.

It does not provide anywhere near complete coverage but if noone
objects I will continue and cover other paths.  Not all error paths
need to be covered of course.  For example we might not want an error
inside socket_create() because it is called multiple times in a loop
inside  turnserver_process_allocate_request().

-- 
-Ken

Re: [Turnserver-devel] Patch to fix crash on SIGTERM

[Sebastien V. <se...@ji...>]

Hi Ken,

Thank you.

In addition to your patch, I will add the following diff to 
src/turnserver.c

-  /* free mod_tmpuser */
-  tmpuser_destroy();
+  if(turnserver_cfg_mod_tmpuser())
+  {
+    /* free mod_tmpuser */
+    tmpuser_destroy();
+  }

Regards,
--
Seb

Le 28/10/11 00:16, Ken Cox a écrit :
> If you have mod_tmpuser = false in the turnserver.conf, turnserver
> crashes on shutdown in tmpuser_destroy() calling list_iterate_safe
> (turned out not so safe).  This patch seemed simplest without breaking
> the encapsulation of g_tmpuser.
>
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
>
>
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel

Re: [Turnserver-devel] patch for turnserver-0.5

[Sebastien V. <se...@ji...>]

Hi Ryo,

Thank you again!

I will commit all of your patches in a few hours.

Regards,
--
Seb

Le 28/10/11 08:59, Ryo Sato a écrit :
> Hi Sebastien,
>
> Sorry, the previous patch cause to crash when a SEND-Indication (w/o
> USERNAME and REALM attr in message) was received.
>
> diff -acr turnserver-0.5fix/src/turnserver.c turnserver-0.5fix2/src/turnserver.c
> *** turnserver-0.5fix/src/turnserver.c  2011-10-28 15:13:23.000000000 +0900
> --- turnserver-0.5fix2/src/turnserver.c 2011-10-28 15:14:59.000000000 +0900
> ***************
> *** 2936,2942 ****
>            daddr, saddr, saddr_size);
>
>        /* check for the allocated username */
> !     if(desc)
>        {
>          size_t len = ntohs(message->username->turn_attr_len);
>          size_t rlen = ntohs(message->realm->turn_attr_len);
> --- 2936,2942 ----
>            daddr, saddr, saddr_size);
>
>        /* check for the allocated username */
> !     if(desc&&  message->username&&  message->realm)
>        {
>          size_t len = ntohs(message->username->turn_attr_len);
>          size_t rlen = ntohs(message->realm->turn_attr_len);
>
> Regards,

Re: [Turnserver-devel] patch for turnserver-0.5

[Ryo S. <sat...@gm...>]

Hi Sebastien,

Sorry, the previous patch cause to crash when a SEND-Indication (w/o
USERNAME and REALM attr in message) was received.

diff -acr turnserver-0.5fix/src/turnserver.c turnserver-0.5fix2/src/turnserver.c
*** turnserver-0.5fix/src/turnserver.c  2011-10-28 15:13:23.000000000 +0900
--- turnserver-0.5fix2/src/turnserver.c 2011-10-28 15:14:59.000000000 +0900
***************
*** 2936,2942 ****
          daddr, saddr, saddr_size);

      /* check for the allocated username */
!     if(desc)
      {
        size_t len = ntohs(message->username->turn_attr_len);
        size_t rlen = ntohs(message->realm->turn_attr_len);
--- 2936,2942 ----
          daddr, saddr, saddr_size);

      /* check for the allocated username */
!     if(desc && message->username && message->realm)
      {
        size_t len = ntohs(message->username->turn_attr_len);
        size_t rlen = ntohs(message->realm->turn_attr_len);

Regards,
-- 
Ryo Sato <sat...@gm...>

Re: [Turnserver-devel] patch for turnserver-0.5

[Ryo S. <sat...@gm...>]

Hi Sebastien,

Thank you for your reviewing.
I sent signed contributor agreement on 17 Mar.

Regards,
-- 
Ryo Sato <sat...@gm...>

> Hi Ryo,
> 
> Thank you very much for your patch.
> 
> I will review it more carefully but all seems good.
> 
> (I think you have already signed our contributor agreement, isn't it ?)
> 
> Regards,
> --
> Seb

[Turnserver-devel] Patch to add support for Fedora-based distributions

[Ken C. <ke...@gm...>]

Here is my patch to add support for packaging on Fedora-based
distributions.  I developed these on CentOS 6.  The RPM and init
script are basic, but sufficient for my needs.  To create an RPM:

    make dist
    cp -p turnserver-0.5.tar.gz ~/rpmbuild/SOURCES
    rpmbuild -ba extra/turnserver.spec

Regards,
-- 
-Ken

[Turnserver-devel] Patch to fix crash on SIGTERM

[Ken C. <ke...@gm...>]

If you have mod_tmpuser = false in the turnserver.conf, turnserver
crashes on shutdown in tmpuser_destroy() calling list_iterate_safe
(turned out not so safe).  This patch seemed simplest without breaking
the encapsulation of g_tmpuser.

-- 
-Ken

Re: [Turnserver-devel] patch for turnserver-0.5

[Sebastien V. <se...@ji...>]

Hi Ryo,

Thank you very much for your patch.

I will review it more carefully but all seems good.

(I think you have already signed our contributor agreement, isn't it ?)

Regards,
--
Seb

Le 27/10/11 11:40, Ryo Sato a écrit :
> Hello,
>
> I suggest you the patch for TurnServer-0.5.
>
> * added some error check
> * added realm check
> * fixed some memory leak
> * fixed attribute length in UNKNOWN ATTRIBUTES
> * fixed byte-order
> * fixed allocate-list corruption when another user accesses with same
>    5-tuple (e.g. by REFRESH Request)
>
> Regards,
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
>
>
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel

[Turnserver-devel] patch for turnserver-0.5

[Ryo S. <sat...@gm...>]

Hello,

I suggest you the patch for TurnServer-0.5.

* added some error check
* added realm check
* fixed some memory leak
* fixed attribute length in UNKNOWN ATTRIBUTES
* fixed byte-order
* fixed allocate-list corruption when another user accesses with same
  5-tuple (e.g. by REFRESH Request)

Regards,
-- 
Ryo Sato <sat...@gm...>

Re: [Turnserver-devel] planned turnserver enhancements: PostgreSQL accounts and CentOS packaging

[Sebastien V. <se...@ji...>]

Hi Ken,

Thank you for your interrest in the project.

Le 24/10/11 23:10, Ken Cox a écrit :
> Hello,
>
> I'm planning on making a couple enhancements to turnserver 0.5.  I'm
> broadcasting my intentions here in case anyone wants to weigh in or
> let me know they're already being worked on.

Please use turnserver SVN version for any new development (there is no 
big changes from 0.5 version).
>
> 1. CentOS 6 packaging: RPM spec file and init script

Great :).

Does CentOS RPM packaging differs from other RPM-based distribution like 
Fedora, RedHat, Mandriva, ... ?

>
> 2. PostgreSQL accounts:  I don't want to keep turnusers.txt in sync
> with other pieces of my infrastructure, so I am thinking of using a PG
> stored proc to look up users dynamically when they connect.  Should
> this be a "module" in the spirit of mod_tmpuser?

I don't have a strong opinion about the database being a module or not. 
But I think it should be done with a separated generic database code and 
database-specific code (PostgreSQL, MySQL, ...).

Regards,
--
Seb

> Comments or suggestions welcome.
>
> Regards,

[Turnserver-devel] planned turnserver enhancements: PostgreSQL accounts and CentOS packaging

[Ken C. <ke...@gm...>]

Hello,

I'm planning on making a couple enhancements to turnserver 0.5.  I'm
broadcasting my intentions here in case anyone wants to weigh in or
let me know they're already being worked on.

1. CentOS 6 packaging: RPM spec file and init script

2. PostgreSQL accounts:  I don't want to keep turnusers.txt in sync
with other pieces of my infrastructure, so I am thinking of using a PG
stored proc to look up users dynamically when they connect.  Should
this be a "module" in the spirit of mod_tmpuser?

Comments or suggestions welcome.

Regards,
-- 
-Ken

Re: [Turnserver-devel] Need clarification related to permissions w.r.t TurnServer

[Emil I. <em...@ji...>]

Hey sthustfo,

If you have comments on the spec then wouldn't it be best to take them
to the mmusic mailing list?

Cheers,
Emil

На 16.07.11 10:24, sthustfo написа:
> Hi Sebastien,
> 
> Thanks for pointing out the mail discussion. I believe that ChannelBind
> must deal only with each channel and CreatePermission deal only with
> permission. But anyway, the spec is already adopted as a standard.
> 
> This behavior in the spec throws up ambiguity at the TURN client end.
> Having ChannelBind refresh both the channel and permission does not add
> any value as it is. This is because the permission expires every 5 mins
> and each channel expires at 10 min. So this means, the TURN client will
> have to refresh the permission anyway every 5 mins by sending
> CreatePermission. And in order to keep the channel alive, the TURN
> client has to send ChannelBind every 10 mins. So I am not sure what is
> the gain my having this ambiguity in the spec - that ChannelBind
> refreshes both the permission and chanel.
> 
> I think if we wanted to keep this aspect in the spec, we could have
> approached it in another way. By having 10 mins for permissions and 5
> mins for Channels.
> 
> The TURNserver must have been involved in many of inter ops with other
> TURN clients. How many of them use only channels to manage both the
> permissions and channels? That is use, ChannelBind to create permissions
> and refresh and also use ChannelBind to install channel? Actually I was
> hesitant whether to really put in my views here on the spec's ambiguity,
> but decided to anyway. [Hence the delay in the response].
> 
> Thanks for hearing me out. Let me know if I am missing anything.

> 
> 
> 
> On Mon, Jun 27, 2011 at 1:24 PM, Sebastien Vincent <se...@ji...
> <mailto:se...@ji...>> wrote:
> 
>     Hi,
> 
>     Sorry for late answer.
> 
>     I suggest you read the following links
>     (http://www.ietf.org/mail-__archive/web/behave/current/__msg04374.html
>     <http://www.ietf.org/mail-archive/web/behave/current/msg04374.html>). In
>     short it was decided sometime ago to avoid possible race conditions.
> 
>     --
>     Seb
> 
> 
> 
>     Hi all,
> 
>     I am developing a turn client and using turnserver for testing and
>     verification. I have come across an issue in the turn RFC 5766 related
>     to permissions and need a clarification. Please clarify how this is
>     handled in the turnserver. Also please correct me if I am missing
>     something in my interpretation of the spec.
> 
>     The spec says that (section 8) the client can install or refresh
>     permissions using either the CreatePermission request or the
>     ChannelBind request. And the permission lifetime is 5 minutes.
> 
>     Similarly section 11 mentions that a channel binding lasts for 10
>     minutes unless refreshed.
> 
>     Now, here is the problem I am encountering. Now suppose the turn
>     client creates an allocation, installs a permission using
>     CreatePermission request. TurnServer starts a timer for 5 minutes. And
>     then Turn client binds a channel using ChannelBind request. At this
>     time, the TurnServer will reset the permission back to 5 minutes
>     because of the just received ChannelBind request which refreshes the
>     permission. Turn client will start a timer for<10 minutes assuming
>     the permission is for 10 minutes.
> 
>     After 5 minutes, the permission at the TurnServer expires, which is
>     not what the turn client wanted.
> 
>     If the duration of permission is 5 minutes, then why is the duration
>     of ChannelBind refresh 10 minutes? This will always result in the
>     permissions at the TurnServer expiring well before the Turn client
>     refreshes it.
> 
>     I hope I am not missing anything in the interpretation of the spec
>     here. Please state how does the TurnServer behave in this scenario. Do
>     correct me if wrong.
> 
>     Thanks in advance.
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric 
> Ries, the creator of the Lean Startup Methodology on "Lean Startup 
> Secrets Revealed." This video shows you how to validate your ideas, 
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> 
> 
> 
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel

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