On Tue, 2005-11-08 at 09:26 -0500, David Stuart wrote:
> I can see how this would be the case for an initial out-of-dialog
> SUBSCRIBE request. But, the in-dialog requests are what is confusing me.
> I thought that the request URI for in-dialog requests should be set to
> the contact from the other side, as specified in RFC3261, no? 
> 
> Section 8.1.1.1 also points to section 12.2.1.1, which seems to indicate
> that the UAC must put the remote target URI into the request URI for in
> dialog requests; unless I am misreading something here (which is
> entirely possible).
> 
> The question is, does the statement in RFC3265 about the Request URI
> having the URI for the presentity apply to all SUBSCRIBE requests, or
> only to the initial dialog-creating one?

My approach to this question is this:

In order for the SUBSCRIBE to be effective, it has to be routed to the
SIP agent which is capable of servicing the subscription.  Normally this
is done by doing an out-of-dialog request, with the URI of the
presentity in question as the Request-URI. The proxy system is
responsible for forwarding the SUBSCRIBE to the correct SIP agent.

As you note, a SUBSCRIBE sent within-dialog must be routed to the
(already established) SIP agent at the far end of the dialog.

I would assert that in most cases, it is impossible for the UA to know
that the SIP agent at the far end of a dialog is the one that can
service the subscription it wants.  Perhaps in some specialized
applications, the UA has special knowledge that that is so.  But in
general, it may be unlikely.  (E.g., many practical SIP systems have
method-dependent routing of requests, as the SIP agents that serve
REGISTER, SUBSCRIBE, and INVITE methods are different.)

So in general, SUBSCRIBEs should never be sent in-dialog, unless the UA
has specific knowledge that the dialog counterpart UA can service the
subscription.  And in that case, it should follow the in-dialog rules,
and the Request-URI should be the remote Contact URI.

Dale


_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to