RE: [Sip] WGLC for PUBLISH

[[e-mail]]

Hi Shinji,

Thanks for the comments. Answers inline.

 > -----Original Message-----
 > From: ext OKUMURA Shinji [mailto:[e-mail]]
 > Sent: 15 January, 2004 12:49
 > To: Rohan Mahy
 > Cc: [e-mail]; 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:[e-mail]> should be 
 > rewritten as
 >              Contact: <sip:watcher@10.0.0.1>
 >
 > 
 >     In M2,   Contact: <sip:[e-mail]> should be
 >              Contact: <sip:pa.example.com>
 >
 >     In M3,    NOTIFY sip:[e-mail] SIP/2.0
 >               Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2
 >               To: <sip:[e-mail]>;tag=12341234
 >               From: <sip:[e-mail]>;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:[e-mail]>;tag=12341234
 >               From: <sip:[e-mail]>;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:[e-mail] SIP/2.0
 >             Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
 >             From: <sip:[e-mail]>;tag=1234wxyz
 >             To: <pres:[e-mail]>
 >             Call-ID: [e-mail]
 >             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:[e-mail]'. 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:[e-mail]>;tag=1234wxyz
 >             To: <pres:[e-mail]>
 >             Call-ID: [e-mail]
 >             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:[e-mail]'. 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:[e-mail]>;tag=1234wxyz
 >             To: <pres:[e-mail]>;tag=1a2b3c4d
 >             Call-ID: [e-mail]
 >             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:[e-mail]>;tag=1234wxyz
 >             To: <pres:[e-mail]>;tag=1a2b3c4d
 >             Call-ID: [e-mail]
 >             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:[e-mail]          | 
 > sip:[e-mail]          | sip:watcher.example.com     |
 > +------------+-----------------------------+-----------------
 > ------------+-----------------------------+
 > |To-URI      | URI of presence resource    | URI of presence 
 > resource    | From-URI of SUBSCRIBE       |
 > |            | pres:[e-mail] | 
 > pres:[e-mail] | sip:[e-mail]     |
 > +------------+-----------------------------+-----------------
 > ------------+-----------------------------+
 > |From-URI    | URI of presentity           | URI of watcher  
 >             | To-URI of SUBSCRIBE         |
 > |            | sip:[e-mail]  | 
 > sip:[e-mail]     | pres:[e-mail] |
 > +------------+-----------------------------+-----------------
 > ------------+-----------------------------+

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 <[e-mail]>
 > >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
 > _________________________________________________
 > OKUMURA Shinji        E-mail:[e-mail]
 > 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip