Subject: [Speermint] Some general comments...

From: David Schwartz <[email-masked]>
Date: Tue, 4 Dec 2007 00:22:21 -0800

Hi Folks

Following yesterdays session a bunch of us sat down to try and close  
probably the assisted/indirect ambiguity. In the discussions it  
became apparent that underpinning this ambiguity is the general  
question of scope in SPEERMINT.

If we look at the WG page we see the following... "The SPEERMINT work  
plan is related to and distinct from the work plans of the ENUM and  
SIPPING working groups. While the the ENUM Working Group is primarily  
concerned with the structure and lookup of data for the translation  
of E.164 numbers into URIs (RFC3761), SPEERMINT is concerned with the  
use of the resulting URI data, as well as non-ENUM-derived URI data,  
for use in signaling and routing of real-time sessions."

The terminology draft follows this line and reads (on Page 4)... " As  
illustrated in Figure 1, the ENUM Working Group is primarily  
concerned with the acquisition of SED while the SPEERMINT Working  
Group is focused on the use of such SED in routing session signaling  
requests"

What emerges is that "the structure and lookup of data" [WG-PAGE] or  
"the acquisition of SED" [TERM] are out of scope but the "use of the  
resulting URI data" [WG-PAGE] or "The use of such SED" [TERM] are in  
scope. What exactly does "the use of the resulting URI data" mean?  
Don't we all agree that SED constitutes a routable SIP URI? isn't  
that just plain SIP at this point? You have a routable URI - you use  
it. you follow 3261 and send it on its merry way.

To me, SPEERMINT is all about GETTING the routable URI - yes - the  
acquisition of SED. Not which protocol I use - that is for ENUM and  
SIP but the process, architecture, semantics, data models, associated  
policy, discovery, etc.

What am I missing?

D.

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

---

From: "Jeremy Barkan \(DigitalShtick\)" <[email-masked]>
Date: Tue, 4 Dec 2007 11:41:40 +0200

Forwarding on behalf of David Schwartz

From: David Schwartz <[email-masked]>
Date: December 4, 2007 1:05:44 AM PST (CA)
To: [email-masked]
Subject: Assisted/Transit

Hi

In our post session meeting there was alot of discussion about the
persistent ambiguity in the documents regarding this divide. Expanding on
the orthogonality of the assisted peering function it became apparent that
the assistance comprises the resolution step (i.e. the lookup function and
the location function) or in other words the process of taking a potentially
non routable identifier (e.164 OR AOR) and converting it (possibly applying
some policy) to a routable URI. This "resolution" step when performed
remotely gains the title "assisted". At this point some of the participants
felt that if this is so than the term "peering" as associated with
"assisted" is misleading for there is no peering per-say that traverses the
assisted peer as in the case of transit or direct peers. Some alternatives
were proposed with the main options being...

1. just include LUF and LF and in the architecture draft introduce a term
(e.g. Resolution Function) that aggregates the two
2. Include a "Resolution Function" in the terminology draft to reduce
ambiguity
3. Leave Assisted with the additional clarification that it encompasses only
the LUF and LF

We are planning on sitting again on Wednesday afternoon (Vancouver time) to
continue discussion on these points so please provide any feedback by then.

Thanks,

D.

-----Original Message-----
From: David Schwartz [mailto:[email-masked]] 
Sent: Tuesday, December 04, 2007 10:22 AM
To: [email-masked]
Subject: [Speermint] Some general comments...

Hi Folks

What am I missing?

D.

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 4 Dec 2007 13:04:29 +0100

On 2007/12/04 09:12, David Schwartz <[email-masked]> wrote:
> probably the assisted/indirect ambiguity. 

That's what the IETF meetings are for.

[reordered]

> Group is focused on the use of such SED in routing session signaling  

This changed in the last revision based on various feedback. The 
version Daryl sent to the reviewers contains:

  As illustrated in Figure 1, the ENUM Working Group is primarily
  concerned with identifying a SIP URI that corresponds to a given
  E.164 number, while the SPEERMINT Working Group is concerned with
  using that SIP URI to acquire the SED and on the use of such SED in
  routing session signaling requests. Importantly, the SIP URI can
  be derived from ENUM (i.e., an E.164 DNS entry) or via any other
  mechanism available to the user.

