RE: [Sipping] User Preferred Contact Address
"Aisling" <ashling.odriscoll@cit.ie> Wed, 17 August 2005 08:34 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5JNW-00029p-Cp; Wed, 17 Aug 2005 04:34:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5JNU-00029k-Fn for sipping@megatron.ietf.org; Wed, 17 Aug 2005 04:34:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15265 for <sipping@ietf.org>; Wed, 17 Aug 2005 04:34:26 -0400 (EDT)
Received: from [157.190.14.18] (helo=mail.cit.ie) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Jwy-0007sy-UL for sipping@ietf.org; Wed, 17 Aug 2005 05:11:10 -0400
Received: from eepf35070200 (unverified [157.190.74.153]) by cit.ie (Rockliffe SMTPRA 5.3.7) with ESMTP id <B0004251898@mail.cit.ie>; Wed, 17 Aug 2005 09:29:39 +0100
From: Aisling <ashling.odriscoll@cit.ie>
To: 'Paul Kyzivat' <pkyzivat@cisco.com>
Subject: RE: [Sipping] User Preferred Contact Address
Date: Wed, 17 Aug 2005 09:32:51 +0100
Message-ID: <000001c5a306$41b242e0$994abe9d@eepf35070200>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <42DD7E44.2090306@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c
Content-Transfer-Encoding: 7bit
Cc: sipping@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org
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:pkyzivat@cisco.com] Sent: 19 July 2005 23:27 To: Aisling O'Driscoll Cc: sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP
- [Sipping] User Preferred Contact Address Aisling O'Driscoll
- Re: [Sipping] User Preferred Contact Address Paul Kyzivat
- RE: [Sipping] User Preferred Contact Address Dale Worley
- RE: [Sipping] User Preferred Contact Address Aisling
- RE: [Sipping] User Preferred Contact Address Dale Worley
- RE: [Sipping] User Preferred Contact Address Aisling
- Re: [Sipping] User Preferred Contact Address Paul Kyzivat
- RE: [Sipping] User Preferred Contact Address Banibrata Dutta