Hi, Salman: Thanks for your comments. Response in line.
Regards Jiang XingFeng > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Thursday, January 15, 2009 4:50 PM > To: Roni Even > Cc: [email protected] > Subject: Re: [P2PSIP] new draft-jiang-p2psip-relay-01 > > There are at least two issues to make direct response work in RPR > which can be more explicitly addressed in the draft: > > a) TURN server permissions > b) TURN server transport address > > a) TURN server creates a permission on the basis of IP/port tuples. > When sender requests a direct response for a request sent in a > recursive manner, the IP/port tuples become irrelevant. Rather, the > message identifier in the RELOAD message has to be used for matching > responses to requests. This will need a new TURN profile. > > b) The request originator must specify the IP address and port on > which the response will be received. RPR does not try to use the TURN server to relay the response. Rather it tries to use a relay peer to forward the response from the destination peer to the source peer. The relay peer should be tested as publicly reachable. A typical message flow for a RPR is as follows: 1. Peer A behind NAT finds one or more relay peers who are publicly reachable; 2. Peer A uses Attach methods to create direct connection between Peer A and Relay peer; 3. Peer A sends a request which indicates RPR routing modes and includes relay peer's transport address; 4. When the request reached the destination, the destination peer will try to send response back to the relay peer because of RPR by populating the destination list for entry with relay peer and peer A in sequential order. 5. Upon receiving the response, what Relay peer does is to check the connection table to see whether it has direct connection with entry in destination list,(currently, it is peer A) A. Then relay peer forward the response as normal response. As you said, TURN has some trouble in relaying response because of its address-dependent filtering behavior because peer A does not who will be the target of the message. I hope you can understand my explanation. Maybe I should add more text to show the difference between relay peer and TURN server. > > For DPR, the draft should clearly state that the response must not be > encapsulated within a STUN/TURN message. As explained above, RPR will not use TURN, so that the response will not use STUN/TURN to encapsulate. > The draft should also specify that if ROUTE-QUERY is used, there is no > need for direct or relay response routing. Ok. It is better to forbid using ROUTE-QUERY when RPR or DRR is to be used. > > -salman > > > > Quoting Roni Even <[email protected]>: > > > Hi, > > > > > > > > In Minneapolis we presented draft-jiang-p2psip-relay-00. There was a hum > > that showed consensus to add support for direct route mode. On the issue of > > using relay peer and discovering of NAT behavior the decision was to > > continue the discussion on the list. > > > > > > > > One of the questions in the meeting was about using TURN for getting a relay > > peer service. This topic was discussed in a separate thread pointing out > > that the sending peer does not know that the address of the target and > > cannot tell it to the TURN server, so that TURN server will discard the > > message from the target of the message. The other point was that using relay > > peer is an optional mode and is not dependent on discovery of NAT behavior, > > for example the relay peers can be provisioned by the service provider or > be > > part of the bootstrap peers. > > > > > > > > We updated the draft and submitted draft-jiang-p2psip-relay-01. In the > > updated draft we tried to separate the NAT behavior discovery, offering > > options to find relay peers from the issue of how to use a relay peer. > > > > The draft explains that the sender of the request decides if to offer direct > > response or a relay peer as the recommended response method based on trying > > to find if it has a publicly reachable address or looking for relay peer > > service. It can have better success based on past experience. The sender > of > > the request can try, for example, using a relay peer and if fails to get a > > response he can switch to symmetric routing when retrying the request. > > > > > > > > We hope that the new draft addresses the questions and people are more > > comfortable with these optional modes. > > > > > > > > Please review the new draft. You can get the draft by accessing the link > > http://tools.ietf.org/id/draft-jiang-p2psip-relay-01.txt > > > > > > > > Thanks > > > > Roni Even > > > > > > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
