Subject: [Ecrit] ELIN

From: "Karl Heinz Wolf" <[email-masked]>
Date: Mon, 12 Nov 2007 09:23:27 +0100

LLDP-MED supports not just civic and coordinate based location
information, but also an ELIN. How does this type of location
information fit to the IETF Framework? Is this case considered in any
document?
I couldn't find any information on how to proceed with this type of
location information.

cheers
Karl Heinz

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 12 Nov 2007 03:03:21 -0600

Hi Karl Heinz,

An ELIN is a specific callback number that represents an area in an MLTS
(Multi-Line Telephone System). As far as I know they are only used in
the USA. The following description may not be 100% right, but it is
pretty close.

Essentially if you have a company or campus that occupies a large area,
you can break this up into smaller areas to make it easier for emergency
service crews to find people. In some States this is mandated when the
area becomes more than a certain size (8000 sqr feet is commonly
quoted). Generally what happens is that all telephone extensions in a
certain area are associated with what is called an ERL (emergency
resource location), this is done in the PABX provisioning. Each ERL is
allocated an ELIN that serves as the presented calling number to the
PSAP for any extension provisioned against the ERL. The PSAP is able to
use the ELIN to get the floor location and area serviced by a specific
ELIN. The ELIN also serves as the number that the PSAP will callback in
the case of the call being dropped.

To this extent the ELIN is the way in which LLDP-MED currently supports
location by reference.

Please let me know if this isn't clear and I will try an clarify
further.

Cheers
James

> -----Original Message-----
> From: Karl Heinz Wolf [mailto:[email-masked]]
> Sent: Monday, 12 November 2007 7:23 PM
> To: ECRIT
> Subject: [Ecrit] ELIN
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Mon, 12 Nov 2007 10:30:38 +0100

Hi James!

Thank you for your detailed description of the ELIN.
One more question: how does the callback from the PSAP work, if there
are multiple extensions with the same ELIN?

Anyway, in case a company uses ELINs, and LLDP-MED location
information tells the client this ELIN, what is the client supposed to
do?

cheers
karl heinz

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 12 Nov 2007 03:46:42 -0600

Hi Karl Heinz,

It is the only the extension that actually has the ELIN number that gets
called back. So all extensions with the same ELIN need to be close to
one another.

As to what the client does when its gets the ELIN from LLDP-MED I have
no idea... *8)

Cheers
James

> Sent: Monday, 12 November 2007 8:31 PM
> To: Winterbottom, James
> Cc: ECRIT
> Subject: Re: [Ecrit] ELIN
> 
> Hi James!
> 
------------------------------------------------------------------------
> ------------------------
------------------------------------------------------------------------
> ------------------------

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 12 Nov 2007 09:47:26 -0600

And I guess the other point is that the PABX allocates the ELIN to the
outgoing call dynamically and assigns it to the originating extension
(in case of callback) for the duration of the call and some period after
call termination? There should be a pool of ELINs for each ERL in case
more than one extension is originating an emergency call from that ERL.

The other half of the story is that this generally works in conjunction
with what is known as PS-ALI (Private switch ALI). It's a two port
arrangement. It's a standard ALI from the PSAP perspective, but the
enterprise has access to the database and can populate it with the
ELIN-ERL information.

One thing an LLDP-MED client could do is provide the ELIN to the PABX in
the call setup. This is beyond the scope of the LLDP-MED specification.

On the other hand, it's all a bit half-baked, and it really wasn't a
good idea to embed this sort of application information down at the link
layer in the first place - IMHO.

Cheers,
Martin

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Monday, 12 November 2007 8:47 PM
To: Karl Heinz Wolf
Cc: ECRIT
Subject: RE: [Ecrit] ELIN

Hi Karl Heinz,

Cheers
James

---

From: [email-masked]
Date: Mon, 12 Nov 2007 11:08:46 -0500

Hi Karl, 
James' description earlier on how ELIN works is essentially correct.  A 
couple of added bits:

- ELIN can also be used for ECS call routing.  If the call gets placed on 
an out of district GW, it can be used in PSTN to route to the correct (in 
district) PSAP. 

- At the PSAP, ELIN is effectively a dB index to look up details on the 
source of the call, based on ERL data that is provisioned in the PSAP dB 
(street location, in-building location, etc etc)

