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

[Scott Godin]

I'm not suggesting they don't get answered - I'm just suggesting that the
answer will have be controlled by the application and not automatically by
the DUM - since an SDP response may be required.

Any thoughts on how in-dialog OPTIONS should notify an application?  Can we
assume that they only appear in INVITE sessions and add a new notification
member to the InviteSession - ie. onOptions?

Scott

-----Original Message-----
From: kaiduan xie [mailto:kaiduanx at yahoo.ca] 
Sent: Monday, July 12, 2004 5:54 PM
To: Scott Godin
Subject: RE: [reSIProcate] Some thoughts on adding OPTIONS handling to the
DUM

Out dialog OPTIONS must be answered as defined in RFC
3261, some phone use it to keep the mapping in the NAT
router alive.

kaiduan
--- Scott Godin <slgodin at icescape.com> wrote: > 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
> 
>  
> 
> > _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
>
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel 

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca