reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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

  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@xxxxxxxx]
Sent: Monday, July 12, 2004 4:41 PM
To: 'Scott Godin'; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Scott Godin
Sent: Monday, July 12, 2004 1:34 PM
To: 'resiprocate-devel@xxxxxxxxxxxxxxxxxxx'
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@xxxxxxxxxxxx

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