- I don't *think* ELIN is generally used as the callback number.  In 
ISDN-based signalling, there is both the ELIN and a callback number.  I 
*think* the PSAP side is (or can be) provisioned with callback 
corresponding to the ELIN in its dB.  The callback number is typically not 
an extension, but a designated responder within the enterprise at that 
location, e.g. the security desk.  Perhaps others on the list with direct 
experience can comment on this point? 

> ... all extensions with the same ELIN need to be close to one another.
Yes, all extensions with the same ELIN *will* be physically close 
together.  But this is not directly related to callback.  It is by 
definition of what the ERL is -- it is a small enough region in a building 
to allow emergency responders to find someone. 

> ... what the client does when its gets the ELIN from LLDP-MED I have no 
idea
ELIN was added to LLDP-MED for completeness and for compatibility with 
existing PSTN infrastructure.  Since existing E911 systems in N.A. use 
ELIN today, there was no easy way to support it with Civic and Geo types 
only.  (I am a little surprised ELIN type has not been defined in IETF as 
well ... but that's another story.)  Thinking was that the device could 
receive ELIN, pass it in SIP signalling towards PSTN GW, that would then 
insert the ELIN into PSTN trunk signalling.  I do not know if anyone uses 
it this way. 

> To this extent the ELIN is the way in which LLDP-MED currently supports
Yes, ELIN is effectively a form of location-by-reference.  LLDP-MED can 
also be readily extended to support LbyR in the sense used in Geopriv / 
ECRIT as well.  Since location objects are directly supplied by the 
network infrastructure in LLDP-MED's case, it is not entirely clear to me 
why LbyR would really be needed / useful for LLDP-MED deployments. 

Cheers, 
Peter Blatherwick

"Winterbottom, James" <[email-masked]>
12.11.07 04:46
 
        To:     "Karl Heinz Wolf" <[email-masked]>
        cc:     ECRIT <[email-masked]>
        Subject:        RE: [Ecrit] ELIN

Hi Karl Heinz,

Cheers
James

---

From: "Rodrig, Benny (Benny)" <[email-masked]>
Date: Mon, 12 Nov 2007 11:47:54 -0500

Another point to add is that when an endpoint moves within the
campus/enterprise, a different ELIN may have to be passed to the PSAP
with the emergency call, depending on the endpoint's location. To figure
this out automatically, getting the right ELIN directly from the local
network via LLDP-MED can be a good solution.
 
Regarding the callback point below - I think the ELIN is typically used
as the callback number, and the MLTS can then either forward the
callback to the original caller or to a designated responder e.g. the
security desk.
 
Benny

________________________________

	From: [email-masked]
[mailto:[email-masked]] 
	Sent: Monday, November 12, 2007 11:09 AM
	To: Karl Heinz Wolf; Winterbottom, James
	Cc: ECRIT
	Subject: RE: [Ecrit] ELIN

	Hi Karl,   
	James' description earlier on how ELIN works is essentially
correct.  A couple of added bits: 
	
	- ELIN can also be used for ECS call routing.  If the call gets
placed on an out of district GW, it can be used in PSTN to route to the
correct (in district) PSAP.   
	
	- At the PSAP, ELIN is effectively a dB index to look up details
on the source of the call, based on ERL data that is provisioned in the
PSAP dB (street location, in-building location, etc etc) 
	
	- I don't *think* ELIN is generally used as the callback number.
In ISDN-based signalling, there is both the ELIN and a callback number.
I *think* the PSAP side is (or can be) provisioned with callback
corresponding to the ELIN in its dB.  The callback number is typically
not an extension, but a designated responder within the enterprise at
that location, e.g. the security desk.  Perhaps others on the list with
direct experience can comment on this point?   
	
	> ... all extensions with the same ELIN need to be close to one
another. 
	Yes, all extensions with the same ELIN *will* be physically
close together.  But this is not directly related to callback.  It is by
definition of what the ERL is -- it is a small enough region in a
building to allow emergency responders to find someone.   
	
	> ... what the client does when its gets the ELIN from LLDP-MED
I have no idea 
	ELIN was added to LLDP-MED for completeness and for
compatibility with existing PSTN infrastructure.  Since existing E911
systems in N.A. use ELIN today, there was no easy way to support it with
Civic and Geo types only.  (I am a little surprised ELIN type has not
been defined in IETF as well ... but that's another story.)  Thinking
was that the device could receive ELIN, pass it in SIP signalling
towards PSTN GW, that would then insert the ELIN into PSTN trunk
signalling.  I do not know if anyone uses it this way.   
	
	> To this extent the ELIN is the way in which LLDP-MED currently
supports
	Yes, ELIN is effectively a form of location-by-reference.
LLDP-MED can also be readily extended to support LbyR in the sense used
in Geopriv / ECRIT as well.  Since location objects are directly
supplied by the network infrastructure in LLDP-MED's case, it is not
entirely clear to me why LbyR would really be needed / useful for
LLDP-MED deployments.   
	
	Cheers, 
	Peter Blatherwick 

	

12.11.07 04:46 

	Hi Karl Heinz,
	
	It is the only the extension that actually has the ELIN number
that gets
	called back. So all extensions with the same ELIN need to be
close to
	one another.
	
	As to what the client does when its gets the ELIN from LLDP-MED
I have
	no idea... *8)
	
	Cheers
	James

	> > An ELIN is a specific callback number that represents an
area in an
	MLTS
	> > (Multi-Line Telephone System). As far as I know they are
only used
	in
	> > Essentially if you have a company or campus that occupies a
large
	area,
	> > you can break this up into smaller areas to make it easier
for
	emergency
	> > service crews to find people. In some States this is
mandated when
	the
	> > quoted). Generally what happens is that all telephone
extensions in
	a
	> > resource location), this is done in the PABX provisioning.
Each ERL
	is
	> > PSAP for any extension provisioned against the ERL. The PSAP
is able
	to
	> > use the ELIN to get the floor location and area serviced by
a
	specific
	> > ELIN. The ELIN also serves as the number that the PSAP will
callback
	in
	> > To this extent the ELIN is the way in which LLDP-MED
currently
	supports
	> > > information fit to the IETF Framework? Is this case
considered in
	any
	> > > document?
	> > > I couldn't find any information on how to proceed with
this type
	of

	contain privileged, proprietary, or otherwise private
information.

---

From: [email-masked]
Date: Mon, 12 Nov 2007 13:57:31 -0500

Hi again, and thanks for the further input Benny, 

Yes, I certainly agree (contrary to Martin's obviously inflammatory and 
self-serving comments earlier) that LLDP-MED can make a very good, simple 
solution in many situations.  And many of those scenarios need to address 
working with traditional E911 systems, hence inclusion of ELIN in 
LLDP-MED.  For better or worse, interworking with pre-existing ECS systems 
such as E911 is not a part of ECRIT's mandate, hence is not described in 
any ECRIT document, or anywhere in IETF for that matter. 

LLDP-MED only defines the protocol and exchange of TLVs.  The usage is 
defined in other documents. 

For a bit more background on this, and how it can play in to the 
application level, see also TIA's TSB-146-A which describes several 
network topologies and possible solutions to the emergency call location 
problem, as well as others pieces of the puzzle.  Note that this document 
was not intended to define any particular solution, but to discuss a range 
of alternatives.  Although recently updated (in March 07) it is also a 
second revision with the first dating several years back now (2004 I 
believe).  Available at: 
 
http://www.tiaonline.org/standards/technology/voip/documents/TSB-146-AFinalforPublication.pdf
(You will likely be asked to fill in some info and press [I agree] button 
on the way.) 

See also DSL Forum draft WT-164 recently posted to this list, which shows 
device startup state diagrams including LLDP-MED, DHCP and HELD. 

Cheers, 
Peter Blatherwick

"Rodrig, Benny (Benny)" <[email-masked]>
12.11.07 11:47
 
        To:     <[email-masked]>, "Karl Heinz Wolf" 
<[email-masked]>, "Winterbottom, James" <[email-masked]>
        cc:     "ECRIT" <[email-masked]>
        Subject:        RE: [Ecrit] ELIN

Another point to add is that when an endpoint moves within the 
campus/enterprise, a different ELIN may have to be passed to the PSAP with 
the emergency call, depending on the endpoint's location. To figure this 
out automatically, getting the right ELIN directly from the local network 
via LLDP-MED can be a good solution.
 
Regarding the callback point below - I think the ELIN is typically used as 
the callback number, and the MLTS can then either forward the callback to 
the original caller or to a designated responder e.g. the security desk.
 