Which make IMHO a lot more sense.

==================================

Generally speaking, one of the problems here is the fact that "SIP
URI" is an overloaded term. I've been bitching about this often
enough in my comments on the list and in one of my drafts. (e.g.
http://www.enum.at/ietf/draft-lendl-speermint-background-00.html#URI )

We really, *really* have to distinguish between a SIP Address of Record
(AoR) which is the nice address you print on your business card and the
trivially routable SIP URI.

In the perfect end-to-end world, RFC 3263 can be used to directly map
the AoR to the next hop SIP proxy.

In the speermint context, this just isn't true. I'd even venture to say
that this is the main reason for the existance of speermint.

> for use in signaling and routing of real-time sessions."

IMHO, the input into the speermint algorithm is always an AoR.

The AoR is a "name". It defines who you want to reach, e.g.
"sip:[email-masked]". It's the same string regardless whom you give
your business card to. Same for public ENUM: You don't know who will
query your public DNS, so you can't tailor your answer to the querier.
Thus the (public) ENUM step must return an AoR, and can't answer with
a SIP URI which indicates a specific ingress point. (unless that's your
one and only ingress point)

The "URIs" quoted above are thus all AoRs. Maybe we should use different
terms for the various kinds of SIP URIs. 

Daryl? Are you game for some more revisions? We're still not at -58.

> it. you follow 3261 and send it on its merry way.

Agreed. I think with the update to the terminology draft it all
makes a lot more sense.

> SIP but the process, architecture, semantics, data models, associated  

The trouble relying with ENUM for SED acquisition is that it's based on
telephone numbers, whereas speermint also needs to cope with non-number
based calling. Thus if we base all the tricky egress-ingress selection,
peer-discovery, transit selection and capacity planning on ENUM (and
thus numbers), then we fail to solve the problem for SIP-AoR based calling.

Have a nice and productive week in Vancouver!

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg

---

From: "Michael Hammer (mhammer)" <[email-masked]>
Date: Tue, 4 Dec 2007 09:33:02 -0500

David,

At a high level, the answer to your question is whether the "call
routing" is done via redirecting a SIP request hop by hop through many
SP networks and their proxies to the terminating network and terminating
end-user, or whether it is done by redirecting ENUM queries through a
sequence of registries until the originating VoIP SP serving the caller
can connect as directly as possible to the terminating VoIP SP serving
the called user.

In short, route through SP's/proxies or route through databases.  I
would contend that the latter is much more efficient and the reason for
SPEERMINT.  Minimize the middlemen.

The use of registries also allows the application of some control over
who learns what ingress to go through, as well as some load balancing
and perhaps congestion control and perhaps some SPIT control.

Mike

> Sent: Tuesday, December 04, 2007 3:22 AM
> To: [email-masked]
> Following yesterdays session a bunch of us sat down to try 
> and close probably the assisted/indirect ambiguity. In the 
> discussions it became apparent that underpinning this 
> ambiguity is the general question of scope in SPEERMINT.
> 
> If we look at the WG page we see the following... "The 
> SPEERMINT work plan is related to and distinct from the work 
> plans of the ENUM and SIPPING working groups. While the the 
> ENUM Working Group is primarily concerned with the structure 
> and lookup of data for the translation of E.164 numbers into 
> URIs (RFC3761), SPEERMINT is concerned with the use of the 
> resulting URI data, as well as non-ENUM-derived URI data, for 
> use in signaling and routing of real-time sessions."
> 
> The terminology draft follows this line and reads (on Page 
> 4)... " As illustrated in Figure 1, the ENUM Working Group is 
> primarily concerned with the acquisition of SED while the 
> SPEERMINT Working Group is focused on the use of such SED in 
> routing session signaling requests"
> 
> What emerges is that "the structure and lookup of data" 
> [WG-PAGE] or "the acquisition of SED" [TERM] are out of scope 
> but the "use of the resulting URI data" [WG-PAGE] or "The use 
> of such SED" [TERM] are in scope. What exactly does "the use 
> of the resulting URI data" mean?  
> Don't we all agree that SED constitutes a routable SIP URI? 
> isn't that just plain SIP at this point? You have a routable 
> URI - you use it. you follow 3261 and send it on its merry way.
> 
> To me, SPEERMINT is all about GETTING the routable URI - yes 
> - the acquisition of SED. Not which protocol I use - that is 
> for ENUM and SIP but the process, architecture, semantics, 
> data models, associated policy, discovery, etc.
> 
> What am I missing?
> 
> D.
> 
>

---

From: Richard Stastny <[email-masked]>
Date: Tue, 04 Dec 2007 17:35:48 +0100

> thus numbers), then we fail to solve the problem for SIP-AoR based calling.

Amen

ENUM is for resolving E.164 numbers to AoRs
RFC3263 and/or SPEERMINT is for resolving AoRs to ingress points

One could use private ENUM to resolve to ingress points directly,
but even GSMA is currently not going down this path,
because:
RFC3263 and/or SPEERMINT must be able to work with AoRs directly also

This is what I said one year ago

Richard

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Tue, 04 Dec 2007 18:01:40 +0000

David,

Personally I think the problem is the notion that we're constrained to a
BCP.  Anything non-trivial that this group might do would go beyond a
BCP as I understand that term.

Setting that aside for the moment, I would agree that we care about as
you say, "getting" the data (SED).  I would add that we care also about
the semantics of the data - what does it represent?  Perhaps that's the
same thing as you mean by referring to data models.

Tim

<snip>

---

From: Daryl Malas <[email-masked]>
Date: Wed, 05 Dec 2007 12:12:50 -0700

Comment in-line...

> Which make IMHO a lot more sense.

Grrr....I'm not sure I believe it makes that much of a difference.  I
think the more important thing is that it reads clearly (meaning clarity
of context...not grammatical bliss ;-)).

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 06 Dec 2007 23:12:29 +0000

We must not make any assumption about a SIP URI being an AoR. In many
cases it will be - in many cases it won't be. In a mid-dialog request it
will be a contact URI. In an INVITE request that arises from a REFER
request it is likely to be a contact URI.

John 

> From: Daryl Malas [mailto:[email-masked]] 
> Sent: 05 December 2007 19:13
> To: Otmar Lendl
> Cc: [email-masked]
> Subject: Re: [Speermint] Some general comments...
> 
> Comment in-line...
> 
> SPEERMINT work

---

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 11 Dec 2007 05:18:47 -0500

It seems the discussion died down. This is important to allow us poor
editors to update the drafts. Are we having a LUF and LF function in the
terminology draft? Should I include them in the architecture? Are we
having a resolution function which is composed of both? ....

Thanks,

Reinaldo 

> Sent: Wednesday, December 05, 2007 11:13 AM
> To: Otmar Lendl
> Cc: [email-masked]
> > > The terminology draft follows this line and reads (on 
> Page 4)... " 
> > URI" is an overloaded term. I've been bitching about this 
> often enough 
> > in my comments on the list and in one of my drafts. (e.g.
> > 
> > (AoR) which is the nice address you print on your business card and 
> > the trivially routable SIP URI.
> > 
> > In the speermint context, this just isn't true. I'd even venture to 
> > say that this is the main reason for the existance of speermint.
> > 
> > > If we look at the WG page we see the following... "The SPEERMINT 
> > > work plan is related to and distinct from the work plans 
> of the ENUM 
> > > and SIPPING working groups. While the the ENUM Working Group is 
> > > primarily concerned with the structure and lookup of data for the 
> > > translation of E.164 numbers into URIs (RFC3761), SPEERMINT is 
> > > concerned with the use of the resulting URI data, as well as 
> > > non-ENUM-derived URI data, for use in signaling and 
> routing of real-time sessions."
> > 
> > a SIP URI which indicates a specific ingress point. (unless that's 
> > your one and only ingress point)
> > 
> > The "URIs" quoted above are thus all AoRs. Maybe we should use 
> > different terms for the various kinds of SIP URIs.
> > 
> Grrr....I'm not sure I believe it makes that much of a 
> difference.  I think the more important thing is that it 
> reads clearly (meaning clarity of context...not grammatical 
> bliss ;-)).
> > 
> > Agreed. I think with the update to the terminology draft it 
> all makes 
> > a lot more sense.
> > 
> > > SIP but the process, architecture, semantics, data models, 
> > > associated policy, discovery, etc.
> > 
> > The trouble relying with ENUM for SED acquisition is that 
> it's based 
> > on telephone numbers, whereas speermint also needs to cope with 
> > non-number based calling. Thus if we base all the tricky 
> > egress-ingress selection, peer-discovery, transit selection and 
> > capacity planning on ENUM (and thus numbers), then we fail 
> to solve the problem for SIP-AoR based calling.
> > 
> > // Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 // 
> > nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // 
> > http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg
> >

