Kedar,
The simple answer to this is that ps.biloxy.com should be one of the contacts in the
location service for [EMAIL PROTECTED] Then the proxy will fork requests (subscribe,
invite, whatever) directed to [EMAIL PROTECTED] Presumably the subscribe for presence
will succeed at ps.biloxy.com and not elsewhere.
Whether ps.biloxy.com is associated with bob.biloxy.com by explicit registration, or
by some sort of provisioning is an implementation decision.
The next question is whether you actually want to force every request to fork to the
places where it won't succeed. To improve on that you can utilize the callerprefs
extensions. The latest drafts provide explicit provision for conditioning the
selection of target based on both method and event package. So, with the proper form
of registration of ps.biloxy.com, the proxy will preferentially try it for presence
subscriptions, but will try some other contact first for INVITEs.
Paul
> Kedar Patil wrote:
>
> 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 ===
>
...
>
> 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.
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
