What, if anything, should the SER server do with a OPTIONS method?
I am receiving this method, from a phone, right after the phone makes a conversation. That is, the final ACK is sent from the phone and a call is in progress when the phone decides to send an OPTIONS message. I thought OPTIONS was a pre-call sort of thing, not for the current call.
Anyway, I thought I could just capture the OPTIONS method and send a 486 busy reply with sl_send_reply(). Didn't work.
---greg
Think of OPTIONS as "INVITE simulation". Some phones use it (I think Pingtel), though I'm not aware of a big use for it in phones now. We use it for trace-route-like functionality in Sipsak.
-Jiri
At 12:27 PM 3/11/2003, Jan Janak wrote:
-- Jiri Kuthan http://iptel.org/~jiri/
Hi Greg,
OPTIONS is a request which determines the capabilities of the destination. A UA or a proxy should answer with its supported features (see RFC for details). I think Ser is currently not able to answer such a request correctly. But i have never seen a UA which queried the server. You can send an OPTIONS whenever you want, for example to change the connection with a re-INVITE, allthough it makes more sence to query the capabilities before a connection.
But OPTIONS is also used for "traceroute" (see RFC for details, and sipsak for an implementation) because it do not establish a call to the UA.
Regards Nils
On Tuesday 11 March 2003 05:04, Greg Fausak wrote:
Hi Nils,
I am forwarding the OPTIONS message from the UA to my gateway (cisco 7206 / pa-vxc-2te1+ / sip) and the gateway is returning what looks like the answer to an INVITE request. I have a pretty current gateway. The UA tries over and over sending one after the other OPTIONS messages. I think it doesn't like the reply from the gateway.
What is weird about the OPTIONS request is that it is including the established Callid.
I tried grabbing the message in the Ser proxy and sending a 486 busy.
Thanks for the help. Most UAs do not present any problems, but this one has been very challenging.
---greg
Hi Greg,
this is definatly wrong behavior of the UA because OPTIONS is not part of the call establishing with INVITE and should have a new CSeq.
For our own knowledge base: which UA has such a strange OPTIONS implemetation? :-)
Greetings Nils
On Tuesday 11 March 2003 14:40, Greg Fausak wrote: