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:

Hello Greg,

If the OPTIONS request is targeted to the other UA involved in the conversation, then the proxy should simply forward the request there and the other UA is supposed to send a reply.

Jan.

On 10-03 22:04, Greg Fausak wrote:

...

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 _______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Jiri Kuthan http://iptel.org/~jiri/

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,

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:

...

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 _______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Hello Greg,

On 11-03 07:40, Greg Fausak wrote:

What is weird about the OPTIONS request is that it is including the established Callid.

That is imho fine as long as CSeq in OPTIONS has higher value than CSeq in INVITE.

Jan.