Hi Paul,
Thanks for the clarification. Just to strengthen my understanding,
kindly clarify, what happens in following case :
A PUA in "watcherhost.example.com" doesn't know the Presence Server
responsible for the presence of "bob" whose AOR is "[EMAIL PROTECTED]"
It sends a SUBSCRIBE request to it's own outgoibng "proxy.example.com".
Using the same DNS lookup (NAPTR/SRV/A) procedure described in my
original mail, following request arrives at "proxy.biloxi.com".
=== draft-ietf-simple-presence-07.txt/Sec. 8. Example message flow ===
SUBSCRIBE pxoxy.example.com -> proxy.biloxi.com server
SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnashds8..
Via: SIP/2.0/UDP watcherhost.example.com;branch=z9hG4bKnashds7
To: <sip:[EMAIL PROTECTED]>
From: <sip:[EMAIL PROTECTED]>;tag=xfg9
Call-ID: [EMAIL PROTECTED]
CSeq: 17766 SUBSCRIBE
Max-Forwards: 70
Event: presence
Accept: application/cpim-pidf+xml
Contact: <sip:[EMAIL PROTECTED]>
Expires: 600
Content-Length: 0
======================================================================
Now, the Request URI in SUBSCRIBE method has a user part - "bob".
The presence server for "biloxi.com" domain is say, "ps.biloxi.com". The
"proxy.biloxi.com" should forward the SUBSCRIBE request to "ps.biloxi.com". This can be done only if "proxy.biloxi.com" does abstract location
query based on SIP method - SUBSCRIBE.
Instead, if this request were - "INVITE sip:[EMAIL PROTECTED] SIP/2.0",
"proxy.biloxi.com" would have to look for the current contact address
for bob, and forward the request there.
Thus, it is imperative for proxy to take action based on SIP method
specified on request startline. Since RFC3261 leaves it to implementation,
I want to be sure if my understanding above is correct.
I appreciate your explanation,
= Kedar =
> -----Original Message-----
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, November 09, 2002 10:11 AM
> To: Kedar Patil
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Sip-implementors] To find the appropriate
> destination for
> a sip request
>
>
> Kedar,
>
> 3261 is pretty clear (in an abstract way) about how to handle
> everything but REGISTER. In those cases the request address
> would be sip:[EMAIL PROTECTED], and proxy.biloxy.com would
> typically use that (perhaps just "bob") to look up in a
> location service for next hop info. And it wouldn't typically
> matter what method it was.
>
> But REGISTER is different. The request URI is sip:biloxy.com
> - bob isn't the intended recipient of the request, the
> registrar who has no username part is. Another way of
> thinking of it is that the proxy itself (being responsible
> for biloxy.com) is the intended recipient. So the proxy could
> simply act as the registrar in this case. If it doesn't want
> to do that, but instead has knowledge of another server to
> use as a registrar, then it can simply use that knowledge to
> decide the next hop. That could be implemented by looking up
> some reserved name in the location service if you like.
>
> Whether it selects a different next hop depending on method
> is up to it. Normally there are few methods that are
> meaningful to send to sip:biloxy.com without a username part.
> OPTIONS is another one that comes to mind. Even if REGISTER
> is offloaded from the proxy it is likely that OPTIONS wouldn't be.
>
> This is all implementation detail - I can see no reason why
> it should be standardized.
>
> Paul
>
> > Kedar Patil wrote:
> >
> > Hi,
> >
> > How does a SIP proxy server decide to forward a REGISTER
> request to REGISTRAR and a SUBSCRIBE request to Presence Server?
> >
> > For clarification pls. consider following example (and let
> me know if I am interpreting
> > anything wrongly in this description) :
> >
> > A SIP UA is visiting "visited.com" domain. The
> "visited.com" admin has configured
> > this UA with "proxy.visited.com:5060" as the outgoing
> proxy. The UA wants to
> > register with the REGISTRAR its new contact. (pls. Ignore
> mobility issues here).
> >
> > The SIP UA sends following REGISTER request to
> "proxy.visited.com:5060",
> >
> > bobspc.visited.com - > proxy.visited.com
> >
> > REGISTER sip:biloxi.com SIP/2.0
> > Via: SIP/2.0/UDP
> bobspc.visited.com:5060;branch=z9hG4bKnashds7
> > Max-Forwards: 70
> > To: Bob <sip:[EMAIL PROTECTED]>
> > From: Bob <sip:[EMAIL PROTECTED]>;tag=456248
> > Call-ID: 843817637684230@998sdasdh09
> > CSeq: 1826 REGISTER
> > Contact: <sip:[EMAIL PROTECTED]>
> > Expires: 7200
> > Content-Length: 0
> > Now, as per RFC3263,
> >
> > 1) "proxy.visited.com" is not responsible for "biloxi.com" domain.
> > So it performs a NAPTR query for TARGET "biloxi.com",
> > It returns, say, one NAPTR SIP+D2U record "_sip._udp.biloxi.com".
> >
> > 2) Then "proxy.visited.com" performs an SRV query for
> "_sip._udp.biloxi.com",
> > it returns, say, one SRV record "proxy.biloxi.com" and port 5070.
> >
> > 3) Then "proxy.visited.com" performs an A record query for
> "proxy.biloxi.com",
> > it returns, say, a.b.c.d.
> >
> > So "proxy.visited.com" sends above request, (without any
> modifications), to
> > a.b.c.d at port 5070 using UDP.
> >
> > Now, "proxy.biloxi.com" receives the above request. It is
> responsible for
> > "biloxi.com" domain. The REGISTRAR for biloxi.com domain is say
> > "registrar.biloxi.com". "proxy.biloxi.com" must decide to
> send above request
> > to "registrar.biloxi.com".
> >
> > RFC3261, section 16.5 allows "proxy.biloxi.com", to use any abstract
> > location service to find the destination for the request.
> >
> > Q : Is it true that, in order to find the destination,
> "proxy.biloxi.com" is
> > required to look into SIP request, and see if it is
> REGISTER, then query
> > abstract location service for REGISTRAR, if it is
> SUBSCRIBE, then instead
> > query for PRESENCE SERVER. So destination is queried based
> on SIP method?
> > Is this what is expected?
> >
> > thanks in advance,
> > = Kedar =
> >
> >
> >
> >
> >
>