Benny

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 12, 2007 11:09 AM
To: Karl Heinz Wolf; Winterbottom, James
Cc: ECRIT
Subject: RE: [Ecrit] ELIN

Hi Karl, 

idea 

Cheers, 
Peter Blatherwick 

Hi Karl Heinz,

Cheers
James

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Thu, 15 Nov 2007 11:25:26 +0100

Hi Peter,
thanks for your additional information on ELINs.

> existing PSTN infrastructure.  Since existing E911 systems in N.A. use ELIN
> today, there was no easy way to support it with Civic and Geo types only.
> (I am a little surprised ELIN type has not been defined in IETF as well ...
> but that's another story.)  Thinking was that the device could receive ELIN,
> pass it in SIP signalling towards PSTN GW, that would then insert the ELIN
> into PSTN trunk signalling.  I do not know if anyone uses it this way.
>

How can this gateway be determined?
Would it be imaginable to have a LoST location profile for ELINs, get
the responsible PSAP via LoST for the given ELIN and convey the ELIN
in the SIP message directly to the PSAP (without a gateway) as
location by reference?

cheers,
karl heinz

> Yes, ELIN is effectively a form of location-by-reference.  LLDP-MED can also
> be readily extended to support LbyR in the sense used in Geopriv / ECRIT as
> well.  Since location objects are directly supplied by the network
> infrastructure in LLDP-MED's case, it is not entirely clear to me why LbyR
> would really be needed / useful for LLDP-MED deployments.
>
> Cheers,
> Peter Blatherwick
>
>
>
>
>
>
>

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 15 Nov 2007 08:36:40 -0500

Karl, 

> Would it be imaginable to have a LoST location profile for 
> ELINs, get the responsible PSAP via LoST for the given ELIN 
> and convey the ELIN in the SIP message directly to the PSAP 
> (without a gateway) as location by reference?
> 

In the US PSTN today, E911 location is supported via an out-of-band database
that uses calling party number (ANI) as the query key.  Enterprises will
assign an ELIN to a geographic area of their campus, submit the proper
database entry, then swap the calling party to match the ELIN on outbound
911 calls.  This allows the PSAP to use the ELIN and query the database for
the location information.  PSAP callbacks can be redirected to the
originator via the enterprise call control (requires the ELIN to be a
dialable number).  This mechanism facilitates the moves-adds-changes of
enterprise phones around the campus without the requirement for constant
database updates, the ELINs are static.  The enterprise call control can
locate the phone using normal L2/L3 network management tools.  The gateway
is normally operated by the enterprise and gateway selection is based on the
ELIN/campus location.

There are 1000s of these systems operating in the US today.

I hope this helps,

-Marc-

---

From: [email-masked]
Date: Thu, 15 Nov 2007 10:15:51 -0500

Hi again Karl,
See Marc's nice description... 

Specifically on the IETF work, I think ELIN probably does not apply very 
well, since ECRIT scope is explicitly not covering interfacing to 
traditional PSTN-base Emerg Call Service, and is explicitly international 
in scope.   ELIN is (at this time) specific to N.A. E-911 for enterprise. 
Might be worth considering though, just not here ... hmmm ..... 

-- Peter

"Karl Heinz Wolf" <[email-masked]>
15.11.07 05:25
 
        To:     [email-masked]
        cc:     "Winterbottom, James" <[email-masked]>, 
ECRIT <[email-masked]>
        Subject:        Re: [Ecrit] ELIN

Hi Peter,

> existing PSTN infrastructure.  Since existing E911 systems in N.A. use 
ELIN

cheers,
karl heinz

> Yes, ELIN is effectively a form of location-by-reference.  LLDP-MED can 
also
>  > > PSAP for any extension provisioned against the ERL. The PSAP is 
able
callback

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 15 Nov 2007 11:42:08 -0500

ELINs are peculiar to the U.S. Multiple Line Telephone Systems, and really
are only applicable in the current TDM based emergency calling system.  I
don't think it makes any sense to mix current generation systems, which
would include ELINs with next generation, IP based systems.

PBX systems today cater to specific countries emergency call systems, which
in the U.S. would include support for ELINs.  I don't think we get enough
mileage out of standardizing something that is specific to the U.S., and is
going away in favor of a more general LoST based routing system.

Brian

> Sent: Thursday, November 15, 2007 5:25 AM

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 15 Nov 2007 17:52:42 -0600

I agree with this. To be useful there would need to be a scenario where
the ELIN was available but location (or the location represented by the
ERL) was not. How realistic is this?

This would also turn the LoST server into an ALI... which, as Brian
says, is actually the model which is going away - on the assumption that
phone numbers simply don't reliably represent location any more.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, 16 November 2007 3:42 AM
To: 'Karl Heinz Wolf'; [email-masked]
Cc: 'ECRIT'
Subject: RE: [Ecrit] ELIN

ELINs are peculiar to the U.S. Multiple Line Telephone Systems, and
really
are only applicable in the current TDM based emergency calling system.
I
don't think it makes any sense to mix current generation systems, which
would include ELINs with next generation, IP based systems.

PBX systems today cater to specific countries emergency call systems,
which
in the U.S. would include support for ELINs.  I don't think we get
enough
mileage out of standardizing something that is specific to the U.S., and
is
going away in favor of a more general LoST based routing system.

Brian

> > > ... what the client does when its gets the ELIN from LLDP-MED I
have
> no
> > (I am a little surprised ELIN type has not been defined in IETF as
well
> ...
> > but that's another story.)  Thinking was that the device could
receive
> ELIN,
> > pass it in SIP signalling towards PSTN GW, that would then insert
the
> > be readily extended to support LbyR in the sense used in Geopriv /
ECRIT
> as
> > infrastructure in LLDP-MED's case, it is not entirely clear to me
why
> LbyR
> >  > information tells the client this ELIN, what is the client
supposed
> >  > > An ELIN is a specific callback number that represents an area
in an
> >  MLTS
> >  > > (Multi-Line Telephone System). As far as I know they are only
used
large
> >  > > service crews to find people. In some States this is mandated
when
extensions in
> >  > > resource location), this is done in the PABX provisioning. Each
ERL
> >  is
> >  > > allocated an ELIN that serves as the presented calling number
to
considered in
> >  any
> >  > > > document?
> >  > > > I couldn't find any information on how to proceed with this
type
> >  > > > Karl Heinz
-----------------------------------------------------------------------
> -
information.
> >  > > this email is prohibited.
-----------------------------------------------------------------------
> -

---

From: [email-masked]
Date: Thu, 15 Nov 2007 21:21:04 -0500

Hi, 

> ... To be useful there would need to be a scenario where

Excuse me but...   In N.A. at present, for enterprise, this is actually 
the 99.9<blah>% case (choose your number of 9s).  ELIN is how it works 
today, and it is provisioned all over, right now, with large investments 
involved on all fronts.  These are really big numbers.  ECRIT all-SIP 
approach has approximately 0% penetration at this time, since it is not 
finished or deployed in any large numbers at all (yet).  ELIN-based 
enterprise systems are current reality in N.A. and will take a very long 
transition time to change over.  They need to be supported.  This *will* 
all change of course, and for all the right reasons.  I fully support 
this!  But it will just take a really long time to accomplish. 

Thus, it is twisting reality very drastically to suggest that the case for 
supporting currently deployed PSTN ECS (E911) systems is not "useful", 
"realistic" or "available".  That's actually exactly where we are today! 

But, I do agree, for IETF (specifically ECRIT) it probably does not make 
much sense to standardize anything specific around ELIN at this point in 
time.  As previously stated it is our of scope by definition for ECRIT. 
Too little, too late, wrong group. 

-- Peter

"Dawson, Martin" <[email-masked]>
15.11.07 18:52
 
        To:     "Brian Rosen" <[email-masked]>, "Karl Heinz Wolf" 
<[email-masked]>, <[email-masked]>
        cc:     "ECRIT" <[email-masked]>
        Subject:        RE: [Ecrit] ELIN

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, 16 November 2007 3:42 AM
To: 'Karl Heinz Wolf'; [email-masked]
Cc: 'ECRIT'
Subject: RE: [Ecrit] ELIN

Brian

have
well
receive
the
ECRIT
why
supposed
in an
used
large
when
extensions in
ERL
to
considered in
type
information.

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 15 Nov 2007 23:34:35 -0600

I don't understand the reaction.

The question was whether it would be useful to make ELIN a query key to
LoST. I only said I thought it would be unusual in an Internet delivered
emergency call to have a system that could pick up an ELIN but not an
ERL - meaning it you'd expect it could use location to make the query
per existing LoST semantics. I never suggested ELIN isn't commonly
deployed....

Regards,

Martin

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, 16 November 2007 1:21 PM
To: Dawson, Martin
Cc: Brian Rosen; ECRIT; Karl Heinz Wolf
Subject: RE: [Ecrit] ELIN

Hi, 

Thus, it is twisting reality very drastically to suggest that the case
for supporting currently deployed PSTN ECS (E911) systems is not
"useful", "realistic" or "available".  That's actually exactly where we
are today!   

-- Peter 

 

15.11.07 18:52 

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, 16 November 2007 3:42 AM
To: 'Karl Heinz Wolf'; [email-masked]
Cc: 'ECRIT'
Subject: RE: [Ecrit] ELIN

Brian

have
well
receive
the
ECRIT
why
supposed
in an
used
large
when
extensions in
ERL
to
considered in
type
information.

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 15 Nov 2007 23:36:30 -0600

Well - if having an opinion equates to self-serving then "guilty as
charged"; it certainly doesn't make me Robinson Crusoe in this forum.

All I mean is that the ELIN, being a fairly North American and
application specific parameter seems somewhat out of place in a general
link layer spec. As has been noted, it's pretty much a reference (though
not an invitation to a callback as used with HELD) - and probably not
even the ELIN the private switch will use since it needs to consider the
dynamics of how many calls are originating. As such, I would have
thought that the switch and port identity available through standard
LLDP (sans MED) would have served the same purpose. I didn't say it
isn't "convenient".

