Presence and IntComm WG

["Jeff King" <>]

Hi Steve:

sip:
 is your valid Session sip AOR within the scope of
the ser.uits.indiana.edu demo as it has been configured.  I suspect that
perhaps the reason your Cisco phone was unsuccessful in returning the call
was because it's outbound proxy was not set to ser.uits.indiana.edu and it
was trying to find blairs on the isc.upenn.edu registrar which does not
exist,  rather than on the ser.uits.indiana.edu registrar.   Is this the
case?

This was my point in the earlier email [WG-PIC:100] but as per Jeremy's
comment [WG-PIC:102], this is intended to be a closed demo for the most
part.  

Let me know if this works OK after setting the outbound proxy on the Cisco
phone.

Thanks,
Jeff


On 9/23/03 6:20 AM, "Steve Blair" 
<>
 wrote:

> 
> 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
>>> 
>>> 
>>> 
>>>    
>>> 
>> 
>> 
>> 
>> 
>>  
>> 

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

    http://archives.internet2.edu/

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