Adam,
Thanks for the answers and the clarification.
Questions and comments inline.
> > 1) ---------------------------------------------
> >
> > According to RFC 3265, it is legal to send a
> > SUBSCRIBE within a dialog
> > established by an INVITE. In this case, the
> > subscribe, the invite, and all
> > the notifies resulting from the subscribe share
> > the same dialog.
> >
> > Q: Is the converse true?
>
> Yes; that is the intention. I don't expect to
> see it happening very much, but the protocol
> is intended to allow it.
Allowing this introduces some complexities.
Here are two:
1a) It makes the presence of a To-tag no
longer sufficient enough to distinguish
an invite from re-invite.
1b) How does a 481 response to an INVITE
over a subscription dialog effect the
subscription dialog?
> > 2) ---------------------------------------------
> >
> > Q: Can a SUBSCRIBE cause a target refresh?
> >
> > RFC 3261, section 12.2 says:
> >
> > For dialogs that have been established with an
> > INVITE, the only target refresh request defined
> > is re-INVITE (see Section 14). Other extensions
> > may define different target refresh
> > requests for dialogs established in other ways.
>
> That's somewhat unfortunate phrasing, and I don't
> think the intention was quite what was said there.
> (We attempted to harmonize 3261 with 3265 before
> they were both released, but 3261 is large enough
> that something was bound to be missed).
The wording was added to explicitly prevent
extension draft requests from altering an
the invite-dialog's route.
However I agree that it appears to no longer
be applicable since RFC 3311 also violates
the text by allowing UPDATE to refresh the
target within an invite-dialog.
> > Analogy to 3261 would suggest that a SUBSCRIBE
> > used to refresh a subscription could refresh the
> > target by including a Contact header with a
> > new value. Is this valid? If not, what should
> > happen if it is attempted?
>
> That is the intention. The dialog handling in 3265
> is a bit under-specified, and will be cleaned up
> in the next version.
Can the targets also be refreshed by a
new Contact supplied during the following:
a) SUBSCRIBE's 2xx response?
b) NOTIFY?
c) NOTIFY's 2xx response?
d) Future extension drafts which define
target-refreshing-requests for a
subscription-dialog?
> > 3) ---------------------------------------------
> >
> > Suppose a dialog has been established by an
> > INVITE. Then, a SUBSCRIBE is sent within this
> > dialog. Further, suppose that the Contact
> > header in the SUBSCRIBE differs from the the
> > remote target of the invite dialog.
> >
> > Q: Is this SUBSCRIBE considered a target
> > refresh request?
>
> This is an example of where the dialog handling
> in 3265 is underspecified. My intention is to
> clearly define SUBSCRIBE as a target refresh
> request in future revisions. Of course,
> consensus may take us in a different direction.
Hopefully we can get this resolved
for those implementing RFC3265.
BTW, I'm not looking forward to resolving
all the race conditions concerning target
refreshing among all the INVITE, UPDATE,
SUBSCRIBE, 2xx, and future requests.
Over an invite-dialog, can two SUBSCRIBE's
successfully occur in opposite directions
at the same time? Should the Contact of
the 2xx or SUBSCRIBE be used for the
target refresh?
Should a 2xx invite response Contact take
precedence over a just received SUBSCRIBE?
How do we know which was actually sent
first by the called party?
Without timestamping all requests and
responses, one solution for all
these race conditions is to immediately
try multiple locations to resolve the
ambiguity. Does anyone have another
suggestion?
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