Cheers,

Martin

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, 13 November 2007 5:58 AM
To: Rodrig, Benny (Benny)
Cc: ECRIT
Subject: RE: [Ecrit] ELIN

Yes, I certainly agree (contrary to Martin's obviously inflammatory and
self-serving comments earlier) that LLDP-MED can make a very good,
simple solution in many situations.  And many of those scenarios need to
address working with traditional E911 systems, hence inclusion of ELIN
in LLDP-MED.  For better or worse, interworking with pre-existing ECS
systems such as E911 is not a part of ECRIT's mandate, hence is not
described in any ECRIT document, or anywhere in IETF for that matter.

For a bit more background on this, and how it can play in to the
application level, see also TIA's TSB-146-A which describes several
network topologies and possible solutions to the emergency call location
problem, as well as others pieces of the puzzle.  Note that this
document was not intended to define any particular solution, but to
discuss a range of alternatives.  Although recently updated (in March
07) it is also a second revision with the first dating several years
back now (2004 I believe).  Available at: 
 
http://www.tiaonline.org/standards/technology/voip/documents/TSB-146-AFi
nalforPublication.pdf 
(You will likely be asked to fill in some info and press [I agree]
button on the way.)   

See also DSL Forum draft WT-164 recently posted to this list, which
shows device startup state diagrams including LLDP-MED, DHCP and HELD.

