Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid

From: Andrew Allen <[email-masked]>
Date: Sat, 3 Sep 2011 16:33:52 +0000

Cullen

Apologies for the delay in responding. With some vacation time, a 3GPP meeting to prepare for and attend and being sick for the past week this is the first chance I have had to respond.

Responses included below:

Andrew

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Tuesday, July 26, 2011 5:23 PM
> To: Andrew Allen
> Cc: DISPATCH list
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-
> dispatch-imei-urn-as-instanceid
> 
> 
> On May 27, 2011, at 23:07 , Andrew Allen wrote:
> 
> > Cullen
> >
> > Responses to your technical points below:
> >
> > regards
> > Andrew
> >
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Cullen Jennings
> >> Sent: Wednesday, May 18, 2011 1:11 PM
> >> To: DISPATCH list
> >> Subject: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-
> >> dispatch-imei-urn-as-instanceid
> >>
> >>
> >> I have said in the past, I have several concerns around the combined
> >> proposal in these two drafts. In this email, I've tried to focus on
> > the
> >> high level problems and ignore small problems in the drafts that can
> > be
> >> fixed by change a bit of text in the drat.
> >>
> >> The biggest issues is that this is going to reduce interoperability
> > with
> >> systems that don't use this type of instance id yet this does not
> > provide
> >> features that could not be done in away that did not reduce
> >> interoperability.
> >
> > Can you please elaborate on what your interoperability concerns are? I
> > don't see any issue with end to end interoperability since with public
> > GRUU the gr parameter is opaque. Devices that contain an IMEI are only
> > those devices specified by 3GPP. Only 3GPP mandates that the IMEI is
> > included in the instance ID, non 3GPP devices or devices not operating
> > in an IMS network do not need to use an IMEI (indeed a non 3PP device
> > would not even have an IMEI to use). RFC 5626 allows the possibility for
> > URNs other than UUID to be used as an instance ID and RFC 5627 does not
> > mandate an algorithm for the generation of GRUUs based on the instance
> > ID. If the 3GPP determines that its devices that already contain an IMEI
> > for their device ID need to use that as an Instance ID and defines a
> > GRUU generation algorithm that satisfies its requirements when receiving
> > an Instance ID that contains the IMEI URN then that seems fine to me. Is
> > your concern regarding a 3GPP IMS terminal registering in a non IMS
> > domain? I think that in reality a device acting as an IMS terminal
> > registering in a non IMS compliant network isn't a practical scenario.
> > There are so many 3GPP and IMS compliant things that would need to
> > happen in the network for the device (acting as an IMS terminal) to
> > register and obtain service that basically the network would need to be
> > an IMS compliant network. Of course there is nothing preventing a device
> > that is IMS capable being configured to either act as an IMS compliant
> > device or a basic SIP compliant device (quite a few devices have such
> > dual mode capabilities). The use of the IMEI as the instance ID should
> > not in itself prevent the successful registration of the device in a non
> > IMS network (since as Dale points out the registrar is likely to treat
> > the instance ID opaquely if it doesn't understand it).
> 
> What happens in 3GPP tends to leak out into other standard and into other
> systems.

[AA] I don't see how this can happen as only GSM/3GPP devices can have an IMEI (GSMA allocates the IMEI namespace). Devices that are not compliant with the 3GPP specifications and are not part of a 3GPP system will not have an IMEI so I don't see how it is possible for the IMEI URN to "leak out" into other standards.
> 
> >
> >> To be concrete, let me offer an alternative solution
> >> that would be interoperable, would not have any IPR that I am aware
> > of,
> >> and would provide the same functionality as the goals of these drafts
> > - or
> >> at least the goals that have been stated at the IETF.
> >>
> >> To indicate the version of the software, I would suggest using the SIP
> >> User Agent header. If a more structured form is required to
> > specifically
> >> line up with existing mobile systems, I would suggest defining an well
> >> structured format to use inside the User Agent header field. The
> > advantage
> >> is that this is what most sip systems do today and many management
> > systems
> >> already can look at this header and use it. A more structured form
> > would
> >> be useful by systems outside the GSMA space and would also be
> > backwards
> >> compatible with existing systems that treat it as an unstructured
> > string.
> >
> > I am not against the proposal of including the software version in the
> > User Agent header but don't see it as an alternative to the
> > representation of the IMEI-SV as part of the IMEI URN. One of the main
> > objectives of the use of the IMEI and IMEI-SV in SIP signaling is to
> > maintain compatibility with the IMEI and IMEI-SV use in Circuit Switched
> > signaling. In some case in circuit switched signaling the device will
> > return the IMEI and in other cases the device will return the IMEI-SV.
> > It needs to be possible that devices registered in circuit switched
> > domain and in the IMS domain can use whichever is returned IMEI or
> > IMEI-SV in the same identifier.
> 
> I understand both are used in circuit switched but I don't see that that
> would require a design like this.
> 
[AA] We are just trying to define a namespace to represent the IMEI and IMEI-SV as already defined by GSMA. The latest version of draft-allen-dispatch-imei-urn-as-instanceid states: "The UAC SHOULD NOT include the optional "svn" parameter in the GSMA IMEI URN in the "sip.instance" media feature tag, since the software version can change as a result of upgrades to the device firmware which would create a new instance ID.". 3GPP do not use the IMEI-SVN as an instance ID in their specifications.

> >>
> >> For the issue of identifying stolen handsets and correlating devices
> >> between SIP and non SIP calls, I would propose that you use a UUID as
> > the
> >> URN but that the UUID be created using IMEI or a hash of the IMEI
> > instead
> >> of the MAC. This would involve an extension to RFC 4122 but would
> > result
> >> in a system that meets the needs. Even if a hash is used, the server
> > side
> >> can do the same hash to match.
> >
> > I don't fully understand the details of your proposal but a clear
> > requirement is that the IMEI in the instance ID be recoverable and
> > understandable by the registrar as the IMEI value of the terminal. Does
> > this proposal allow the IMEI value to be obtained and understood by the
> > registrar?
> 
> The requirement was that they be matchable not recoverable which this
> meets

[AA] The requirement is that the IMEI be identifiable so that registration of barred devices (e.g stolen devices) can be prevented and also so that for emergency calls the device used can be identified.

> 
> 
> >
> > If an extension to RFC 4122 is required isn't this more overhead and has
> > more impact than simply defining and using a URN that represents the
> > namespace that you wish to include? UUID itself is also heavier in
> > computational resources and less efficient in size than the IMEI URN.
> 
> This extension to 4122 is pretty easy and has no IPR I am aware of.
> 
[AA] As above it seems this solution doesn't meet the above requirement that the IMEI be recoverable.
> >
> >>
> >> If the WG is interest in such an idea, I am glad to write up an ID for
> >> each of these and submit it to the group so that it can be properly
> >> considered in contrast to draft-allen-dispatch-imei-urn-as-instanceid.
> >>
> >> As the draft-allen-dispatch-imei-urn-as-instanceid stands today, I am
> > not
> >> in favor of publishing it as is because  I believe it will result in
> >> interoperability failures with the many SIP devices that don't support
> > it,
> >
> > This needs justification. 3GPP specifications also support handling
> > devices that use UUID and not IMEI as many IMS compatible devices do not
> > actually have an IMEI (only GSM mobile devices have an IMEI).
> 
> I think I have provided this on more than one occasion.
> 
[AA] As I understand from a very brief discussion with you on this in Quebec City your concern is that GSM mobile devices may try and register using the IMEI as an Instance ID on non IMS networks. I don't think this is a practical scenario. There are so many IMS specific things that 3GPP devices that contain IMEIs do and expect the network to do that a device acting as a compliant 3GPP IMS device would not successfully register with a non 3GPP IMS compliant network. Firstly 3GPP IMS mobile devices that contain an IMEI either obtain or derive their registered public user identity (which becomes the address of record), the domain name to register in and their security parameters for authentication from the SIM card or UICC. Only GSM network operators supply SIM cards and UICCs that contain other GSMA allocated identities such as mobile country code (MCC) and mobile network code (MNC) so a 3GPP IMS device (with an IMEI) cannot register (according to IMS procedures) with any network that is not a network operated by a GSM operator. Additionally lower layer security mechanisms upon which SIP signaling relies are also dependent on the SIM card or UICC based security mechanisms so a 3GPP IMS device (with an IMEI) could not even establish the necessary security contexts. Also the 3GPP IMS device depends on the support and usage of certain mechanisms such as Service-Route header field, P-Associated-URI header field and use of security agreement (Security-Client, Security-Server and Security-Verify header fields in an IMS specific manner. Without these IMS specific procedures being followed the 3GPP IMS device (with an IMEI) would not be able to successfully register and establish sessions. Therefore I don't see how this is a real issue. This concern could be addressed in draft-allen-dispatch-imei-urn-as-instanceid by adding a statement that an IMEI is MUST only be used as an Instance ID by a device registering with a 3GPP IMS network.

> >
> >> and it has IPR that we can easily avoid and provide the same
> >> functionality. I also have issues with some of the technical details
> > in it
> >> but theses could all be fairly easily resolved with a few back and
> > forth
> >> of suggested text. RIM is offering awful licensing terms for something
> >> that I believe you would have to implement to be workable in the bulk
> >> mobile SIP deployments. Give this is easily avoidable, I think we
> > should
> >> avoid it. It's not really a topic for this WG but if this draft
> > proceeded,
> >> it was very late IPR disclosure. When it came to IETF LC, I would also
> >> want to point out that the only teeth IETF has to enforce very late
> > IPR
> >> disclosures is to say no. I'm not particularly interested in talking
> > about
> >> this here as I don't think it will help solve the proble
> >> m but I have brought this up in the past in context of this draft and
> > I
> >> don't want anyone to be surprised if I brought it up in an IETF LC.
> >>
> >> There are also significant privacy concerns around this proposal. A
> > key
> >> design of GRUU is being able to meet people goals of privacy while not
> >> revealing private information.
> >
> > Privacy in GRUU is achieved through temporary GRUUs. Properties of
> > temporary GRUUs are unaffected by using the IMEI as an instance ID.
> >
> >> The IMEI is sometimes used as a security
> >> identifier between a user and SP as a shared secret. This proposal
> > would
> >> break theses systems.
> >
> > The IMEI is easily readable from the UI of mobile phones and is quite
> > often printed on the case under the battery. Mobile phone stores
> > sometimes keep lists (sometimes on paper) of IMEIs and the customers who
> > have been allocated them (warranty reasons etc).
> 
> agree with what you are saying but you do agree it is used as a secret
> often used to show proof of possession of the phone?

[AA] This is handled with the design and usage of the IMEI. The IMEI has a spare digit. This digit has a spare digit. This digit is always set to zero when transmitted but one the mobile device has a non zero value. Thus intercepting the transmitted IMEI value does not provide you the entire IMEI.

> 
> > It is hardly a super
> > secret security identifier. I am not aware of the security usage you
> > describe and if it does exist it seems pretty flawed.
> >
> >> The privacy and security aspects of this would need to be addressed.
> >
> > 3GPP has addressed aspects of revealing the IMEI when generating GRUUs
> > in their specifications.
> 
> right, send them on over

[AA] Here is the link:
http://www.3gpp.org/ftp/Specs/latest/Rel-8/24_series/24229-8g0.zip

> 
> >
> >> It's conceivable that in many cases IMEI is Personal
> >> Identifiable Information.
> >
> > IMEI is not really anymore personal information than IP address
> 
> <..snip..>
> 
> I'll note I think you are just wrong on this. First of all, IMEI are more
> revealing than IP because they tend to be tighter bound to a single suer
> instead of multiple and exist over longer time and second of all many
> people, myself included, consider IP as PII in many cases.
>

[AA] Whether one is worse than the other is debatable but as indicated above there isn't a issue with revealing this information since 3GPP specifications address this issue and having 3GPP IMS devices with IMEIs register on non IMS networks isn't a practical scenario.
 
> 
> >
> >> The idea that every call would have to have PII
> >> information in it or my call would be blocked as coming form a stolen
> >> phone seems like a pretty serious flaw in this proposal.
> >
> > In general the IMEI is not placed in an IMS call. The blocking would be
> > achieved via the registration. Blocked mobiles simply would be unable to
> > register in IMS (which in IMS means they are unable to make calls). If
> > an IMEI check is needed during a call the mobile can be requested by the
> > network to re-register. The only use in 3GPP of the IMEI during an IMS
> > call is for emergency calls.
> 
> again, I think there are much better designs for this without IPR issues

[AA] I don't think there has been such a proposal and in any case this was the proposal that was agreed in 3GPP. This proposal is informational not standards track and is 3GPP informing the internet community of its usage. This is applicable for 3GPP IMS deployments only so what is the basis for these concerns?

> 
> >
> >> I'll note I brought up the privacy issues in 2007 and have yet to get
> > a reply on it.
> 
> 
> >
> > I don't recall your previous comment (but it was 4 years ago). If we
> > have failed to respond adequately to a previous comment then please
> > restate it if the above responses do not cover it.
> >>
> >> On the topic of draft-montemurro-gsma-imei-urn, I of course think it
> > is
> >> fine for the GSMA to be able to allocate a namespace where they need
> > it.
> >> However, there are bunch of changes that would be needed to make this
> >> draft fit all the URN rules. They are all small actionable things like
> >> defining how comparison of things such as svn is defined and how
> >> allocation of new things works.
> >
> > Of course all technical issues and concerns can be fixed. Please supply
> > details on those so they can be addressed.
> >
> >> As I have also brought up many times in
> >> the past, what the relationship between GSMA and 3GPP on this is very
> >> weird and I would want clarity on that before proceeding. In the time
> > we
> >> have been discussing this draft, people constantly tell me that GSMA
> > is
> >> the group that will handle the namespace allocation for the 3GPP
> >> deployments yet at the same time we have approved RFC 5279 which oddly
> >> looks like a better namespace for this than the GSMA one. I would want
> > to
> >> have a clear understanding of how these different spaces interact. The
> >> more we splinter this namespace, the less interoperability we have.
> >
> > My understanding is that in order to be allocated a URN namespace the
> > registrant of the namespace has to guarantee uniqueness of the
> > namespace. GSMA provides for the allocation of IMEIs and ensures
> > adherence to the guidelines for IMEI allocation "GSMA Association, "IMEI
> > Allocation and Approval Guidelines", PRD DG.06". Thus for the IMEI the
> > GSMA is the appropriate registrant for that namespace. 3GPP has no
> > responsibility for allocation of IMEIs so should not be the responsible
> > registrant. 3GPP namespace would seem appropriate for items which are
> > completely specified (including all their values) in 3GPP
> > specifications. It should be noted that 3GPP is not a legal entity and
> > might not exist for the entire period of time that IMEIs are being
> > allocated and used.
> >>
> >> On the topic of including the software version as part of the device
> >> identifier, given the software is upgraded, I think this is a mistake
> > and
> >> it is better to consider the software version as a separate thing from
> > the
> >> unique device identifier. It does not seem consistent with the goals
> > and
> >> requirements of a device id URN.
> >
> > As stated above the software version is included for backward
> > compatibility with the IMEI-SV usage in circuit switched signaling. The
> > SVN is a parameter and so the original IMEI which does not change can be
> > easily obtained. Registrars and other devices that understand the IMEI
> > URN with the SVN parameter can ignore the parameter when generating
> > GRUUs for instance. If a book has a 2nd edition with different content
> > doesn't that warrant being assigned a new value within the ISBN URN
> > namespace? Similarly if the software is upgraded the nature and
> > capabilities of the device may change so doesn't this warrant a new
> > value? Note that RFC 5626 and RFC 5627 do not require that the instance
> > IDs or GRUUs be forever persistent (RFC 5626 only requires that it MUST
> > be persistent through a power cycle). I doubt very much that most
> > embedded SIP endpoints will after a complete software upgrade (such as
> > involving completely rewriting flash memory) still use the same UUID as
> > previously used either.
> >>
> >> I will also note that as far as process is concerned, I would prefer
> > the
> >> problem, not the solution was brought to dispatch and we could figure
> > out
> >> how to solve it. I do think the problem here is well worth solving, I
> > just
> >> think there are solutions that will work better that this when
> > considering
> >> the whole eco systems of SIP endpoints and not just the GSM ones.
> >
> > When this was first proposed in 2006 all that was being done was
> > registering a namespace.
> 
> I doubt that is true. Please look at the drafts from 2006. I have never
> objected to the idea that some other SDO might want a URN namespace. If
> that was all that was requested, this would have been done long ago and
> the current draft would not be requesting anything more than that.
> 
[AA] There is nothing in the early versions (around 2006) about using the IMEI URN as an instance ID although this was added in later versions but then removed and then specified separately in draft-allen-dispatch-imei-urn-as-instanceid

> > I don't think that 3GPP needs to bring
> > requirements to the dispatch WG, propose a charter etc for every problem
> > that can be solved by registering a namespace or a parameter. In fact
> > the SIP change process has moved away from that with only specification
> > required and expert review needed for defining "proprietary" SIP header
> > fields. As stated above the IMEI only applies to the GSM family of
> > technology mobiles not all SIP endpoints and I fail to see the impact of
> > the use of the IMEI URN by the GSM family of technology mobiles when
> > registering with IMS on any other SIP endpoints. This proposal does not
> > mandate the use of the IMEI URN as an Instance ID by non 3GPP terminals
> > and is not being proposed to become part of an IETF standard. This is
> > just trying to follow the process whereby external users of IETF
> > protocols register their identifiers with IANA and provide informational
> > documentation to the internet community about such usage. It seems to me
> > that some of the issues of principle being raised are those
> > considerations that more appropriately apply to standards track
> > submissions and not to these informational submissions.
> 
> > If the same
> > level of consideration and debate about different solutions takes place
> > for informational submissions as would take place for standards track
> > submissions then I fear this will become a big deterrent to outside
> > users of IETF protocol submitting their proprietary usages as
> > informational RFCs for the benefit of the internet community and in
> > ensuring that are no conflicts with the IANA registry.
> 
> 
> You are asking for something that can not be approved as an information
> draft by the ISE because it impacts interoperability of SIP devices. The
> bar here is somewhat higher than some information drafts. If what you
> needed to be approved could be done by the ISE, I would suggest you take
> it there but it can't.
> 
[AA] As above I do not agree that there are any interoperability concerns with this proposal and this is only proposed for 3GPP IMS usage of SIP not for general internet usage.
> 
> >>
> >> Cullen in my individual contributor role
> >>
> >>
> >> _______________________________________________
> >> dispatch mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/dispatch
> >
> > ---------------------------------------------------------------------
> > This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be
> unlawful.
> 
> 
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 6 Sep 2011 15:15:37 -0400

I hope I'm not the only person who feels that this "debate" is a tempest
in a teapot.

I can't see any serious reason not to define a URN namespace for
IMEIs.  These names have various deficiencies from various points
of view, but none that are substantially worse than the currently popular
system of constructing URNs from UUIDs which are constructed from
MAC addresses (which are printed on a label on the back of the phone).

There can only be interoperability problems if a proxy is unable to accept
instance-ids that are in namespaces that it does not understand.  But
such a proxy is clearly deficient, and indeed, one would have to go out
of one's way to build a proxy that had this deficiency, since the simplest
and most natural implementation is to treat the instance-id as an opaque
string.

There may be IPR attached to this, but as the only vendors who would
care about using it are manufacturers who have licensed the entire 3GPP
IPR bundle, that causes nobody any problems that they do not already have.

I regard to privacy, any user of a 3GPP phone has submitted to having
their privacy protected and violated to exactly the degree designed into 3GPP,
and the transmission of an IMEI-based instance-id between the 3GPP phone
through a 3GPP network to a 3GPP registrar is not going to decrease (or
increase) their privacy.

Can we just approve this and stop spending time on it?

Dale

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 14 Sep 2011 21:12:22 +0000

AT&T supports this draft moving forward :) 

-----Original Message-----
From: Worley, Dale R (Dale) [mailto:[email-masked]] 
Sent: Tuesday, September 06, 2011 3:16 PM
To: Andrew Allen; Cullen Jennings
Cc: DISPATCH list
Subject: RE: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid

Dale

---

From: Itsuma TANAKA <[email-masked]>
Date: Thu, 15 Sep 2011 08:50:43 +0900

Dear All,  

Just to echo what other supporters of this draft say - NTT DOCOMO also
supports this draft moving forward.

Thank you,
Itsuma Tanaka
NTT DOCOMO

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of DOLLY, MARTIN C
Sent: Thursday, September 15, 2011 6:12 AM
To: Worley, Dale R (Dale); Andrew Allen; Cullen Jennings
Cc: DISPATCH list
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn
anddraft-allen-dispatch-imei-urn-as-instanceid

-----Original Message-----
From: Worley, Dale R (Dale) [mailto:[email-masked]] 
Sent: Tuesday, September 06, 2011 3:16 PM
To: Andrew Allen; Cullen Jennings
Cc: DISPATCH list
Subject: RE: [dispatch] draft-montemurro-gsma-imei-urn
anddraft-allen-dispatch-imei-urn-as-instanceid

I regard to privacy, any user of a 3GPP phone has submitted to having
their privacy protected and violated to exactly the degree designed into
3GPP,
and the transmission of an IMEI-based instance-id between the 3GPP phone
through a 3GPP network to a 3GPP registrar is not going to decrease (or
increase) their privacy.

Dale

---

From: Shida Schubert <[email-masked]>
Date: Thu, 15 Sep 2011 09:00:47 +0900

We support the draft as well. 

 Regards
  Shida

---

From: Lili Yang_lili <[email-masked]>
Date: Thu, 15 Sep 2011 01:10:52 +0000

Hello,

+1 support. 

Best regards,
Lili 
华为技术有限公司 Huawei Technologies Co., Ltd.

Phone: +86-755-28422553
Fax: +86-755-28420413
Mobile:+86-13632632065
Email: [email-masked]
地址：深圳市龙岗区坂田华为基地 邮编：518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com 

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shida Schubert
Sent: Thursday, September 15, 2011 8:01 AM
To: DISPATCH list
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid

 Regards
  Shida

---

From: Ricky Kaura <[email-masked]>
Date: Thu, 15 Sep 2011 03:28:18 +0100

Hello,

I would like to repeat my support for the progressing of this work in IETF.

Please see my attached email I sent earlier on in the year in which I expressed the reasons for why this work is important for 3GPP and GSMA.

Regards,
 
Ricky Kaura.

Principal Standards Engineer
Standands and Industry Affairs (SIA)
Samsung Electronics Research Institute
Tel:   +44 (0) 1784 428 600 Ext 635; Mob: +44 (0) 7760 761514; Fax: +44 (0) 1784 428 610
Email: [email-masked]; Skype: rickykaura; Yahoo: rkaura1969
Samsung Electronics (UK) Limited
Registered number: 03086621
Registered address: Communications house, South Street, Staines, Middlesex TW18 4QE.

-----Original Message-----
From: Worley, Dale R (Dale) [mailto:[email-masked]] 
Sent: 06 September 2011 20:16
To: Andrew Allen; Cullen Jennings
Cc: DISPATCH list
Subject: RE: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid

Dale

Subject: Re: [dispatch] Revision ofdraft-allen-dispatch-imei-urn-as-instanceid
From: Ricky Kaura <[email-masked]>
To: [email-masked]
Date: Wed, 02 Feb 2011 20:40:18 +0100

Dear all,

I work for Samsung and attend 3GPP CT1/CT meetings and GSM Association
(GSMA) Interworking, Roaming Expert Group (IREG), Roaming in LTE (RiLTE)
subgroup meetings.

I would like to express my support of draft-montemurro-gsma-imei-urn and
the associated draft-allen-dispatch-imei-urn-as-instanceid for the
following reasons:

*         3GPP has specified IMS emergency calls over LTE and GPRS in
3GPP Release 9. When originating an emergency call over these access
technologies, it is required to include the IMEI-URN as the instance ID
in the "+sip.instance" header field parameter in the Contact header of
the SIP INVITE (see 3GPP TS 23.237 and 3GPP TS 24.237). This is required
in order to support access transfer of emergency calls from the PS
domain to the CS domain. The IMEI is used at the Emergency Access
Transfer Function (EATF) to correlate the original IMS emergency session
with the session transfer request that was initiated from the MSC
(Mobile services Switching Centre) upon handover to the CS domain.
Specifically, in the case of limited service mode, where an IMS
registration does not necessarily occur, the IMEI is the only available
identifier that can be used to allow the EATF to correlate the source
and target access legs.

*         Recently in 3GPP TS 24.229, a CR was approved which states
that if a UE has an IMEI available, it shall always include the IMEI in
the "+sip.instance" header field parameter in the Contact header of the
SIP Register. The requirement for the inclusion of the IMEI came from
GSMA and is included in PRD IR.92. IR.92 is a user-to-network (UNI)
profile of the key 3GPP IMS specifications for voice and SMS over LTE
and has been developed in GSMA IREG RiLTE by a number of operators,
network vendors and device manufacturers. The requirement to include the
IMEI (if available) in the SIP Register is to support operator
requirements for the IMS network to perform an IMEI check when the UE is
IMS registered, as stated in the Stage 1 requirements in 3GPP TS 22.016
(section 5).  

*         3GPP developed a feature in Release 8 called "IMS Centralised
Services" (ICS) (see TS 23.292 and TS 24.292) which allows a user to
have a consistent set of features independent of whether the UE is on PS
access or CS access. 3GPP have defined the MSC server enhanced for ICS
to control voice sessions set up using circuit bearers. To enabled this
feature, the MSC server performs a SIP registration on behalf of the UE
when the UE is in the circuit domain. However, a registration for the
user may also exist in the PS domain. The IMEI included as the Instance
Id is used as a way of allowing the IMS network to identify that the SIP
registrations below to the same UE and to allow correct handling of
session establishment requests using GRUU.

*         The ICS feature in 3GPP also allows the use of specialised
functionality on the UE (i.e. an ICS client). Such a UE is called an ICS
UE. When the ICS UE performs a SIP registration, it identifies itself by
using the IMEI and includes this as the Instance Id in the SIP REGISTER.
When used in conjunction with an MSC server enhanced for ICS, the
application server in IMS can use the GRUU to correlate the SIP
signalling that comes directly from the UE with the SIP signalling that
comes via the MSC server when the ICE UE initiates an ICS session. 

In summary, these drafts are very important for the support of key
features in 3GPP.

I request that this work is progressed as quickly as possible in IETF. 

Regards,

Ricky Kaura.

Principal Standards Engineer

Standands and Industry Affairs (SIA)

Samsung Electronics Research Institute

Tel:   +44 (0) 1784 428 600 Ext 635; Mob: +44 (0) 7760 761514; Fax: +44
(0) 1784 428 610

Email:  <mailto:[email-masked]> [email-masked]; Skype:
rickykaura; Yahoo: rkaura1969

Samsung Electronics (UK) Limited

Registered number: 03086621

Registered address: Communications house, South Street, Staines,
Middlesex TW18 4QE.

---

From: <[email-masked]>
Date: Thu, 15 Sep 2011 06:29:00 +0200

+1

Mit freundlichen Grüßen
Roland Jesske

Deutsche Telekom Netzproduktion GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 58 12766 (Tel.)
+49 391 580 133 831 (Fax)
+49 171 8618-445  (Mobil)
E-Mail: mailto:[email-masked]
http://www.telekom.de

