Re: draft-rosenberg-midcom-turn-07

>I think that I found two problems while implementing TURN:
> 
> The first problem is that the design creates some inefficiencies in the 
> packet processing. Let say E is the endpoint, T the TURN server and R1 
> and R2 two remote destinations that will exchange packets with E through 
> the TURN server. First E want to send a packet to R1 so it wraps the 
> packet in a TURN Send packet, sends it to T, that forwards the original 
> packet to R1.
> At this time, R1 becomes the default destination, and E can directly 
> sends the next packets to T, that will forward them to R1. If R1 sends 
> back a packet to T, the packet will be forwarded back to E. Now let say 
> that E want to send a packet to R2. As R2 is not the default 
> destination, E needs to wrap the packet in a Send request, and send it 
> to T for forwarding to R2. The problem here is that if E want to send 
> packets to R1, it will have to wrap again the packet in a Send request 
> to change the default back to R1. In the worst case if E wants to send 
> packets alternatively to R1 and R2, a Send wrapper must be used for each 
> packet, which can be inefficient - a Send wrapper adds 80 bytes to the 
> size of the packet, and needs more CPU and memory to be processed. A 
> simple modification to the TURN protocol would be to add a parameter to 
> explicitly ask the TURN server to change the default destination - or to 
> use a different request, e.g. SendWithDefault.

Why do you allocate 2 address on TURN server using TURN Allocate Request?
You can use one for speaking with R1, and another with R2.