Subject: [BEHAVE] TURN: ChannelBind response

From: Philip Matthews <[email-masked]>
Date: Tue, 15 Jul 2008 11:47:11 -0400

Scott Godin has suggested, in a private e-mail to me, that a  
successful ChannelBind response contain a CHANNEL-NUMBER and perhaps a  
PEER-ADDRESS attribute. His reasons are that he finds this make  
programming on the client side a bit easier.

I personally find this request a bit odd, since no other request does  
something similar, but I would like to hear from other working group  
members. Would anyone else like to see this?

Comments?

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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Jul 2008 13:00:28 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Philip Matthews
> Sent: Tuesday, July 15, 2008 8:47 AM
> To: Behave WG
> Cc: Scott Godin
> Subject: [BEHAVE] TURN: ChannelBind response
> 

The client needs to remember the CHANNEL-NUMBER and PEER-ADDRESS
anyway, in order to re-transmit the Request (and other things, too,
like the transaction-id, username, etc.).

I'm not sure what it saves, but maybe Scott could elaborate.

-d

---

From: "Scott Godin" <[email-masked]>
Date: Wed, 16 Jul 2008 20:55:59 -0400

I agree that implementations will need to store the request and should
have access to this information by doing a TID lookup in some kind of
request map.  I suggested that at least channel number be added to the
ChannelBind response not out of necessity, but because I felt it could
make life easier for some client implementations - at least that was
the case for the reTurn implementation I worked on
(https://www.resiprocate.org/ReTurn_Overview).  For some
implementations, if this information is included in the response, then
it is possible that the request lookup is avoidable (ie. authenicated
request over TCP or TLS).

Scott