Cheers, 
Peter Blatherwick 

12.11.07 11:47 

        To:        <[email-masked]>, "Karl Heinz Wolf"
<[email-masked]>, "Winterbottom, James"
<[email-masked]> 
        cc:        "ECRIT" <[email-masked]> 
        Subject:        RE: [Ecrit] ELIN

  
Benny 

Hi Karl,   

- ELIN can also be used for ECS call routing.  If the call gets placed
on an out of district GW, it can be used in PSTN to route to the correct
(in district) PSAP.   

> ... what the client does when its gets the ELIN from LLDP-MED I have
no idea 
ELIN was added to LLDP-MED for completeness and for compatibility with
existing PSTN infrastructure.  Since existing E911 systems in N.A. use
ELIN today, there was no easy way to support it with Civic and Geo types
only.  (I am a little surprised ELIN type has not been defined in IETF
as well ... but that's another story.)  Thinking was that the device
could receive ELIN, pass it in SIP signalling towards PSTN GW, that
would then insert the ELIN into PSTN trunk signalling.  I do not know if
anyone uses it this way.   

Yes, ELIN is effectively a form of location-by-reference.  LLDP-MED can
also be readily extended to support LbyR in the sense used in Geopriv /
ECRIT as well.  Since location objects are directly supplied by the
network infrastructure in LLDP-MED's case, it is not entirely clear to
me why LbyR would really be needed / useful for LLDP-MED deployments.   

Cheers, 
Peter Blatherwick 

12.11.07 04:46 

Hi Karl Heinz,

Cheers
James

---

From: [email-masked]
Date: Fri, 16 Nov 2007 11:23:57 -0500

Martin,
Yes, chassis_id / port_id based location tracking is also quite possible, 
of course.  And LLDP-MED further tightens this possibility by constraining 
the id types presented by underlying LLDP, making it more predictable 
exactly what will be presented.  In practical enterprise systems 
interfacing to existing infrastructure, use of ELIN is also valid, and 
equivalent in fact.  But use of ELIN directly would save a look-up step. 
LLDP-MED added ELIN since was a very easy and obvious location type to 
have available along with the IETF specified ones.  At the time, 
specifying ELIN was also in line with NENA directions for compatibility in 
N.A.  Since ELIN is really just a string of digits, it can also be used in 
lots of other ways too.  Support of currently deployed N.A. E-911 
interfacing is simply an absolutely huge use case, so why would it not be 
added?? 

To repeat myself, since IETF ECRIT / Geopriv does not have support of 
existing PSTN systems in its mandate, I agree use of ELIN likely does not 
play in there.  But, that does not make it "half baked", to repeat your 
earlier words.  Support of existing systems, deployed in huge numbers, and 
highly likely to keep existing for a very long time, just makes pragmatic 
sense. 

-- Peter

16.11.07 00:36
 
        To:     <[email-masked]>, "Rodrig, Benny (Benny)" 
<[email-masked]>
        cc:     "ECRIT" <[email-masked]>
        Subject:        RE: [Ecrit] ELIN

Well – if having an opinion equates to self-serving then “guilty as 
charged”; it certainly doesn’t make me Robinson Crusoe in this forum.
 
All I mean is that the ELIN, being a fairly North American and application 
specific parameter seems somewhat out of place in a general link layer 
spec. As has been noted, it’s pretty much a reference (though not an 
invitation to a callback as used with HELD) – and probably not even the 
ELIN the private switch will use since it needs to consider the dynamics 
of how many calls are originating. As such, I would have thought that the 
switch and port identity available through standard LLDP (sans MED) would 
have served the same purpose. I didn’t say it isn’t “convenient”.
 
Cheers,
Martin

    

Cheers, 
Peter Blatherwick 

 

  
  
Benny 

Hi Karl, 

idea 

Cheers, 
Peter Blatherwick 

 

Hi Karl Heinz,

Cheers
James

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 16 Nov 2007 11:47:53 -0500

Peter,
 
In MLTS it's called ELIN and it's 'half baked'.
 
In cellular it's called P-ANI, ESRN, ESQK, etc. and that's considered state
of the art!
 
It's all perspective!
 
-Marc- 

Martin, 
Yes, chassis_id / port_id based location tracking is also quite possible, of
course.  And LLDP-MED further tightens this possibility by constraining the
id types presented by underlying LLDP, making it more predictable exactly
what will be presented.  In practical enterprise systems interfacing to
existing infrastructure, use of ELIN is also valid, and equivalent in fact.
But use of ELIN directly would save a look-up step.  LLDP-MED added ELIN
since was a very easy and obvious location type to have available along with
the IETF specified ones.  At the time, specifying ELIN was also in line with
NENA directions for compatibility in N.A.  Since ELIN is really just a
string of digits, it can also be used in lots of other ways too.  Support of
currently deployed N.A. E-911 interfacing is simply an absolutely huge use
case, so why would it not be added??   

-- Peter 

16.11.07 00:36 

  
All I mean is that the ELIN, being a fairly North American and application
specific parameter seems somewhat out of place in a general link layer spec.
As has been noted, it's pretty much a reference (though not an invitation to
a callback as used with HELD) - and probably not even the ELIN the private
switch will use since it needs to consider the dynamics of how many calls
are originating. As such, I would have thought that the switch and port
identity available through standard LLDP (sans MED) would have served the
same purpose. I didn't say it isn't "convenient". 
  
