Brett,
I presume the answers you gave are a result of private communication with the authors.
I can't see any way to find those interpretations as normative or implied by anything
in the RFCs.
I don't see anything fundamentally wrong with the answers you suggest, though I would
prefer different answers. But mostly I am concerned that all implementors interpret
these things in a consistent way.
How are clarifications to an RFC supposed to be documented if there is currently no
work in progress on a bis?
More comments inline below.
Paul
Brett Tate wrote:
>
> > 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?
> >
> > Specifically, what happens if I send an INVITE
> > within a dialog established by a SUBSCRIBE?
> > Does it share the dialog, or does it result
> > in an error of some sort?
>
> Good question. It exposes a potential
> complication with the 481 response when
> sharing invites and subscribes on a single
> dialog.
>
> The response could be a 481 to the
> INVITE because of the To tag
> and no active call.
I gather that you are saying this should be an error.
> However should
> the 481 also trigger a reaction
> concerning the subscription? Or
> should a 481 to SUBSCRIBE/NOTIFY only
> apply to the subscription part of
> the dialog; and a 481 to INVITE only
> apply to the invitation part of the
> dialog?
I think this highlights some areas where things didn't get cleaned up fully after the
introduction of dialogs.
"Call Leg" could be read here to simply be the obsolete name for "dialog". But with
that interpretation 481 is an inappropriate response, because the dialog *does* exist.
Or "Call Leg" could be read here to mean the call-specific part/extension to a dialog.
If so, then it would be appropriate here, but it would be inappropriate when no match
is found for a subscription with a tag.
Or the description of 481 could be changed to "Call Leg/Subscription/Transaction Does
Not Exist".
Or it could simply be declared legal to start a new call within a dialog that doesn't
yet have one.
>
> Assuming a 405 and Allow header can be
> considered dialog specific, the 405
> with an Allow header might be a better
> response.
That doesn't seem quite right either. Because the method *is* allowed, even within a
dialog. It is a particular type of use of the method that is illegal.
>
> > 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.
> >
> > RFC 3265 doesn't explicitly mention target
> > refresh or remote target. It does however discuss
> > refreshing of subscriptions for the purpose of
> > changing the expiration time. It also fails to
> > discuss explicitly what target address is used for
> > notifications, though it does say:
> >
> > This NOTIFY message is sent on the
> > same dialog as created by the SUBSCRIBE response.
> >
> > By inference, the Contact header in a dialog
> > creating SUBSCRIBE must define the notifier's
> > remote target.
> >
> > 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?
>
> Based upon a response that I received from
> Adam last April, the answer is that the
> Contact can't be updated. The reason cited
> was the desire to reduce complications caused
> by invitations and subscriptions potentially
> sharing the same dialog.
Well, that would simplify things.
By implication, any other future sip extension that creates dialogs would presumably
have to follow the same rule, because the same arguments apply. The effect would be to
create first and second class citizens in dialogs - calls are first class, while any
other user of a dialog is 2nd class. Only 1st class citizens can do target refreshes.
(This isn't necessarily bad - INVITE is clearly first among equals in SIP.)
Then the language in 3261 that suggests other extensions may define new ways of doing
target refresh would be invalid.
Seems like it would be simpler to say that a dialog has one remote target (at each
end), and it can be refreshed by any target refresh that is otherwise valid in the
dialog. (So a target refresh by a Subscribe would affect a call that shares the
dialog.)
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
