RE: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne -sipping-emergency-req-00

["Peterson, Jon" <[e-mail]>]

Heh, right. I've been considering the 'last mile' chunk to be between the
end user (currently, their POTS phone - in the future, their IP phone) and
the selection router - that's how I thought we were using the term in our
conf call, and hence my confusion (I was contrasting the terms 'last mile'
with 'trunking replacement' on the call). The use of the term 'access' in
the title of section 4 made me think you were describing the access portion
of the network (i.e. copper to the home, etc). Your suggestion in the intro
to the section that the transport could be analog or ISDN but might be
replaced with DSL certainly supported that reading. I thought the term
'trunking' was used casually there.

I guess looking more closely at that section, requirement M-7 and a few
others might have tipped me off that these requirements were about the
trunking replacement. The definition in section 3 of 'last mile emergency
service' also is a pretty good indicator. I don't know if this would have
been unclear to someone who hadn't been on our conference call. I imagine
that paraphrasing the definition of 'last mile' from section 3 in the intro
to section 4 would clear up any conceivable ambiguity. I also would avoid
using the term 'access' in the title of section 4.

>From my perspective anyway, what I'm concerned about is that the full e2e
solution be bundled separately from the more immediately achievable work.
Whether or not these two are in separate sections is less material to me,
but ultimately, we know that the section 4 solution is not depending on
geopriv, but the later material is. I think there is value in having the
section 4 work go forward on its own merits, and fully specifying this
solution - I know you think this is trivial, but to me, trivial means
achievable. :) Putting the later e2e work in a separate document would
remove any geopriv dependencies for the section 4 work.

- J

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[e-mail]]
> Sent: Tuesday, February 25, 2003 7:06 AM
> To: King, Kimberly S.
> Cc: Peterson, Jon; [e-mail]
> Subject: Re: [Sipping-emergency] Re: [Sipping-emergency]
> draft-schulzrinne-sipping-emergency-req-00
> 
> 
> Maybe we're getting closer to the source of the confusion... 
> During the 
> teleconference, I had associated 'last-mile' with the 
> recently-completed 
> NENA effort, which only deals with what section 4 describes. 
> Since it's 
> the last mile before reaching the PSAP/ECC, I used that term. Maybe 
> others were thinking of what I'd consider 'first-mile', i.e., from a 
> VoIP phone to a PSTN gateway?
> 
> That might explain a few of the rounds of discussion... Jon, Allison: 
> where's first and last? :-)
> 
> King, Kimberly S. wrote:
> > Henning,
> > 
> > 
> >>"In last-mile access, an ECC replaces an analog (CAMA) or 
> >>digital (ISDN) 
> >>trunk with packet-based access,
> >>typically over one or more high-speed access lines such as DSL 
> >>or leased 
> >>lines."
> >>
> >>Suggestions on how to make this clearer are welcome.
> > 
> > 
> > 
> > I believe it isn't as clear because it disorients the 
> reader.  The last mile
> > (reader is thinking from the perspective of being the client) has
> > packet-based access (access puts the reader in the 
> perspective of being on
> > the "server" side).
> > 
> > I can't completely re-word it as I'm not totally clear what 
> you are trying
> > to say but I'll take a shot at it.
> > 
> > "In the last mile situation, instead of calls being 
> terminated by analog
> > (CAMA) or digital (ISDN) trunks, they are terminated by 
> high-speed DSL or
> > leased line packet-based solutions."  
> > 
> > Kimberly
> 
_______________________________________________
Sipping-emergency mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-emergency