---

From: David Schwartz <[email-masked]>
Date: Tue, 11 Dec 2007 12:47:29 +0200

Yes

The only term removed was "assisted peering"

D.

On Dec 11, 2007, at 12:18 PM, "Reinaldo Penno" <[email-masked]>  
wrote:

> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

---

From: Daryl Malas <[email-masked]>
Date: Tue, 11 Dec 2007 12:03:33 -0700

I concur.

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 14 Dec 2007 13:46:26 +0100

> BCP as I understand that term.

That's my understanding as well.

The current IETF protocol set makes certain assumptions regarding the
overall interconnection/peering/connectivity layout which are not
true in the carrier VoIP interconnection space.

Current implementations use these protocols within private walled
gardens where those assumptions more or less hold. That kind of works
out for calls which stay inside these gardens. Any BCP speermint can
come up with will thus only work within such walled gardens.

In order to solve the overall VoIP interconnection / call routing
problem, we'd need to look beyond individual peering islands.

That, while IMHO very much needed, is definitely no longer a simple BCP issue.

I consider it foolish to spend so much time on optimizing the
intra-federation peering mechanics while the overall call routing
architecture is completely undefined. 

This is tending and beautifying walled gardens before you even know
what the layout of the arches and paths connecting your gardens will
look like. Perhaps lovely in the short term, but a waste of time and
a recipe for long term inefficiencies.

I thus think we're on the road to irrelevance unless we change our charter.

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 14 Dec 2007 13:51:26 +0100

> having a resolution function which is composed of both? ....

Well, _you're_ doing the architecture. It should be your design which
defines whether we need these two terms or not. There is no point in
adding boxes to your architecture document just because we have defined
some terms.

/ol

---

From: Daryl Malas <[email-masked]>
Date: Fri, 14 Dec 2007 14:35:56 -0700

IMO, I think it is necessary to describe both architectures within
SPEERMINT.  One architecture, which can be adopted as a walled garden
scenario.  This will allow an implementable and realistic version for
today's peering scenarios.  A second architecture, which assumes an open
version that the content (telephoney, video, etc.) industry can,
potentially, move towards over time.

I simply do not believe it will occur in the next 10 years, but it will
likely become more open over time.  If we define the basic requirements
and architecture to achieve both, I think we succeed in SPEERMINT.

Keep this in mind, some early proposals made some assumptions of an
"open" architecture (e.g. policy exchange, etc), and the WG chairs (and
AD's, I believe) suggested we focus on a more realistic (currently)
version of peering and then write drafts over time to better define
attributes of the open architecture.

IMO, too often, we have a tendency to want to "boil the ocean", instead
of developing something to create building blocks for the industry today
and tomorrow.  Tomorrow may seem a little ambiguous today; but, over
time, it will become clearer as the adoption of peering evolves and
requirements become more and more obvious.

--Daryl

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Dec 2007 16:58:46 -0500

Michael - when you say "redirecting" a SIP or ENUM request, do you mean proxying/forwarding, or do you literally mean a SIP 3xx redirection (or iterative ENUM) model?

The latter won't work, for a variety of reasons.  But I assume you mean the former: whether call routing should be done by SIP proxying or recursive ENUM.  A recursive ENUM model won't cover all, IMO.  Within a registry federation it will be useful, because each SSP may well have direct SIP connection to each other (ie, a full mesh), and thus a recursive ENUM query can tell the originating SSP the right ingress SBE for the terminating SSP.  The problem, of course, is not all SSPs have connectivity to all SSPs, and ENUM has no topological view of the relationships and equipment that exist in between.

In other words even if we can figure out how to get SSP2's subscriber data to be "seen" by SSP1, so that SSP1 can do an ENUM dip and get back SSP2's subscriber AoR or ingress point, it has nothing to do with whether SSP1 can actually reach SSP2 at a SIP layer, or what transit SSPs (and SBEs) it has to traverse to do so.  I guess we'll see whether that particular aspect will be covered by PEPPERMINT. :)

-hadriel

> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Tuesday, December 04, 2007 9:33 AM
> To: David Schwartz; [email-masked]
> Subject: RE: [Speermint] Some general comments...
>
> David,
>

---

From: "Michael Hammer (mhammer)" <[email-masked]>
Date: Mon, 17 Dec 2007 12:28:52 -0500

Hadriel,

If the topological and relationship information is not available within
ENUM and DNS, it is not because it can not be done, but because we
haven't gotten busy and defined those parameters to be there yet.  Of
course, it requires the data to be provisioned with the right values in
a registry that is visible.  But, that is more a business problem than a
technical one.

Mike

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Friday, December 14, 2007 4:59 PM
> To: Michael Hammer (mhammer); David Schwartz; [email-masked]
> Michael - when you say "redirecting" a SIP or ENUM request, 
> do you mean proxying/forwarding, or do you literally mean a 
> SIP 3xx redirection (or iterative ENUM) model?
> 
> The latter won't work, for a variety of reasons.  But I 
> assume you mean the former: whether call routing should be 
> done by SIP proxying or recursive ENUM.  A recursive ENUM 
> model won't cover all, IMO.  Within a registry federation it 
> will be useful, because each SSP may well have direct SIP 
> connection to each other (ie, a full mesh), and thus a 
> recursive ENUM query can tell the originating SSP the right 
> ingress SBE for the terminating SSP.  The problem, of course, 
> is not all SSPs have connectivity to all SSPs, and ENUM has 
> no topological view of the relationships and equipment that 
> exist in between.
> 
> In other words even if we can figure out how to get SSP2's 
> subscriber data to be "seen" by SSP1, so that SSP1 can do an 
> ENUM dip and get back SSP2's subscriber AoR or ingress point, 
> it has nothing to do with whether SSP1 can actually reach 
> SSP2 at a SIP layer, or what transit SSPs (and SBEs) it has 
> to traverse to do so.  I guess we'll see whether that 
> particular aspect will be covered by PEPPERMINT. :)
> 
> -hadriel
> 
> > SP networks and their proxies to the terminating network and 
> > terminating end-user, or whether it is done by redirecting ENUM 
> > queries through a sequence of registries until the 
> originating VoIP SP 
> > serving the caller can connect as directly as possible to the 
> > terminating VoIP SP serving the called user.
> >
> > would contend that the latter is much more efficient and the reason 
> > for SPEERMINT.  Minimize the middlemen.
> >

---

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 17 Dec 2007 15:55:06 -0500

Actually, I'm not doing the architecture as you imply, the IETF is. I'm
one of the co-author and editor but follow IETF guidelines on putting
the document together. If you think something is not right with the
document, please point out and/or suggest text so we can get consensus.

Your previous comments to the doc were put before the WG in the last
meeting in case you do not know.

Thanks,

Reinaldo

> From: Otmar Lendl [mailto:[email-masked]] 
> Sent: Friday, December 14, 2007 4:51 AM
> To: [email-masked]
> > editors to update the drafts. Are we having a LUF and LF 
> function in 
> > the terminology draft? Should I include them in the 
> architecture? Are 
> > we having a resolution function which is composed of both? ....
> 
> Well, _you're_ doing the architecture. It should be your 
> design which defines whether we need these two terms or not. 
> There is no point in adding boxes to your architecture 
> document just because we have defined some terms.
> 
> /ol
> --
> // Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 
> 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft 
> m.b.H // http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg
>