The section you refer to is mostly related to INVITE - the contact addesses exchanged in the INVITE and response to it define where requests are exchanged for the dialog. The validity outside of a dialog is for cases of reestablishing a dialog with the same party, or establishing a new one. (As in the case of REFER.)
Those rules do of course also apply for subscribe/notify. So the contact address returned in the response to a subscribe is what is used for a refresh of that subscription. Other requests in the same dialog also use it, such as sending a subscribe for a different event package to the same place. And while that kind of usage would typically be within the dialog, you could do it outside a dialog to the same address if you wished.
You *could* use the address learned in this way from a subscribe (whether received in the 2xx from the subscribe, or from the first NOTIFY), to send PUBLISH requests. But this would require that the publisher have done such a subscribe, and that it know that the UA answering that subscription was the right place to publish to. There is no particular reason why it should believe this to be the case.
Paul
Franz Edler wrote:
Paul,
my conclusion comes from RFC 3261 (�8.1.1 about the Contact Header): ... the Contact header field value contains the URI at which the UA would like to receive requests, and this URI MUST be valid even if used in subsequent requests outside of any dialogs.
Franz
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Freitag, 11. Juli 2003 17:35
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Franz Edler wrote:
Hi all,
can anybody please confirm my following assumptions on some URIs in SUBSCRIBE/NOTIFY messages:
SUBSCRIBE is a dialog creating method and therefore the addresses sent in the Contact-header of the request and the response should be used as
request
URIs in subsequent requests. Therefore
1. A NOTIFY-request should use the URI of the Contact-header of SUBSCRIBE-request as Request URI.
2. SUBSCRIPTION refresh requests should use the URI of the Contact-header
of
the 200-response to SUBSCRIBE as Request URI.
The above all seems right.
3. If the same UA also uses PUBLISH-requests, it should also adhere to the above rules and use the URIs exchanged in the Contact-headers of existing SUBSCRIPTION based dialogs.
How do you draw this conclusion? PUBLISH isn't dialog creating, and isn't required (or expected) to be sent in the context of a dialog.
Paul
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
