Subject: Re: [Simple] Presence & SRV - Problem solved?

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Nov 2002 16:47:54 -0500

I'm not sure this ever got answered. Response inline.

Ryan Chapman wrote:
 > Hello all,
 >
 > I'm writing a SIMPLE-based presence infrastructure, but I'm having
 > some difficulty determining exactly how to deal with a presence URI
 > (e.g., pres:[email-masked]).
 >
 > In the CPIM draft, we are told to query _im._sip.example.com for
 > im:[email-masked], and then that the "choice of IM transfer
 > protocol is a local configuration option for each system."

Right. Meaning, the somewhere.com domain decides which SRV entries to 
place into DNS - _im._sip.somewhere.com and _im._apex.somewhere.com. The 
sender gets to choose amongst those as it sees fit.

 > Given
 > this, which SRV RR should my SIP layer query?

If you are always trying to send using SIP, it would be 
_pres._sip.somwehere.com.

 >  If I translate my
 > presence URI to a SIP URI as specified (somewhere!) in the mailing
 > archive

Yes, this is something that needs to be described somewhere. I think it 
belongs in the cpim mapping draft.

 > by simply replacing "pres" with "sip", then what good was my
 > first SRV lookup?  In other words, my SIP layer would simply lookup
 > _sip._udp.example.com, ignoring whatever results my previous query
 > returned.

Well, thats an excellent question.

Clearly, one thing you get from the initial lookup is whether or not the 
terminating system even supports SIP. One approach is that you use the 
initial query just for that purpose, discard the resulting records, 
translate the SIP URI using some local mechanism (swap pres for sip in 
the scheme), and then use SIP mechanisms.

A second approach would have the translation done by the recipient 
domain. To some degree, one might argue that URI translation is 
something that only the server in the relevant domain can do. That is, 
pres:[email-masked] is a URI that only domain.com should ever try to 
translate. In that case, the appropriate approach is this:

1. client looks up _pres._sip.somewhere.com in DNS
2. client takes the resulting records, and sends the request there. The 
r-uri remains a pres URI.
3. the somewhere.com proxy server understands the pres URI, and applies 
some local policy to translate the URI.
4. Its all sip from there

The drawback to this second approach is that the proxy has to understand 
the pres URI. Arguably, it always will, if someone got a hold of a pres 
URI in that domain in the first place...

 > My primary goal is to have my presence server be decoupled from our
 > proxy/registrar, so the presence URI should send the message to a
 > different location than a normal SIP URI would.

Well, that you can always do. Generally a particular large domain will 
have a single proxy server that is the "front line" for requests. Its 
job is to route requests to the appropriate servers. For example, 
proxying a SUBSCRIBE request to a presence server.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple