Subject: RE: [Speermint] Requirement(s) for call routing addressingdatavariability (was: RE: [Speermint] Basic Peering Requirements)

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 19 Oct 2006 11:01:38 -0400

The term "acquisition" seems strange.

ENUM translates an E.164 into a domain name from which a URI mapping can
be retrieved.  That URI determines what protocol and addressing
information may then be used by Speermint to target peering points and
complete the communications.  In many cases, these will be SIP URIs
leading to completion of calls via SIP-based mechanisms.

Mike

> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]] 
> Sent: Wednesday, October 18, 2006 6:08 PM
> To: Uzelac, Adam; [email-masked]
> Subject: RE: [Speermint] Requirement(s) for call routing 
> addressingdatavariability (was: RE: [Speermint] Basic Peering 
> Requirements)
> 
> Adam wrote:
> > Jean-Francois - well done shifting through all the noise to 
> get at the 
> > key requirements across 3 different voices!
> > Couple comments:
> >  - I need to ask why you think the LF function is out of 
> scope?  Are 
> > you thinking that it's out of scope for speermint, but in scope for 
> > ENUM/DNS?
> 
> It is based on draft-ietf-speermint-terminology-06.txt, page 
> 4, figure 1 as well as the following text:
> " he ENUM Working Group is primarily
>    concerned with the acquisition of Call Addressing Data, or 
> CAD, while
>    the SPEERMINT Working Group is focused on the use of such CAD in
>    routing session signaling requests."
> 
> 
> >  - I also think the comment about how call addressing data 
> is acquired 
> > is via user input - regardless if it is E.164 or an URI.  It's not 
> > really an issue as the session has to start somewhere with 
> something.
> Agreed.
> 
> > It's the resolving of the data input that needs the 
> attention both in 
> > speermint/ENUM/DNS/SIP/etc.
> > 
> > Otmar - requirements for the routing decisions Daryl - Operators 
> > maintaining control of how sessions ingress to them Brian - 
> specific 
> > list of proxy server domain names between peers
> > 
> > None of these, from what I can glean, have anything to do 
> with how the 
> > data is acquired - only the resolution once data is available.
> > 
> > -AU
> 
> Jean-Francois.
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 

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