Presence and IntComm WG

["Jeff King" <>]

Hi Steve:

The current version of Session uses the Server Address field (under Edit >
Accounts > SIP) in the following ways:

1) To formulate address of record (AOR).  The "To:"  header field of a
REGISTER request is formed using this field.   The "To:" header field
contains the address of record (AOR) whose registration is to be created.
Session forms the  (AOR) by concatenating the Username field and the Server
address field with an "@".  For example: If the Username field contains
johndoe and the Server Address field contains companyabc.com, the To:
header of a SIP REGISTER request will contain 
sip:.
This is also true for the "From:"  field in a SIP REGISTER request.  Since
we are not performing any 3rd party registration function with Session, the
"To:" and "From:" fields are the same.

2) The REGISTER Request- URI is also formed using the Server Address field.
The Request-URI names the domain of the location for which the registration
is meant.  In the previous example, the Request-URI would be
sip:companyabc.com.

If an outbound proxy is not specified, the REGISTER requests will be
directed to this domain.  This is what precipitated by comments in the
earlier email.

As to your question regarding credentials:  When you first register with a
registrar that is configured to challenge for credentials, Session will
prompt you for credentials and also allow you to "remember this credential".
Next time you register, if you saved the credential information, Session
will not re-prompt you as it will be able to compute appropriate nonce
information.  Multiple credential entries can exist within Session and are
differentiated by realm.  Multiple saved credentials does not affect the
registration process provided your multiple saved credentials are associated
with different realms.  Attempting to save credentials of two different
"usernames" within the same realm would not work properly in this context as
each credential is differentiated by realm.  If you have other thoughts on
how you would like this to work, I would be happy to hear them.

Session supports multiple "SIP accounts".  In the Edit > Accounts > SIP
dialog, you can create multiple "SIP accounts" and hence multiple
registration entries (perhaps one to company abc and another at univxyz).
With this version of Session, when you place a call, the "From:" header will
be populated with information from the first SIP account in your list.  A
later version may have the ability to switch identities.

Let me know if this addresses your questions.  Perhaps we can perform some
testing on Friday.   How is your schedule?

Regards,
Jeff
 



On 9/24/03 4:33 AM, "Steve Blair" 
<>
 wrote:

> 
> Jeff:
> 
>  I don't think I phrased my question correctly. I realize that the call
> failed because isc.upenn.edu does not exist. I meant to use this as
> an example only. Sorry for the confusion.
> 
>  What I am wondering is how Session uses the value in the server
> name field in the general case.
> 
>   We also did some tests and Deke & I have another question.
> When configuring the proxy under the "calls" tab there is a
> credentials box. (I think the credentials box is here). We were wondering
> how Sessions uses the credentials data when registering and placing
> calls. Part two of this question is what happens /what impact does
> multiple, and possibly different, credentials entries have on the
> registration/call setup process?
> 
> Thanks,Steve
> 
> 
> Jeff King wrote:
> 
>> 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--