< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index |
I think I found a use case for Options to
be handled by the invite session.... With my latest commit (to the teltel
branch), we are attempting to store the peer capabilities (ie. Allow/Support/etc
headers) if they are sent in an inbound INVITE or 200 response to our INVITE. We
do this in order to determine whether or not the peer supports UPDATE requests
(currently for SessionTimers and TargetRefreshes). But it is not a
requirement that a UA provide this info during call setup. You can, of
course, query this info by forming an OPTIONS request. Thus to have the
InviteSession store the info in an Options response, the response should be
dispatched through the InviteSession. How do you guys feel about the following?
From: Derek MacDonald
[mailto:derek@xxxxxxxx] A general question about OPTIONS: is
anybody doing something different with options requests if they are in our out
of dialog? Before we implement anything, we should see if we can unify
our options handling logic. OPTIONS are valid in subscribe dialogs. From:
resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Godin Does anyone know if the OPTIONS request is valid in Dialogs
other than ones initiated via INVITE (ie. Subscription)? |