Cheers, 
Martin 

  _____  

Yes, I certainly agree (contrary to Martin's obviously inflammatory and
self-serving comments earlier) that LLDP-MED can make a very good, simple
solution in many situations.  And many of those scenarios need to address
working with traditional E911 systems, hence inclusion of ELIN in LLDP-MED.
For better or worse, interworking with pre-existing ECS systems such as E911
is not a part of ECRIT's mandate, hence is not described in any ECRIT
document, or anywhere in IETF for that matter.     

For a bit more background on this, and how it can play in to the application
level, see also TIA's TSB-146-A which describes several network topologies
and possible solutions to the emergency call location problem, as well as
others pieces of the puzzle.  Note that this document was not intended to
define any particular solution, but to discuss a range of alternatives.
Although recently updated (in March 07) it is also a second revision with
the first dating several years back now (2004 I believe).  Available at: 
 
http://www.tiaonline.org/standards/technology/voip/documents/TSB-146-AFinalf
orPublication.pdf 
(You will likely be asked to fill in some info and press [I agree] button on
the way.)   

Cheers, 
Peter Blatherwick 

12.11.07 11:47 

Another point to add is that when an endpoint moves within the
campus/enterprise, a different ELIN may have to be passed to the PSAP with
the emergency call, depending on the endpoint's location. To figure this out
automatically, getting the right ELIN directly from the local network via
LLDP-MED can be a good solution. 

