[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] Open Issue #181: Forking OPTIONS
Issue:
OPTIONS, like any other request,could fork. The response you get back will
be from one of the UA that receives the OPTIONS request. Which one will be
arbitrary. Furthermore, when you send a subsequent request based on that
OPTIONS, no guarantees that it is within the capabilities of any of the
other UA that received the OPTIONS request initially.
Discussion:
THis is a genearl problem with forking. We can take an approach similar to
SUBSCRIBE, and define a "reverse OPTIONS", which contains the capabilities
of each UA. This reverse OPTIONS would be sent by each server back towards
the UA that sent the OPTIONS, much like NOTIFY.
But, I think thats overkill to solve a problem that is not so important. The
limited use of OPTIONS, combined with the limited use of forking, makes this
something which is a don't care. The proposal therefore is:
Proposal:
Document this limitation of OPTIONS with a few sentences.
-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
jdrosen@dynamicsoft.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sip mailing list http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip