Subject: RE: [Sipping] User Preferred Contact Address

From: "Aisling" <[email-masked]>
Date: Wed, 17 Aug 2005 09:32:51 +0100

Hi Paul,

I'm replying to an email that you sent me a few weeks ago responding to
my query regarding allowing users to set their preferred end device e.g.
Office phone, laptop etc, via a web interface. You suggested that I look
at sip.instance indentifiers (Thank you very much for that). I looked at
this along with the sip.description and sip.class feature tags. 

My worry was that I would have to extend a sip user agent for this as
one of the requirements put on my research is that all the intelligence
should be in the providers network, compatible with off-the-shelf sip
phones and with as little configuration by the user in the web interface
as possible.

However I have found out that SNOM phones support these feature tags.
However there seems to be no way to configure a snom phone (or any
other) for a variable sip.description tag. Therefore concentrating on
sip.instance tag....If I was to create a mapping on the server as you
suggested between this tag and a user friendly name - I am still
confused how the server would be able to know that a particular
sip.instance tag should be mapped to perhaps "office phone" when it
receives the register message...I mean would a user have to manually
enter the mapping first on the web interface?.....I thought that the
sip.description tag seemed the way to go but I don't think off-the-shelf
sip phones allow configuration of this.

I am very confused about this and I really appreciate your suggestions
so far. If you could give me any further advice on the above, that would
be great.

Many Thanks,
Aisling.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 19 July 2005 23:27
To: Aisling O'Driscoll
Cc: [email-masked]
Subject: Re: [Sipping] User Preferred Contact Address

Aisling,

Similar things have been discussed recently. (See 
draft-jennings-sipping-instance-id-01.txt) To identify particular 
endpoints uniquely, the +sip.instance feature tag has been proposed. It 
isn't especially user-friendly but it is unique.

You could define, somewhere, a mapping between sip.instance values and 
user-friendly names.

You could also define a different feature tag for the express purpose of

providing a friendly name for a contact, but then you run the risk of it

not being unique, and of requiring a way to provision the device with 
the value.

	Paul

Aisling O'Driscoll wrote:
> Hello all,
> 
> I am hoping to get opinions on the below:
> 
> I am considering research options in either extending CPL to support a
> REGISTER messages (some research has been done with CPL & SUBSCRIBE
> messages for presence) or perhaps adding a field to a SIP REGISTER
> message?...any other suggestions also welcome.
> 
> The reason I am considering the above is because I would like a user
> to be able to choose their preferred SIP end device to have a call
> delivered to e.g. office hard phone or pda softphone, laptop
> softphone etc. This user would have registered many times
> from the various end user devices with the same url and would
> therefore have multiple contact addresses. I cannot think how I can
> associate a particular contact address with "office phone" or
> "laptop" etc. 
> 
> However if I could extend CPL script syntax for this or perhaps add
> an extra field in a sip register message indicating the place the
> contact address is associated with, could this could work?
> 
> I cannot think of other methods of implementing this scenario. The
> problem with extending a SIP REGISTER message is that it would
> require every user to have a dedicated client. Anything I could do
> purely on the service provider side?
> 
> Many thanks for your ideas and guidance,
> BR,
> Aisling O' Driscoll.
> 
> 
> 
> -------------------Legal
Disclaimer---------------------------------------
> 
> The above electronic mail transmission is confidential and intended
only for the person to whom it is addressed. Its contents may be
protected by legal and/or professional privilege. Should it be received
by you in error please contact the sender at the above quoted email
address. Any unauthorised form of reproduction of this message is
strictly prohibited. The Institute does not guarantee the security of
any information electronically transmitted and is not liable if the
information contained in this communication is not a proper and complete
record of the message as transmitted by the sender nor for any delay in
its receipt.
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

-------------------Legal
Disclaimer---------------------------------------

The above electronic mail transmission is confidential and intended only
for the person to whom it is addressed. Its contents may be protected by
legal and/or professional privilege. Should it be received by you in
error please contact the sender at the above quoted email address. Any
unauthorised form of reproduction of this message is strictly
prohibited. The Institute does not guarantee the security of any
information electronically transmitted and is not liable if the
information contained in this communication is not a proper and complete
record of the message as transmitted by the sender nor for any delay in
its receipt.

-------------------Legal  Disclaimer---------------------------------------

The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Aug 2005 18:19:45 -0400

Aisling wrote:
> enter the mapping first on the web interface?.....

Yes, probably. You might be able to do something clever, like notice 
that there is a new value of sip.instance and send an OPTIONS to poll 
it. Use something from the OPTIONS as the friendly name if you can find 
something. But you probably aren't going to find anything like "Office 
Phone" there.

If you want names like "office phone" then you are going to require some 
degree of manual configuration, either on the phone or in the network. 
The trouble with manually configuring the association with the 
sip.instance is that the user won't be able to recognize the 
sip.instance as anything he knows.

Perhaps combo of above would work: a web interface to config would 
recognize contacts that a sip.instance with no corresponding name 
configured. Would offer to let the user config these, and would present 
what info it could get via OPTIONS as identifying info so the user can 
realize which device it is. You could also provide some option like 
"ring this" to verify which device it is.

I thought that the
> sip phones allow configuration of this.

Seems like only real advantage of configuring on the device vs 
configuring on the web is that you at least know which device you are 
configuring. Otherwise, configuring on web will probably provide better UI.

> so far. If you could give me any further advice on the above, that would

Maybe above thoughts are of some help.

	Paul

---

From: "Banibrata Dutta" <[email-masked]>
Date: Fri, 19 Aug 2005 12:06:34 +0530

While I might be going off on a tangent, but doesn't XCAP support something
like this by allowing a network based support for doing what is being tried
to be done here ?

- bd 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Friday, August 19, 2005 3:50 AM
To: Aisling
Cc: [email-masked]
Subject: Re: [Sipping] User Preferred Contact Address

Aisling wrote:
> Hi Paul,
> 
> I'm replying to an email that you sent me a few weeks ago responding 
> to my query regarding allowing users to set their preferred end device
e.g.
> Office phone, laptop etc, via a web interface. You suggested that I 
> look at sip.instance indentifiers (Thank you very much for that). I 
> looked at this along with the sip.description and sip.class feature tags.
> 
> one of the requirements put on my research is that all the 
> intelligence should be in the providers network, compatible with 
> off-the-shelf sip phones and with as little configuration by the user 
> in the web interface as possible.
> 

Yes, probably. You might be able to do something clever, like notice that
there is a new value of sip.instance and send an OPTIONS to poll it. Use
something from the OPTIONS as the friendly name if you can find something.
But you probably aren't going to find anything like "Office Phone" there.

If you want names like "office phone" then you are going to require some
degree of manual configuration, either on the phone or in the network. 
The trouble with manually configuring the association with the sip.instance
is that the user won't be able to recognize the sip.instance as anything he
knows.

Perhaps combo of above would work: a web interface to config would recognize
contacts that a sip.instance with no corresponding name configured. Would
offer to let the user config these, and would present what info it could get
via OPTIONS as identifying info so the user can realize which device it is.
You could also provide some option like "ring this" to verify which device
it is.

I thought that the
> sip.description tag seemed the way to go but I don't think 
> off-the-shelf sip phones allow configuration of this.

Seems like only real advantage of configuring on the device vs configuring
on the web is that you at least know which device you are configuring.
Otherwise, configuring on web will probably provide better UI.

> so far. If you could give me any further advice on the above, that 
> would be great.

	Paul

> endpoints uniquely, the +sip.instance feature tag has been proposed. 
> It isn't especially user-friendly but it is unique.
> 
>>delivered to e.g. office hard phone or pda softphone, laptop softphone 
>>etc. This user would have registered many times from the various end 
>>user devices with the same url and would therefore have multiple 
>>contact addresses. I cannot think how I can associate a particular 
>>contact address with "office phone" or "laptop" etc.
>>
>>However if I could extend CPL script syntax for this or perhaps add an 
>>extra field in a sip register message indicating the place the contact 
>>address is associated with, could this could work?
>>
>>problem with extending a SIP REGISTER message is that it would require 
>>every user to have a dedicated client. Anything I could do purely on 
>>the service provider side?
>>
>>Many thanks for your ideas and guidance, BR, Aisling O' Driscoll.
>>
>>
>>
>>-------------------Legal
> 
> protected by legal and/or professional privilege. Should it be 
> received by you in error please contact the sender at the above quoted 
> email address. Any unauthorised form of reproduction of this message 
> is strictly prohibited. The Institute does not guarantee the security 
> of any information electronically transmitted and is not liable if the 
> information contained in this communication is not a proper and 
> complete record of the message as transmitted by the sender nor for 
> any delay in its receipt.
> 
>>
>>This list is for NEW development of the application of SIP Use 
>>[email-masked] for questions on current sip Use 
>>[email-masked] for new developments of core SIP
>>
> 
> 
> -------------------Legal
> protected by legal and/or professional privilege. Should it be 
> received by you in error please contact the sender at the above quoted 
> email address. Any unauthorised form of reproduction of this message 
> is strictly prohibited. The Institute does not guarantee the security 
> of any information electronically transmitted and is not liable if the 
> information contained in this communication is not a proper and 
> complete record of the message as transmitted by the sender nor for 
> any delay in its receipt.
> 
> 
> -------------------Legal  
for the person to whom it is addressed. Its contents may be protected by
legal and/or professional privilege. Should it be received by you in error
please contact the sender at the above quoted email address. Any
unauthorised form of reproduction of this message is strictly prohibited.
The Institute does not guarantee the security of any information
electronically transmitted and is not liable if the information contained in
this communication is not a proper and complete record of the message as
transmitted by the sender nor for any delay in its receipt.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP