El Thursday 21 August 2008 10:12:51 Attila Sipos escribió:
> hmmm... not so sure now.
>
> I can see that a client must not generate a CANCEL.
> Maybe a proxy can.
>
> I have a few questions myself:
> 1. of what use is a CANCEL for OPTIONS? Won't the OPTIONS
> just be responded to very quickly anyway.
> I doubt the CANCEL would ever arrive in time to have
> an effect unless somehow the OPTIONS took a long time.
9.1 Client Behavior
Since requests other than INVITE are responded to immediately,
sending a CANCEL for a non-INVITE request would always create a
race condition.
> 2. what use is forking an OPTIONS anyway?
> Isn't the purpose of OPTIONS to find out capabilities
> of a specific UA?
IMHO OPTIONS is a very buggy method. If the destination has various locations,
the proxy will just forward the 200 of the first location responding, it
makes no sense.
In fact, I'd really like to know other use *in real life* for OPTIONS except
being a SIP ping method.
I hope **no one UAC** will send an OPTIONS before other request to check if
the UAS allows this request method. Note this example:
- user_A wants to send a MESSAGE to user_B.
- user_B i registered in phone_B1 and phone_B2.
- phone_B1 allows MESSAGE while phone_B2 not.
- user_A sends an "OPTION sip:user_B".
- The proxy forks the OPTIONS to phone_B1 and phone_B2.
- phone_B2 replied before so this is the reply proxy forwards to user_A.
- So user_A will not send the MESSAGE since the "Allow" in the 200 OK (sent by
phone_B2) doesn't include "MESSAGE".
So, IETF people: please remove completely the OPTIONS method.
> 3. if the OPTIONS is forked - and the first fork responded
> with 200 OK? What does the proxy do with subsequent
> 200 OKs?
17.1.2.2 Formal Description
If a final response (status
codes 200-699) is received while in the "Trying" state, the response
MUST be passed to the TU, and the client transaction MUST transition
to the "Completed" state.
...
If a
final response (status codes 200-699) is received while in the
"Proceeding" state, the response MUST be passed to the TU, and the
client transaction MUST transition to the "Completed" state.
...
Once the client transaction enters the "Completed" state, it MUST set
Timer K to fire in T4 seconds for unreliable transports, and zero
seconds for reliable transports. The "Completed" state exists to
buffer any additional response retransmissions that may be received
But a 200 for other branch (when forking) doesn't match an already received
200 OK from other branch so, what should do the proxy?
IMHO the text should be:
The "Completed" state exists to
buffer any additional response retransmissions or other responses from
other location in case of paralllel forking.
--
Iñaki Baz Castillo
[EMAIL PROTECTED]
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
