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

[Scott Godin]

1.	Right.
2.	Good reason for Individual Handlers!  I don't think RFC3261
disallows SDP outside of a dialog.  In fact it states: OPTIONS "allow a
client to discover information about the supported methods, content types,
extensions, codecs, etc. without 'ringing' the other party".  I don't think
automatic handling will be possible.

 

  _____  

From: Derek MacDonald [mailto:Derek at xten.com] 
Sent: Monday, July 12, 2004 4:41 PM
To: 'Scott Godin'; resiprocate-devel at list.sipfoundry.org
Subject: RE: [reSIProcate] Some thoughts on adding OPTIONS handling to the
DUM

 

A couple of points:

1.) A dialog will not be created for an out-of-dialog request, just a
DialogSet.

 

2) I would have individual handlers, then DUM can generate a 405 for
out-of-dialog requests that are not supported.  You could also add a default
options handler for out-of-dialog OPTIONS requests(I don't think these can
have an SDP).  

 

Derek

-----Original
  Message-----
From: resiprocate-devel-bounces at list.sipfoundry.org
[mailto:resiprocate-devel-bounces at list.sipfoundry.org]On Behalf Of Scott
Godin
Sent: Monday, July 12, 2004 1:34 PM
To: 'resiprocate-devel at list.sipfoundry.org'
Subject: [reSIProcate] Some thoughts on adding OPTIONS handling to the DUM

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/9c9496cf/attachment.htm>