Hi Aman,
Some implementations go like this to keep the NAT bindings. The client REGISTERs with its proxy, proxy identifies that the request is from behind NAT through various mechanisms. If the proxy finds that the request is from behind NAT then it sends 200 OK with expiry value say 30 secs depending on its NAT binding time out. Then onwards the client keeps registering with the proxy at that interval. Madhav On 6/16/06, Aman Arora <[EMAIL PROTECTED]> wrote: > > Hi > > Why does the RFC 3581: " symmetric response routing using rport" suggests > to send an OPTIONS request to keep the NAT bindings alive. > > Options request is used by the client to know the capabilities of a > server. > When OPTIONS is sent to keep the NAT binding alive there is has an > overhead at the receiving entity to query its capabilities and return them > in the > response. > Since the request was sent to keep the bindings alive, the returned > response will not be processed at the UA. > > Can we not instead send the "Message" Request to the server with Content > Length set to "0". This can also be used to keep the binding alive > and reduces overhead of any additional processing done in case of > "OPTIONS". Incase the proxy doesn't support the method, it can respond > with the appropriate response. > > The only issue that I see with the MESSAGE method is that it will go all > the way to the other end, while the OPTIONS response will come from the > first hop > and need not be sent to the other end. > > So, what is the advantage of sending OPTIONS over MESSAGE request to keep > the NAT binding alive. > Are there any implementations that support/use any other method(s) to keep > this bindings alive? > > thanks for the response > rgds > aman > > *********************** FSS- Confidential *********************** > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
