Presence and IntComm WG

[Steve Blair <>]

Jeff:

  Your instructions work. I was able to register Session to the
ser.uits.indiana.edu proxy this morning. I am curious about
setting the server address (step B.6).

  After I register Session I placed a call to 
,
this is a Cisco IP phone. The call completed but the Cisco
display shows the calling party as 
.
 This
is an invalid address. Return calls to this address will not
complete.

  In what ways does Session use the value in the server name
field?

Thanks,Steve

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:.
>
> 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.
>
> 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.
>
> 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.
>
> A. Set outbound proxy to ser.uits.indiana.edu
> 1) Go to the Preferences dialog window
> 2) Select the Calls tab
> 3) Set the proxy name to ser.uits.indiana.edu
> 4) Select Apply then OK
>
> B. Register
> 1) Go to the Edit > Accounts dialog window
> 2) Select the SIP tab
> 3) Select Add...
> 4) This will bring up the "Specify a SIP Registrar" dialog
> 5) Server name enter: PIC WG (or whatever other name you want to call
> it, this field is generic)
> 6) Server Address enter: companyabc.com (as per previous example)
> 7) Realm you should be able to leave this field blank
> 8) Username enter: johndoe (as per previous example)
> 9) Select OK
> 10) Session will now send a SIP REGISTER to ser.uits.indiana.edu
> 11) ser will send back a 401 Unauthorized
> 12) Session will display an "Authenticate Caller" Dialog
> 13) Username enter: johndoe
> 14) Password enter: <your assigned password>
> 15) If you want Session to remember this credential check the box,
> otherwise you will be prompted to re-enter credentials each time it
> refreshes registration.  Saved credentials can be deleted later if
> desired in the Preferences > Calls dialog.
> 16) Select OK
>
> You should now be configured and registered :>)
>
> 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).  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 guess my preferred approach for this demo would to be to define a
> username without an "@" (e.g. johndoe rather than
> ).
>   The complete SIP URI would then be
>
>  rather than the equivalent of
> @ser.uits.indiana.edu
>  which of course is not valid
> SIP URI syntax meaning I have to use an outbound proxy of
> ser.uits.indiana.edu.
>
> We can work with either approach.  Hope this helps.  Let me know if you
> have any questions or have any problems registering with the approach
> described above.  I plan to post directions to this group early next
> week on downloading the latest build of Session.
>
> Thanks,
>
> Jeff King
> Wave Three Software
>
>
> -----Original Message-----
> From: 
>
>  
> [mailto:]
>  On
> Behalf Of Steve Blair
> Sent: Friday, September 19, 2003 4:48 PM
> To: 
>
> Subject: [WG-PIC:99] Re: UAs
>
>
> Ben:
>
>  Sure.
>
> Jeff:
>
>   The first issue I see is that the '@' cannot be used in the username
> field in the account setup. This prevents us from trying combinations
> of characters in the username field. For example "blairs" is accepted
> by the text input box but 
> blairs@-any-thing-else-
>  is not.
>
>  I assume once the username field accepts the '@' the authentication
> process will work ok and we will be able to authenticate. I may be
> underestimating the programming work needed to make this change
> but it seems like an easy change.
>
>  I did not try embedded a code for the '@' in place of the actual
> '@' character. Perhaps something like blairs%40isc.upenn.edu will
> work? Just a thought to help narrow down the problem.
>
> -Steve
>
> Ben Teitelbaum wrote:
>
>  
>
> > > It seems that Session does not provide a "Sign-in" name as do the
> > > other UAs. It also
> > > does not seem to like an '@' in the username. Consequently having
> > > username formatted
> > > like the one we've proposed does not allow Session to sign in to the
> > >      
> proxy.
>  
>
> > >   
> > >
> > >      
> > Steve,
> >
> > Would you work with Jeff et al, to see if we can fix this in time?
> > I'd really like to see Session work with this demo.
> >
> > -- ben
> >
> >
> >
> >    
>
>
>
>
>  

--
 
ISC Network Engineering
The University of Pennsylvania
3401 Walnut Street, Suite 221A
Philadelphia, PA 19104  


voice: 215-573-8396 
fax: 215-898-9348    

sip:


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

   http://archives.internet2.edu/

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