Subject: [BEHAVE] TURN-12 Comments (refresh)

From: Paul Mackell <[email-masked]>
Date: Wed, 04 Feb 2009 12:48:14 +0100

After implementing a TURN-12 client, I have the following comments
regarding refreshing of  allocations, permissions and channel bindings.

Having to refresh an allocation, refresh a permission and refresh a
channel binding makes the client implementation complex. However, I note
that once a channel is bound then there is no need to refresh the
permission explicitly with a CreatePermissionRequest as
ChanneBindRequest  also  creates/refreshes a permission.  The client
implementation would be simpler if all these refreshes could be carried
out in a single refresh message. i.e. By putting the attributes of 
CreatePermissionRequest and ChannelBindRequest into the Refresh method.
In this way the client would only need to implement a single supervision
timer.   

One issue I have come across is that the default permission lifetime is
300 sec (see section 8).  However, a channelBinding lasts for 10 minutes
(section 11).  The problem is that the ChannelBindRequest also
installs/refreshes a permission and a permission times out after 300
sec. So if the client creates a permission (using
CreatePermissionRequest) then at a later time does a ChannelBind and
refreshes the ChannelBind every 10 minutes then in actual fact, after 5
minutes the permission will timeout, whereas you would expect it to be
10 minutes.  Such is the consequence of placing 2 functions (channel
Bind and create permission) in one method.  Making the 2 timers the same
value would simplify this. 

Paul Mackell
Senior Software Engineer
Tandberg Telecom

---

From: Simon Perreault <[email-masked]>
Date: Wed, 4 Feb 2009 08:24:31 -0500

On Wednesday 04 February 2009 06:48:14 Paul Mackell wrote:
> channel binding makes the client implementation complex.

I agree.

> value would simplify this.

I'm not sure it would make anything simpler from the point of view of the 
client. What you need to do now is to send a ChannelBind every 5 minutes. It 
will automatically refresh the permission.

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.

---

From: Paul Mackell <[email-masked]>
Date: Thu, 05 Feb 2009 09:42:01 +0100

> will automatically refresh the permission.
It would be simpler (to implement and test) in that only one supervision
timer (and wait state) would be required to refresh both the allocation,
the channel binding and the permission.

With the current draft, at worst case 1-3 supervision timers are
required and there is the issue of timers going off "simultaneously".
It would be simple to combine refresh of the allocation and the channel
binding by (optionally) adding the XOR_PEER_ADDRESS and CHANNEL_NUMBER
to the refresh method. We could code the XOR_PEER_ADDRESS/CHANNEL_NUMBER
combination as a new attribute in order to differentiate between a
channel bind refresh and a Permission refresh (the later consisting of
XOR_PEER_ADDRESS only) in the refresh message. 

Some client implementations have many simultaneous media streams e.g.
audio,Video,duo-video,BFC etc... and each of these have both RTP and
RTCP streams resulting in a multitude of TURN allocations, all of which
having their own independent supervision timers, and this is a pain to
debug. Reducing the complexity of the supervision would simplify things.

---

From: Philip Matthews <[email-masked]>
Date: Thu, 5 Feb 2009 18:12:07 -0600

Let me point out that, in practice, the client needs to send some sort  
of packet to the TURN server a lot more frequently than once every 10  
minutes (channel binding lifetime) or even once every 5 minutes  
(permission lifetime). Typical NAT binding lifetimes are two minutes  
or less, with some as low as 30 seconds. ICE recommends keep-alives be  
sent every 15 seconds.

Having said that, I have no problem with changing the channel binding  
lifetime from 10 minutes to 5 minutes if this is what the WG wants.  
(This is, of course, a non-backwards-compatible change, so  
implementors who care should speak up)

- Philip

On Thu, 5-Feb-09, at 02:42 , Paul Mackell wrote:

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>