Re: [Sip] WGLC for PUBLISH

[OKUMURA Shinji <[e-mail]>]

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:[e-mail]",
"sip:[e-mail]" 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:[e-mail];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

[e-mail] wrote in <[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

_______________________________________________
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