Re: [Sip] WGLC for PUBLISH

Hi Shinji,

The key thing here is that there is nothing special about how a proxy 
determines the next hop target for PUBLISH requests. There are several 
options to doing this:

	- A domain has configured all PUBLISH requests to be
	  forwarded to a PA
	- A PA has explicitly added an address binding for that
	  AOR, possibly using the SIP registration
	- All requests get forwarded to a UA (no matter what the
	  method is) that has an active address binding in the
	  domain's location service for that AoR
	- The request gets targeted using some other, undefined
	  logic

The administrator for that domain just needs to pick a way of doing 
this. So when proxying a PUBLISH request, Section 16 in RFC 3261 applies 
in full.

Cheers,
Aki

ext OKUMURA Shinji wrote:

> Hi Aki,
> 
> Thank you for your comments.
> 
> You say that R-uri is used to determine what resource the PUBLISH is
> targeted for. But R-uri has the possibility to be rewritten by proxy.
> 
> 
> Even if PUA sends "sip:presentity@example.com", 
> "sip:presentity@pa.example.com" may reach to PA.
> 
> Now my questions are:
> 
> a) PUBLISH message MUST NOT pass proxy?
> 
> b) proxy MUST NOT rewrite R-uri?
> 
> b-1. the uri MUST NOT be registered? b-2. Register-Contact is
> <sip:presentity@example.com;maddr=pa.example.com> ? b-3. original
> message has Route: <sip:pa.example.com;lr> ?
> 
> c) PA MUST determine the target resource ONLY by username of R-uri?
> 
> Best regards,
> 
> 
> Shinji
> 
> aki.niemi@nokia.com wrote in
> <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D92C9@esebe013.ntc.nokia.com>
> 
>> Hi Shinji,
>> 
>> Thanks for the comments. Answers inline.
>> 
>> 
>>> -----Original Message----- From: ext OKUMURA Shinji
>>> [mailto:shin@softfront.co.jp] Sent: 15 January, 2004 12:49 To:
>>> Rohan Mahy Cc: sip@ietf.org; Dean Willis; Niemi Aki
>>> (Nokia-M/Helsinki) Subject: Re: [Sip] WGLC for PUBLISH
>>> 
>>> 
>>> Hi,
>>> 
>>> [1] I believe it requires following changes in some headers of 
>>> the illustrated example in section 12.
>>> 
>>> In M1,   Contact: <sip:watcher@example.com> should be rewritten
>>> as Contact: <sip:watcher@10.0.0.1>
>>> 
>>> 
>>> In M2,   Contact: <sip:pa@example.com> should be Contact:
>>> <sip:pa.example.com>
>>> 
>>> In M3,    NOTIFY sip:presentity@example.com SIP/2.0 Via:
>>> SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2 To:
>>> <sip:watcher@example.com>;tag=12341234 From:
>>> <sip:presentity@example.com>;tag=abcd1234 Call-ID:
>>> 12345678@10.0.0.1 CSeq: 1 NOTIFY ....
>>> 
>>> should be
>>> 
>>> NOTIFY sip:watcher@10.0.0.1 SIP/2.0 Via: SIP/2.0/UDP
>>> pa.example.com;branch=z9hG4bK8sdf2 To:
>>> <sip:watcher@example.com>;tag=12341234 From:
>>> <sip:presentity@example.com>;tag=abcd1234 Call-ID:
>>> 12345678@10.0.0.1 CSeq: 1 NOTIFY Contact: <sip:pa.example.com> 
>>> ....
>> 
>> All true. Also, since the Via contains a domain name, I will add a
>> "received" param to the Via in the response.
>> 
>> It's very good that you pointed out these mistakes in the examples.
>> I swear, I've looked at them a few times before, but I guess my
>> internal SIP parser is so well built that it never gave me an error
>> message. ;-)
>> 
>> I'll fix these for the next revision.
>> 
>> 
>>> [2] It could be helpful if the following example (2) is added in
>>>  the document as an addition to the only example (1) illustrated
>>>  in section 12.
>> 
>> I'm a little reluctant to adding this. There are excellent SIP call
>> flows already documented elsewhere (see RFC 3665, e.g., Section
>> 3.2), and to this particular method, adding a proxy in between the
>> PUA and the PA works no different from how this works for other
>> methods (MESSAGE, INVITE). I.e., the proxy rewriting the
>> Request-URI follows the same logic as the other methods would.
>> 
>> However, since this issue has come up before, it might be a good
>> idea to add a proxy between the PUA and PA. Any other views on
>> this?
>> 
>> 
>>> (1) PUA <---> PA <---> WATCHER
>>> 
>>> (2) PUA <---> proxy <---> PA
>>> 
>>> For example:
>>> 
>>> PUA <-----> proxy <------> PA |            |            | | M1
>>> PUBLISH |            | |----------->| M2 PUBLISH | |
>>> |----------->| |            | M3 200 OK  | | M4 200 OK
>>> |<-----------| |<-----------|            |
>>> 
>>> M1: PUBLISH sip:pa@example.com SIP/2.0 Via: SIP/2.0/UDP
>>> pua.example.com;branch=z9hG4bK652hsge From:
>>> <sip:presentity@example.com>;tag=1234wxyz To:
>>> <pres:presentity@example.com> Call-ID: 81818181@pua.example.com 
>>> CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence 
>>> Content-Type: application/pidf+xml Content-Length: ...
>> 
>> Note that the Request-URI needs to be 'sip:presentity@example.com'.
>> PUBLISH is specifically addressed to the resource, not the presence
>> agent.
>> 
>> 
>>> M2: PUBLISH sip:pa.example.com SIP/2.0 Via: SIP/2.0/UDP
>>> proxy.example.com;branch=z9hG4bKpx123 Via: SIP/2.0/UDP
>>> pua.example.com;branch=z9hG4bK652hsge From:
>>> <sip:presentity@example.com>;tag=1234wxyz To:
>>> <pres:presentity@example.com> Call-ID: 81818181@pua.example.com 
>>> CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence 
>>> Content-Type: application/pidf+xml Content-Length: ...
>> 
>> The proxy would rewrite the Request-URI, but probably to something
>> like 'sip:presentity@pa.example.com'. Note that when the request is
>> received by the PA/ESC, it specifically uses the Request-URI to
>> determine what resource the PUBLISH is targeted for. This is
>> identical to a SUBSCRIBE.
>> 
>> 
>>> M3: SIP/2.0 200 OK Via: SIP/2.0/UDP
>>> proxy.example.com;branch=z9hG4bKpx123 Via: SIP/2.0/UDP
>>> pua.example.com;branch=z9hG4bK652hsge From:
>>> <sip:presentity@example.com>;tag=1234wxyz To:
>>> <pres:presentity@example.com>;tag=1a2b3c4d Call-ID:
>>> 81818181@pua.example.com CSeq: 1 PUBLISH SIP-ETag: dx200xyz 
>>> Expires: 1800 Content-Length: 0
>>> 
>>> M4: SIP/2.0 200 OK Via: SIP/2.0/UDP
>>> pua.example.com;branch=z9hG4bK652hsge From:
>>> <sip:presentity@example.com>;tag=1234wxyz To:
>>> <pres:presentity@example.com>;tag=1a2b3c4d Call-ID:
>>> 81818181@pua.example.com CSeq: 1 PUBLISH SIP-ETag: dx200xyz 
>>> Expires: 1800 Content-Length: 0
>>> 
>>> [3] It could be better if the "Request-URI" is used as the
>>> message's target address and the 'Presence Resource' is specified
>>>  using "To" header.
>>> 
>>> It would be easy for understanding if REGISTER's location 
>>> registration operation like mechanism is considered.
>> 
>> This is actually how PUBLISH used to work. But having the
>> Request-URI point to a PA requires special handling from the
>> proxies and/or a specific naming convention for PAs to be able to
>> route the request. So we decided to reject the REGISTER-like
>> operation (determining the resource by the To-field) in favor of 
>> the SUBSCRIBE-like behavior the draft currently has.
>> 
>> 
>>> The same point could also be said about RFC3265. This is because,
>>> 
>>> 
>>> |3.1.5. Proxy SUBSCRIBE Behavior |  Proxies need no additional
>>> behavior beyond that described in SIP [1] |  to support
>>> SUBSCRIBE.
>>> 
>>> [4] For expressing 'Presence Resource', the 
>>> pres-URI(draft-ietf-impp-pres-04) would be better than that of
>>> the sip-URI.
>>> 
>>> Finally, when [3] & [4] are considered together, the various
>>> usages of URI can be expressed as listed below.
>>> 
>>> +------------+-----------------------------+----------------- 
>>> ------------+-----------------------------+ |            |
>>> PUBLISH                     | SUBSCRIBE | NOTIFY
>>> | +------------+-----------------------------+----------------- 
>>> ------------+-----------------------------+ |Request-URI | URI of
>>> PA                   | URI of PA | Contact-URI of SUBSCRIBE    | 
>>> |            | sip:pa@example.com          | sip:pa@example.com
>>> | sip:watcher.example.com     | 
>>> +------------+-----------------------------+----------------- 
>>> ------------+-----------------------------+ |To-URI      | URI of
>>> presence resource    | URI of presence resource    | From-URI of
>>> SUBSCRIBE       | |            | pres:presentity@example.com | 
>>> pres:presentity@example.com | sip:watcher@example.com     | 
>>> +------------+-----------------------------+----------------- 
>>> ------------+-----------------------------+ |From-URI    | URI of
>>> presentity           | URI of watcher | To-URI of SUBSCRIBE
>>> | |            | sip:presentity@example.com  | 
>>> sip:watcher@example.com     | pres:presentity@example.com | 
>>> +------------+-----------------------------+----------------- 
>>> ------------+-----------------------------+
>> 
>> Adding to my previous comments, how would the UA find out the
>> address of a PA that services the presentity? We can't mandate a
>> specific naming convention for PAs in general, which is why the
>> Request-URI is always the address of the subscribed/published
>> resource.
>> 
>> Note that one valid location for a PA is in the client device.
>> Because of the way PUBLISH and SUBSCRIBE currently work, this
>> requires nothing special from a proxy - it simply
>> forwards/redirects these requests to the UA like any other request
>> for that AoR.
>> 
>> Cheers, Aki
>> 
>> 
>>> Regards, shinji
>>> 
>>> Rohan Mahy wrote in
>>> <C3094B8F-4563-11D8-B291-0003938AF740@cisco.com>
>>> 
>>>> Hi,
>>>> 
>>>> I'd like to begin Working Group Last Call for PUBLISH:
>>>> 
>>>> 
>>> 
>>> http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-02.txt
>>> 
>>> 
>>>> This WGLC will end on January 28, 2004.
>>>> 
>>>> thanks, -rohan

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip