OK. In that case, your statement:
>>>The proxy responds with a 202 Pending, and then sends a NOTIFY request >>>with subscription-state pending.
is misleading in its use of the term "proxy", because the proxy in this case is not acting as a proxy - it is acting as a UAS for the subscribe.
With that cleared up, the answer is yes, the notify MUST be sent within the dialog established by the subscribe.
Paul
David Stuart wrote:
From what I understand, in the case of presence the registrar can act asa UAS for SUBSCRIBE requests. This is because it's really the authority on who is currently "logged in". I think what went unsaid in my previous e-mail was that I am assuming the proxy and registrar are the same server.
On Fri, 2003-07-11 at 11:31, Paul Kyzivat wrote:
I don't think I understand your question.
If the subscribe is sent to a something acting as a proxy, the proxy should not respond with a 2xx. If it responds with a 2xx it is acting as a UAS. This must establish a dialog.
This seems to have nothing to do with a registrar or registrations.
I have a feeling that you have something else in mind, but you need to explain it more fully.
Paul
David Stuart wrote:
Hi All,
I have a question regarding SUBSCRIBE and NOTIFY requests with a proxy in between, relating mostly to Dialogs. Here is the situation:
1) One (registered) UA 2) One proxy/registrar
The UA registers to the proxy and immediately sends a SUBSCRIBE for a resource (for argument's sake let's use presence as an example since it is the most well known).
The first subscribe request is outside of a dialog, and I believe is considered to be a dialog-creating request. As such, there is a CallId and the From: "tag" is set (but there is no "To:" "tag" yet).
The proxy responds with a 202 Pending, and then sends a NOTIFY request with subscription-state pending.
My question is, should this NOTIFY request be inside or outside of the dialog (I am assuming inside, but want to check).. That is to say, are the callId and both the From "tag" and To "tag" set at this point?
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
