[reSIProcate] Some thoughts on adding OPTIONS handling to the DUM

[Scott Godin]

DUM Design Team,

 

OPTIONS handling could potentially look at the Profile and DUM could
generate a response - but since options handling may require an SDP answer,
then final handling must be past to the application - via a handler.  We
could add a helper function to generate the initial OPTIONS response, then
the user could add the SDP info and whatever else before calling send.

 

If the OPTIONS request is out of Dialog then a short lived DialogSet and
Dialog should likely be created and the message should be dispatched to
ServerOutOfDialogReq - I think this should in turn call Handler callback
onReceivedRequest.

 

Currently OutOfDialog Handlers are not implemented on the DUM - there is an
addOutOfDialogHandler function - that adds a handler to a list for a
particular OutOfDialog request type.  Is likely to be the final signature of
this function - or should we just have one OutOfDialogHandler registered and
it can handle all message types?

 

If the OPTIONS request is in Dialog - which handler should it be dispatched
to?  The Invite Session is a possibility - but it is possible to receive an
OPTIONS message in a Dialog that is not an INVITE session?

 

Any thoughts on the design of the OPTIONS request handling?

 

 

 

Scott Godin

Research and Development

Computer Talk Technology

slgodin at icescape.com

905-882-5000 and 'Say my name' or x127

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20040712/e0bf493f/attachment.htm>