RE: [reSIProcate] Some thoughts on adding OPTIONS handling to the DUM
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@xxxxxxxx]
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@xxxxxxxxxxxx> 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@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
>
>
>
> > _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
>
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca