The use of OPTIONS request is not at all limited to know the capabilities of the Server nowdays. It is being used for lots of other purposes as well. In all these cases the OPTIONS requests/responses are without any body to make life easy for End Points.
As an example, OPTIONS is used as a mechanism by lots of networks to keep track of health of Servers and switch traffic to the servers that are responding. Using this for keeping NAT pinhole alive was something that has been discussed in this forum of may be sip mailing list for quite a while now.
Infact, Frank Miller had come up with a draft on usage of new method PING, whic was very very similar to OPTIONS but had some advantages whic he had highlighted. This can be found if you search on draft-fwmiller-ping-01.txt
regards
Rayees
To: <[email protected]>
From: Aman Arora/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
Date: 06/16/2006 05:05AM
cc: Aman Arora/[EMAIL PROTECTED], Abhishek Chhibber/[EMAIL PROTECTED], Deepti Goyal PRD-NGN/[EMAIL PROTECTED]
Subject: [Sip-implementors] Query on the use of OPTIONS for refreshing theNAT bindings
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
*****FSS-Private *****" DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