Erleben, was verbindet.

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: N.N. (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft Bonn
USt-IdNr. DE 814645262

Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

> -----Ursprüngliche Nachricht-----
> Von: [email-masked]
> [mailto:[email-masked]] Im Auftrag von DOLLY, MARTIN C
> Gesendet: Mittwoch, 14. September 2011 23:12
> An: Worley, Dale R (Dale); Andrew Allen; Cullen Jennings
> Cc: DISPATCH list
> Betreff: Re: [dispatch] draft-montemurro-gsma-imei-urn

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Sep 2011 07:34:59 +0200

+1

Regards,

Christer 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Worley, Dale R (Dale)
> Sent: 6. syyskuuta 2011 22:16
> I hope I'm not the only person who feels that this "debate" 
> is a tempest in a teapot.
> 
> I can't see any serious reason not to define a URN namespace 
> for IMEIs.  These names have various deficiencies from 
> various points of view, but none that are substantially worse 
> than the currently popular system of constructing URNs from 
> UUIDs which are constructed from MAC addresses (which are 
> printed on a label on the back of the phone).
> 
> There can only be interoperability problems if a proxy is 
> unable to accept instance-ids that are in namespaces that it 
> does not understand.  But such a proxy is clearly deficient, 
> and indeed, one would have to go out of one's way to build a 
> proxy that had this deficiency, since the simplest and most 
> natural implementation is to treat the instance-id as an 
> opaque string.
> 
> There may be IPR attached to this, but as the only vendors 
> who would care about using it are manufacturers who have 
> licensed the entire 3GPP IPR bundle, that causes nobody any 
> problems that they do not already have.
> 
> I regard to privacy, any user of a 3GPP phone has submitted 
> to having their privacy protected and violated to exactly the 
> degree designed into 3GPP, and the transmission of an 
> IMEI-based instance-id between the 3GPP phone through a 3GPP 
> network to a 3GPP registrar is not going to decrease (or
> increase) their privacy.
>

---

From: Laura Liess <[email-masked]>
Date: Thu, 15 Sep 2011 07:47:44 +0200

+1

Thanks,
Laura

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 15 Sep 2011 09:50:31 +0200

+1

/O

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 15 Sep 2011 11:46:35 -0400

Based on responses that have been sent to my original rant,

(1) I formally request the chairs to recognize that rough consensus
has been reached that the work described in
draft-montemurro-gsma-imei-urn and
draft-allen-dispatch-imei-urn-as-instanceid should progress, and those
proposals be dispatched to an appropriate working group.

(2) I ask any person who believes that the current methods of
constructing SIP instance ids can be significantly improved upon
(along any dimension), and who wishes to work on improving them,
present proposals for research and/or implementation to Dispatch or
another working group, so that the state of SIP can be improved.

Dale

---

From: "Leis, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 16 Sep 2011 07:19:33 +0200

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Worley, Dale R (Dale)
Sent: Tuesday, September 06, 2011 9:16 PM
To: Andrew Allen; Cullen Jennings
Cc: DISPATCH list
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn
anddraft-allen-dispatch-imei-urn-as-instanceid

of view, but none that are substantially worse than the currently
popular

There can only be interoperability problems if a proxy is unable to
accept
instance-ids that are in namespaces that it does not understand.  But
such a proxy is clearly deficient, and indeed, one would have to go out
of one's way to build a proxy that had this deficiency, since the
simplest
and most natural implementation is to treat the instance-id as an opaque
string.

There may be IPR attached to this, but as the only vendors who would
care about using it are manufacturers who have licensed the entire 3GPP
IPR bundle, that causes nobody any problems that they do not already
have.

Dale

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 16 Sep 2011 06:21:25 -0600

> proposals be dispatched to an appropriate working group.

Did any the emails sent since your rant discuss any of the issues raised? Of course no one has ever objected some organization such ad GSM having a URN they can use.

> another working group, so that the state of SIP can be improved.

I have.

---

From: Andrew Allen <[email-masked]>
Date: Fri, 16 Sep 2011 12:38:11 +0000

Cullen

I think my email prior to Dale's that Dale replied to  responded to all your points

Andrew

----- Original Message -----
From: Cullen Jennings [mailto:[email-masked]]
Sent: Friday, September 16, 2011 07:21 AM
To: Worley, Dale R (Dale) <[email-masked]>
Cc: Mary Barnes <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn	anddraft-allen-dispatch-imei-urn-as-instanceid

I have.

---

From: <[email-masked]>
Date: Fri, 16 Sep 2011 21:09:48 +0000

+1

Cheers,
Krisztian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Christer Holmberg
Sent: Wednesday, September 14, 2011 22:35
To: Worley, Dale R (Dale); Andrew Allen; Cullen Jennings
Cc: DISPATCH list
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid

+1

Regards,

Christer 

> IMEIs.  These names have various deficiencies from various points of 
> view, but none that are substantially worse than the currently popular 
> system of constructing URNs from UUIDs which are constructed from MAC 
> addresses (which are printed on a label on the back of the phone).
> 
> accept instance-ids that are in namespaces that it does not 
> understand.  But such a proxy is clearly deficient, and indeed, one 
> would have to go out of one's way to build a proxy that had this 
> deficiency, since the simplest and most natural implementation is to 
> treat the instance-id as an opaque string.
> 
> care about using it are manufacturers who have licensed the entire 
> 3GPP IPR bundle, that causes nobody any problems that they do not 
> already have.
> 
> their privacy protected and violated to exactly the degree designed 
> into 3GPP, and the transmission of an IMEI-based instance-id between 
> the 3GPP phone through a 3GPP network to a 3GPP registrar is not going 
> to decrease (or
> increase) their privacy.
>

---

From: Atle Monrad <[email-masked]>
Date: Sat, 17 Sep 2011 00:59:26 +0200

All

+1

I'd like to echo Dales request.

To me it seems that there are quite some support for progressing and completing draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid. 

3GPP needs a solution to this.

thanks
/atle

________________________________ 

Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management 
Ericsson

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 19 Sep 2011 02:57:48 +0000

I have read through all the emails since the one that started this thread back on May 18, and I agree with Dale.  Every issue raised has actually been responded to as far as I can tell, and clearly there is demand/interest.

In particular, since we actually need to DISPATCH these somewhere, I suggest that they both go the A-D sponsored path and not require a new mini-WG (and no existing group is appropriate afaict).

-hadriel

---

From: Andrew Allen <[email-masked]>
Date: Mon, 19 Sep 2011 03:00:47 +0000

+1

AD sponsored is my preferred approach.

Andrew

----- Original Message -----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Sunday, September 18, 2011 09:57 PM
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: DISPATCH list <[email-masked]>
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid

-hadriel

---

From: "VAN GEEL Jan (SDV/PSE)" <[email-masked]>
Date: Mon, 19 Sep 2011 08:44:08 +0200

Also Belgacom would like to see this draft progressed

Jan Van Geel 
IT and Network Specialist 
Belgacom SDE/SDV/PSE/FVC 
Tel: +32 2 202 1035 
Tel: +32 2 207 9032 
Email : [email-masked] 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Atle Monrad
Sent: 17 September 2011 00:59
To: Christer Holmberg; Worley, Dale R (Dale); Andrew Allen; Cullen Jennings
Cc: DISPATCH list
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid

All

+1

thanks
/atle

Atle Monrad
3GPP CT Chairman

**** DISCLAIMER ****
http://www.belgacom.be/maildisclaimer

---

From: <[email-masked]>
Date: Mon, 19 Sep 2011 15:05:36 +0200

+1

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la
> part de VAN GEEL Jan (SDV/PSE)
> Envoyé : lundi 19 septembre 2011 08:44
> À : DISPATCH list
> Objet : Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-
> Behalf Of Atle Monrad
> To me it seems that there are quite some support for progressing and
> completing draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-
> urn-as-instanceid.
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 20 Sep 2011 15:51:30 -0400

Given that the decision to be made in this working group is whether to
assign these I-Ds for further work to be done on them, there are a
small number of questions in play (with assorted other issues to be
addressed during the technical refinement of the proposal):

1.  Does this proposal introduce any interoperability problems?
2.  Does this proposal present any privacy concerns?
3.  Does this proposal allow anyone to extract an unconscionable
    "tax" (through the use of IPR)?

Here are my assessments of these issues:

1.  Does this proposal introduce any interoperability problems?

I don't see what interoperability problems can result from the
introduction of an additional format of URN, as long as the format
adheres to the generic URN syntax.  RFC 5626 section 4.1 makes it
clear that a SIP element may receive a +sip.instance value which is in
a URN namespace that it does not recognize, so any properly
constructed SIP element should be able to handle +sip.instance values
in namespaces that it does not have prior knowledge of.

(Certainly, the one product/project that I have detailed knowledge of
has always treated +sip.instance as a string.  Thereon hangs a tale:
If the +sip.instance is a UUID-based URN, and if the UUID is based on
a MAC address, the registrar extracts the MAC address so that the UA
can be addressed through a special URI that encodes its MAC address.
But it turns out that a popular make of UA formats its UUIDs
incorrectly, so that it was not recognized as a MAC-based UUID.  We've
had to add special code to the registrar to recognize this defective
URN format!)

2.  Does this proposal present any privacy concerns?

There would be general privacy concerns if this or any other
+sip.instance value was present in dialog-forming requests or
responses, and so could be seen by the other end of phone calls.  But
as far as I can tell, no UA uses +sip.instance in INVITEs;
+sip.instance values are presented only in REGISTER messages.

On the other hand, generated GRUU values are given in INVITEs, and the
GRUU can give information about the UA's +sip.instance and the AOR,
even if the GRUU is generated using a secret key.  However, the
problems resulting from this seem to be essentially the same when the
+sip.instance is derived from an IMEI as when it is derived from a MAC
address.

In regard to registrations, given that the intended scope of
application of the proposal is entirely within paid wireless networks,
there can be no privacy between the UA and its registrar.

3.  Does this proposal allow anyone to extract an unconscionable
    "tax" (through the use of IPR)?

Though this proposal may be encumbered by IPR claims, the only users
who would be *required* to use this URN format are products within the
GSM/3GPP/IMS universe, and even then, only if GSM/3GPP/IMS adopts this
as mandatory-to-implement.  Those users might be subjected to an
unconscionable tax, but the GSM/3GPP/IMS universe has its own
political/economic structure for deciding what licensed technology is
mandatory to implement and what licensing terms are considered
acceptable.  It seems to me that we can justly leave these questions
to GSM/3GPP/IMS.

There is some concern that the IPR disclosures were filed "late".
However, as the latest IPR disclosure was filed in January 2011, the
working group is now even later, and the objection has expired.

In summary, I don't see any of these issues as being particularly
problematic.  If I've overlooked an important aspect of this, I would
like to see some detailed information about it.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Sep 2011 13:32:43 -0400

> had to add special code to the registrar to recognize this defective

Can you say more? (Or is this all proprietary?)
This usage sounds bizarre. The REGISTER contains the Contact URI at 
which the UA wishes to be reached. What is the point of forming a 
different URI from the MAC? How can you know that it will work?

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 21 Sep 2011 14:23:24 -0400

> From: Paul Kyzivat [[email-masked]]
> 

All of this is in open-source versions of sipX, so it's not
proprietary.

Remember, sipX is a PBX, so it is in environment that is not
particularly sensitive for privacy and security, but conversely, it
has to service various needs that do not arise in wider-scale
communications.

In this case, we discovered that we want to be able to address "all
the line appearances on a phone" and also "a particular line
appearance on a particular phone".  Situations where these are useful
include:

- Ordering a particular phone to reboot when the provisioning system
  has revised the configuration files that it should load.

- Being able to drive a BLF light with "Is the boss's phone busy?"
  (In the common case where the assistant's phone also has an
  appearance of the boss's extension (AOR), a BLF light on the
  assistant's phone that reports whether the boss's AOR is busy is not
  particularly useful, since most of the times when the assistant
  needs to know if the boss is on the phone are when the assistant is
  talking to a caller on the boss's AOR.)

Of course, the registered contacts for the phone can be used for these
purposes, but the contact URIs are dynamic, which makes them hard to,
e.g., insert in a BLF "resource list".

The solution is to define a series of special URIs that are mapped
through the registration database *in different ways* than AORs are
mapped.  In our implementation (see
http://sipxecs.sipfoundry.org/rep/sipXecs/main/meta/system-sip-identities):

- sip:~~in~[MAC address]@[domain] is mapped to all contacts registered
  by the phone with the specified MAC address.

- sip:~~in~[user name]&[MAC address]@[domain] is mapped to all contacts
  registered for the specified SIP user name by the phone with the
  specified MAC address.

As a mathematician, I want to add for completeness:

- sip:[user name]@[domain] is mapped to all contacts registered for
  the specified SIP user name.

During registration, the registrar extracts from the REGISTER request
the MAC address of the phone, via:

- If +sip.instance is given, and its value is a URN derived from a
  UUID, and the UUID is based on a MAC address, that MAC address is
  used.

- If that fails, the "authentication user" from the Authorization
  header is examined to see if it has the form [user name]/[MAC
  address].  If so, the MAC address is used (and the user name part is
  used to look up the password).  (This form is useful if the phone
  does not provide +sip.instance, as all phones allow the
  arbitrary configuration of the authentication user.)

Thus, for instance, if the provisioning system has generated new
configuration files for the phone with MAC address 0123456789ab, it
can send a NOTIFY for "Event: check-sync" to URI
sip:~~in~0123456789ab@[domain].  Previously, the provisioning system
sent the NOTIFY to the AOR of the first line appearance on the phone,
which often rebooted more phones than needed to be rebooted.

If an assistant wants a BLF for "Is the boss's phone busy?", the BLF
URI can be sip:~~in~[boss's MAC address]@[domain].  Conveniently, that
monitors *all* of the boss's line appearances, even if he has more
than one AOR on his phone.

More narrowly, each line appearance on the boss's phone can be
monitored separately with URIs of the form sip:~~in~[user
name]&[boss's MAC address]@[domain].

I suppose that in abstract the same functionality can be implemented
by the various subsystems examining the registration database themselves,
e.g., the provisioning system could look up the current contact of phone
0123456789ab itself.  But sipX is not a monolithic system, it is a set of
processes that communicate via SIP, and the registration lookups are
done entirely by the redirection facility of the proxy/registrar.  So the
provisioning system would rather not have to dig through the registration
database itself.  Instead, we give it a set of URIs it can use to request
that the redirector does the desired lookup.

In no case does a phone use these URIs to identify itself, so there
isn't much of a privacy problem.  They do allow a caller to more
finely control routing of his call, but a caller can often obtain the
same effect by placing a call to a Contact saved from a previous
dialog.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Sep 2011 19:17:41 -0400

OK, what you describe isn't as disturbing to me as what I thought at 
first. What you are saying is that the registrar/proxy is *deriving* 
some added AORs, and location db for them, from from properties of the 
registered contacts. The names of these added AORs are defined by 
convention.

The only thing I find wrong with that is that the anyone wanting to use 
those AORs must know the convention. Given the unfriendliness of the 
names, I presume that they aren't typically entered by humans - but 
rather are derived by software that understands the convention. Any such 
software is of course then dependent on the registrar following these 
conventions. For instance, if I had a softphone with a BLF light that I 
wanted to use as the secretary's phone in the case you describe below, 
it would need to be customized for this convention before it would work 
right.

While this is a potential interoperability problem, its not likely to be 
much of a problem in practice, at least as things are typically deployed.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 22 Sep 2011 11:26:54 -0400

> those AORs must know the convention. 

Yes...  If you want to call Joe, you have to know his name, phone
number, or some such.  If you want status information on a particular
line appearance, you have to know how to specify it.

> Given the unfriendliness of the names, I presume that they aren't
> typically entered by humans - but rather are derived by software that
> understands the convention.

In general, we do expect most uses of special URIs to be
software-generated, although one can use them manually, too.  The
biggest constraint is that we needed to define a syntax that would
allow the creation of many series of special URIs (there are 10 now in
use) and minimize the risk of collision with "legitimate" user
names/phone numbers.

So the syntax "~~[letter][letter]~[arbitrary]" was reserved for
special purpose user names, and the provisioning system prevents
administrators from creating names that start with "~~".

The prefix "~~in~" is thus used for "instrument identity user names".

> While this is a potential interoperability problem, its not likely
> to be much of a problem in practice, at least as things are
> typically deployed.

It's not clear to me how this could lead to an interoperability
problem, as the PBX is the authority for the use of user names within
its own domain.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Sep 2011 13:25:21 -0400

> line appearance, you have to know how to specify it.

My general philosophy is that URIs are determined by the recipient, and 
conveyed to those that will use them. While its possible to "guess" 
URIs, there are in general no guarantees that doing so will get the 
result you intend.

In some realms there are conventions about how URIs are constructed, 
making it possible to guess with higher confidence, *if* you know the 
convention for that realm. That's what I see here - a realm with a 
convention that facilitates guessing, to those that are clued in to it.

> problem, as the PBX is the authority for the use of user names within

An example of when the interop problem would arise is if I introduce a 
new phone into a system that has this convention. I then may have to 
modify it to take advantage of this convention (to get its lights to 
work in the proper cases.) Then later, if the phone system gets swapped 
out for one that doesn't support the same convention, the phone's 
feature will no longer work.

Its an interop problem because it is non-standard behavior. Its not an 
issue as long as you stick to standardized behavior.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 22 Sep 2011 14:40:42 -0400

> feature will no longer work.

You don't have to modify the phone to use this convention, you just
have to give the phone the proper URIs for each BLF light, matching
what status you want the BLF light to report.  These URIs are, after
all, syntactically correct.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Sep 2011 15:19:56 -0400

> all, syntactically correct.

You can just configure the phone as you say, IF:

- the phone has a configurable light
- the light can be configured with a URI
- the phone determines the light status by using the URI
   in the way intended by the target of that URI

AFAIK all of those are unusual properties, except for the specific 
equipment that currently supports it. If I have some "other" phone I am 
out of luck unless I am in a position to modify it in that way.

I'm not saying that any of this is a bad thing to do.
I'm just saying that it is still in the realm of proprietary systems.
Conceivably it could be expanded into a standard, but nobody seems to be 
working on that.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 23 Sep 2011 11:46:16 -0400

> out of luck unless I am in a position to modify it in that way.

I may be completely misunderstanding you, but I know of no SIP phone
which is claimed to "have BLF lights" that does *not* implement the
points you've listed.

Dale

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 23 Sep 2011 11:22:01 -0500

> which is claimed to "have BLF lights" that does *not* implement the

Yeah... I was going to post the same thing, but wasn't quite sure if I 
was missing something obvious :-)

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org