Benny 

  _____  

Hi Karl,   

- ELIN can also be used for ECS call routing.  If the call gets placed on an
out of district GW, it can be used in PSTN to route to the correct (in
district) PSAP.   

- I don't *think* ELIN is generally used as the callback number.  In
ISDN-based signalling, there is both the ELIN and a callback number.  I
*think* the PSAP side is (or can be) provisioned with callback corresponding
to the ELIN in its dB.  The callback number is typically not an extension,
but a designated responder within the enterprise at that location, e.g. the
security desk.  Perhaps others on the list with direct experience can
comment on this point?   

> ... all extensions with the same ELIN need to be close to one another. 
Yes, all extensions with the same ELIN *will* be physically close together.
But this is not directly related to callback.  It is by definition of what
the ERL is -- it is a small enough region in a building to allow emergency
responders to find someone.   

idea 

Cheers, 
Peter Blatherwick 

12.11.07 04:46 

Hi Karl Heinz,

Cheers
James

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------
[mf2]

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------
[mf2]

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 16 Nov 2007 21:26:18 -0600

Hi Peter,

I have no argument with the concept of the ELIN per se - it makes
perfectly good sense on the public (PS-ALI) side of the network. The
PABX, it seems to me, is quite capable of bridging the LAN concepts to
the emergency network side without pulling the ELIN into the layer 2 on
the LAN side. Nevertheless - my terminology wasn't aimed at anyone in
particular and wasn't intended to cause offence - I withdraw the
characterization and apologize for any offence caused.

Cheers,

Martin

From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, 17 November 2007 3:24 AM
To: Dawson, Martin
Cc: Rodrig, Benny (Benny); ECRIT
Subject: RE: [Ecrit] ELIN

Martin, 
Yes, chassis_id / port_id based location tracking is also quite
possible, of course.  And LLDP-MED further tightens this possibility by
constraining the id types presented by underlying LLDP, making it more
predictable exactly what will be presented.  In practical enterprise
systems interfacing to existing infrastructure, use of ELIN is also
valid, and equivalent in fact.  But use of ELIN directly would save a
look-up step.  LLDP-MED added ELIN since was a very easy and obvious
location type to have available along with the IETF specified ones.  At
the time, specifying ELIN was also in line with NENA directions for
compatibility in N.A.  Since ELIN is really just a string of digits, it
can also be used in lots of other ways too.  Support of currently
deployed N.A. E-911 interfacing is simply an absolutely huge use case,
so why would it not be added??   

To repeat myself, since IETF ECRIT / Geopriv does not have support of
existing PSTN systems in its mandate, I agree use of ELIN likely does
not play in there.  But, that does not make it "half baked", to repeat
your earlier words.  Support of existing systems, deployed in huge
numbers, and highly likely to keep existing for a very long time, just
makes pragmatic sense.   

-- Peter 

16.11.07 00:36 

        To:        <[email-masked]>, "Rodrig, Benny
(Benny)" <[email-masked]> 
        cc:        "ECRIT" <[email-masked]> 
        Subject:        RE: [Ecrit] ELIN

  
Cheers, 
Martin 

 

Cheers, 
Peter Blatherwick 

12.11.07 11:47 

 
 
Benny 

Hi Karl,   

no idea 

Cheers, 
Peter Blatherwick 

12.11.07 04:46 

Hi Karl Heinz,

Cheers
James