Presence and IntComm WG

[Jiri Kuthan <>]

At 10:04 AM 9/20/2003, Jeff King wrote:
>Hi Steve/Ben:
>
>The way the ser proxy/registrar/location service is currently configured
>seems a bit unconventional but Session is still able to register
>successfully (or on second thought maybe it's Session that's a bit
>unconventional ;>) )
>
>If I understand correctly,  ser.uits.indiana.edu is currently configured
>for the demonstration as follows (correct me if I'm wrong on any of
>these
>points):
>
>A participant with an email address of  
>
> will be
>assigned an address of record (AOR) on ser.uits.indiana.edu of
>sip:.

Hello Jeff,

Sorry for jumping in so late, I was too burdedned by VoN. Yes, that's
how it is.

>When attempting to register, the participant will be challenged for
>credentials with a realm string of "companyabc.com".
>
>My first question would be:   For this demonstration, should another UA
>outside the scope of the ser.uits.indiana.edu demonstration be able to
>place
>a call to our friend John Doe?    (e.g. John Doe's colleague back at
>companyabc who happens to be registered with his own registrar at
>companyabc.com as 
>)?
>   It seems to me that in
>order
>for this to happen, Jim will have to know to set his outbound proxy to
>ser.uits.indiana.edu otherwise his call to 
>sip:
>will query his local registrar at companyabc.com rather than the
>ser.uits.indiana.edu registrar.

I don't think that reachability through home domain has been ever asked
for and I agree it would be too tricky to set it up.


>Also as per RFC 3261: "Realm strings MUST be globally unique."  Using
>companyabc.com as a realm string on ser.uits.indiana.edu may not be
>globally unique as companyabc may use that string.

RFC is one thing, existing implementations other one. There are wide spread 
UAs
which require domain names used in SIP to relate to realm. Nevertheless,
I don't think it is too bad in this particular case: in this demo scenario,
we are desperados hijacking domain and we don't look at realm uniquiness too 
much.


>It seems the more conventional approach would be to assign an AOR of
>.
>
>Anyway, perhaps I'm getting a bit carried away here.  Now to the point
>of how to register Session with the current ser configuration.

[..]

>As you can tell from the above scenario, Session creates the AOR as
>defined in the To:  header of the REGISTER method by appending the
>server address field to the username field with an @.  In the previous
>example, the To: header of the REGISTER request would be populated with
>.
>  This addresses Ben's point of the Session
>equivalent of a "sign-in" name.
>
>I think one issue here with Session and with other UAs I have seen is
>that the Request URI of the REGISTER request should be able to name the
>domain of the location service for which the registration is meant (e.g.
>sip:ser.uits.indiana.edu) rather than naming the "right-hand side" of
>the "sign-in" name (e.g. sip:companyabc.com). 

I'm personally easy about request-URIs as long as we keep hijacking.
It's content of To header field which matters for processing REGISTERs.

> We will look at providing
>this function in a future release.  In the meantime, configuring the
>outbound proxy is one approach or using the proxy in the server address
>field is another approach, but in that case you cannot have an '"@" in
>the username field.

I thing the easiest way is use of outbound proxy server. Everything else
stays same and we don't run into any syntactical interop issues.

-jiri

ps -- I'm looking forward to try your UA -- I'm just traveling all these
days and can't give it a try right now. 

----------------------------------------------------------------wg-pic-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

----------------------------------------------------------------wg-pic--