Subject: [Speermint] Re: I-D ACTION:draft-lendl-speermint-background-00.txt

From: Otmar Lendl <[email-masked]>
Date: Thu, 19 Apr 2007 22:14:18 +0200

FYI:

On 2007/04/19 00:04, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 	Title		: Background and Assumptions of the Speermint WG
> 	Author(s)	: O. Lendl
> 	Filename	: draft-lendl-speermint-background-00.txt
> 	Pages		: 15
> 	Date		: 2007-4-18
> 	
>    This documents provides background for the Speermint WG.  It is
>    intended to spur discussion about the goals of this WG and tries to
>    provide guidance on what kind of work is needed to facilitate
>    widespread SIP-based peering of telephony networks.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lendl-speermint-background-00.txt

As the abstract states: this draft is supposed to generate some
discussion on the basic assumption regarding the environment in
which the speermint WG operates.

Some of the points are sure to be contentious.

/ol (reaching for the asbestos underwear)
-- 
/ 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 /

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Apr 2007 16:53:10 -0400

"As anybody on the Internet can contact any destination domain, no
       business relationship between sender and destination domain is
       required.  This implies that there is no settlement: No money is
       changing hands because of such a communication."

While no money *needs* to change hands, nothing prevents a callee  
from requesting such funds as a condition of accepting the call (or  
even the caller forwarding the response and completing the call).  
Indeed, extensions such as OSP allow for this type of model, but  
there are many other models.

* Apparently, the real world did not choose to implement and deploy
    SIP and ENUM as initially envisioned by their inventors.  In other
    words: the motivation for Speermint is the failure of the world to
    conform to the original IETF vision of SIP based real-time
    communication. *

It is not clear to me that this is a choice as such, but could at  
least partially be a rational decision due to the small number of  
VoIP customers, compared to the total number of E.164 owners. If only  
10% of call destinations use SIP, a carrier incurs a lot of  
complexity and not much financial gain from direct peering. Thus, it  
doesn't necessarily follow that this is a long-term failure as the  
ratio increases. Direct SIP connectivity among second-tier VoIP  
providers seems at least somewhat common, although primarily based on  
* codes, rather than DNS resolution (which has more to do with the  
current UA GUI issues than protocol or trust problems.)

"is needed between communication partners, thus no termination fees
       can be collected."

This is logical fallacy. Just because a particular thing is not  
needed, it does not follow that it cannot be supported. Nothing  
prevents me from being reachable via 3263 AND charging you to talk to  
me (naturally, assuming some kind of settlement or collection  
mechanism).

"The SIP identity standard (RFC 4474) uses a different approach
       (certificate-based, end-to-end) than what is current practice in
       the telco space (transitive trust)."

This is not true. In many instances, telcos connect directly  
(customer of A talks to customer of B). This is not fundamentally  
different from A (with cert issued by a mutually-trusted CA) calling  
B (with cert). In both telco and SIP cases, A and B assert the  
identity of their customers indirectly, i.e., B needs to trust A that  
it can actually verify the identity of their customers.

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 19 Apr 2007 23:02:43 +0200

Otmar,
 
thanx for this document, it is very useful and raises a lot if isssues.
 
IMO one central point is the following sentence:
 
"In order to place calls, some alternative to RFC 3263 needs to be
   developed which accommodates the needs of carriers."
 
Ok, beside that GSMA is using RFC3263 in IPX DNS,
do you have ANY idea what this alternative could be or look like?
 
Maybe we also have to define first:
1. What the needs of the carriers are
2. What the options (methods) are to support this needs
3. We should also define what a "carrier" is, or better
who is allowed to participate in peering
(I am talking here mainly about enterprises, but also about end-users that are
running a proxy)
So basically we are back (what I said a year ago) to define
the minimum requiriments for a "service provider" to be trusted
and also the minimum requirements for the peering protocol
 
Richard

________________________________

Von: Otmar Lendl [mailto:[email-masked]]
Gesendet: Do 19.04.2007 22:14
An: [email-masked]
Betreff: [Speermint] Re: I-D ACTION:draft-lendl-speermint-background-00.txt

FYI:

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 19 Apr 2007 17:47:50 -0400

Yes, you are right. We are back to the same questions as before.  It
seems something out of Monty Phython's "Meaning of Life". (;-) 

We are still struggling with the definition of a carrier vs. sp vs.
something else. Given this indefinition we are not sure if speermint
applies to carriers, sp, vsp, etc. After we define this somebody will
ask if the requirements are different, the same, and exactly which one
of these players want. Then there is the whole notion of BCP vs.
building something new and it goes on and on.

We are still struggling with the notion of routing to a URI (how, should
we tackle this or not, etc). Do we assume E.164 numbers or only SIP
URIs, how people will charge this or others, etc

IMHO I believe we should take a step back, look at the charter, maybe
decleare some problems "real" but out of the scope for now, try to come
up with a (laundry) list of of things we find missing in the existing
drafts. We can then update/consolidate/what have you and go from there.

Thanks,

Reinaldo

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Thursday, April 19, 2007 2:03 PM
> To: Otmar Lendl; [email-masked]
> Subject: Re: [Speermint] Re: I-D 
> ACTION:draft-lendl-speermint-background-00.txt
> 
> Otmar,
>  
> Ok, beside that GSMA is using RFC3263 in IPX DNS, do you have 
> ANY idea what this alternative could be or look like?
>  
> 2. What the options (methods) are to support this needs 3. We 
> should also define what a "carrier" is, or better who is 
> allowed to participate in peering (I am talking here mainly 
> about enterprises, but also about end-users that are running 
> a proxy) So basically we are back (what I said a year ago) to 
> define the minimum requiriments for a "service provider" to 
> be trusted and also the minimum requirements for the peering protocol
>  
> Richard
> 
> Betreff: [Speermint] Re: I-D 
> ACTION:draft-lendl-speermint-background-00.txt
> 
> 
> 
> 
> FYI:
> 
> As the abstract states: this draft is supposed to generate 
> some discussion on the basic assumption regarding the 
> environment in which the speermint WG operates.
>

---

From: Jan Janak <[email-masked]>
Date: Fri, 20 Apr 2007 13:36:22 +0200

> Section 3.1
>
> The number of SIP users who are reachable via the open Internet using
> RFC 3263 is miniscule when compared to the number of SIP based
> telephones in operation today.

  Pretty much all the ITSPs I have tried  over last couple of years
  would accept INVITE requests coming from the public internet as long
  as it is destined to one of their subscribers. This also means that
  all their subscribers (SIP users) are reachable from the open
  internet.

  From my experience the reachability problem disappears if you use
  a user agent that is capable of "dialing" full SIP URIs.

  Isn't the reachability problem of SIP telephones you mentioned in the
  I-D caused primarily by the lack of ENUM deployment and fragmented
  ENUM trees, rather than the failure of the email model for SIP?

> Email is non-interactive: filters can be deployed to detect spam
> by the content of the mail before the recipient is alerted.  That
> is not possible for SPIT: content is only available after the
> recipient has picked up the phone.  A number of SPIT mitigation
> strategies have been proposed over the last years, their
> effectiveness is yet untested.

  Spammers often use techniques that make content-filtering inefficient
  (such as messages send as picture attachments) and in such cases
  spam filters can only rely on the information from message headers,
  just like in spit. I think that the main difference between spam and
  spit is that ringing phones are much more intrusive than unsolicited
  email messages and that's also probably the reason why ITSPs consider
  deploying draconian measures, such as restricting the reachability of
  subscribers.

      Jan.

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 23 Apr 2007 14:27:19 +0200

> there are many other models.

My argument is about the reasons why the email model failed to catch
on in the carrier-level VoIP world.

What you're proposing here is an addition to the email model, with
adds settlement to the picture in the hope that this is the missing
piece. 

That's fair and could be a good idea, but I wouldn't call the result
the "email-model" any more.  The ominous lack of any real world OSP
deployments maybe a bad sign, though.

Please note that I did not propose a new "Interconnection model" in this
draft: this draft just documents why two existing models (namely email
and pstn) are not suitable.

So yes: please come up with ideas on what changes we need to the
email model in order to make up a workable solution for VSPs.

> complexity and not much financial gain from direct peering. 

That argument is true with respect to peering arrangements. You don't
address the lack of open SIP URIs in the typical PSTN-replacement 
services, though.

> Thus, it doesn't necessarily follow that this is a long-term failure  
> as the ratio increases.                                               

We will see. Up to now I don't see the big VoIP operators (MSOs, Vonage,
UPC, ...) starting to hand out Internet-reachable URIs. 

> Direct SIP connectivity among second-tier VoIP  

The * codes seem to be a US-specific thing, I don't encounter them
with operators in Austria.  I think they are a symptom of not using
E.164 numbers (e.g. the +1 747 numbers sipphone is using) plus the
non-availability of 1.e164.arpa.

> me (naturally, assuming some kind of settlement or collection  

Sorry, I have to return the logical fallacy charge.

Once you have a settlement between parties (however indirect the billing
is), this is per definition a business relationship. Thus, once a VSPs
requires settlement, it requires a business relationship. As stated
above, I don't think this should still be labeled "the email model".

Again, I don't think we're that much in disagreement on the facts,
but only on the terminology. For me, "email model" and "settlement"
just doesn't go together.

> it can actually verify the identity of their customers.

If only two parties are involved, the difference may indeed be
negligible. Once you have a call traversing three networks then the
difference is clear:

Consider A -> B -> C

In the PSTN case, B trusts the callerID from A and thus forwards it to C
which trusts B. C doesn't even know that the call did not originate in
B's network. Thus C has just the option to either trust the callerID it
receives in ISUP messages from B's switches (and thus whomever B trusts)
or not.

In the SIP Identity scenario, unless B re-signs the SIP message, this
is no the case.

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 23 Apr 2007 15:59:30 +0200

> thanx for this document, it is very useful and raises a lot if isssues.

The idea was to condense a lot of mailing list arguments into
one neat document.

> Ok, beside that GSMA is using RFC3263 in IPX DNS,

As far as I know, they aren't. The last time I heard a presentation
on the IPX, there was a lot of talk about "hubs" which are basically
peering aggregators. Pure RFC3263 is thus just for destination networks
with which a direct peering relation has been established.

Which means: RFC3263 is just used in one part of the next hop
determination, and it is not the complete algorithm.

> do you have ANY idea what this alternative could be or look like?

Sure. Based on my experience here it is rather pointless to re-interate
my proposal until we've reached agreement on the requirements.

> Maybe we also have to define first:

Yes. That's what's IMHO really needed. There are actually very simple

> 1. What the needs of the carriers are

* Have full control on with whom he peers.

* This decision can range from
  - open peering (I peer with everybody)
  - manual peering only (I only peer with others I have manually selected)
  - peer with everybody for whom someone I trust vouches for
  - peer with everybody who agrees to my settlement terms
  - peer with everybody who qualifies according to some technical criteria
  - peer with everybody I'm legally required to do
  - peer with everybody who can provide sufficient ranking in a specific distributed 
    reputation system
  - peer with everybody who is using some certified hard/software for peering
  - peer over private infrastructures
  - peer only using some sort of mediated peering arrangement

  Any combination of these criteria must be possible.

* Must support both E.164 and URI-based calls

* As automatic as possible.

In other words: whatever criteria the lawyers/CFOs/CEOs/Techies of a VSP
can come up with, the protocol must support in a unified way.

> 2. What the options (methods) are to support this needs

hm?

> (I am talking here mainly about enterprises, but also about end-users that are

There is absolutely no need to define this. In practice, a commercial
VSP will just make different choices regarding with whom he will peer
as compared to an enterprise VoIP installation.

The BGP protocol doesn't a have a variant for Tier-0 networks and one
for multi-homed enterprises. These terms are irrelevant to the protocol.

We MUST strive for the same: The same toolbox must be good enough
for everybody, regardless of what label some want to put on them.

Never ever should the IETF define who is "allowed to participate in
peering".  That decision MUST reside only with the potential peering
partners.  

Example: If Global Crossing wants to peer with my private Asterisk PBX
which just hosts my phone at home plus the softphone on my laptop, then
good for them (and for me). If two VSPs peer with each other it should
just be because these two AGREE to peer with each other.

As it is likely that not everybody will talk to everybody else, there
will be transit operators. This is just something we have to allow for
in the protocol. *Who* will play that role is not something the IETF is
supposed to solve. If that is a viable business, then someone will fill
the role. If everybody else suddenly converts to direct peering, then
this business model will cease to be viable. So what? I can hardly find
a topic with should be of less concern to the IETF.

> and also the minimum requirements for the peering protocol

I think this is the wrong approach. The question of whom a VSP
trusts enough to peer with him, is solely in the purview of
that VSP.

The only topic the IETF can solve is the technical protocol with
which VSPs can

* learn who the destination VSP is
* learn more about that VSP to determine whether the peering
  requirements of that destination VSP allows for a direct call.

We really *really* must make sure that the IETF defines only the
machinery which control the peering decision. The control-levers of said
machinery MUST firmly stay in the hands of the organization running this
network.

Everything else is doomed to fail.

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 23 Apr 2007 16:27:40 +0200

>   all their subscribers (SIP users) are reachable from the open

Yes, your average "let's take ser, a cisco media gateway and let's
play ITSP" service will have open URIs.

I really doubt that the majority of SIP users are using such
services. Where are the numbers really?

* PBXs

  Most new PBX deployments are VoIP based these days (though
  usually not SIP). When we shopped around for one recently,
  we had troubles finding any vendor whose product was designed
  to do SIP on the open Internet. We got mostly blank stares.

* Cable networks

  These guys go for triple-play (TV, Internet, Telephony) in a 
  huge way. Those are the companies who sign up more users
  in a month than what all the second-tier services have in total.

* Alternative carriers using a NGN style device.

  Often the user isn't even told that his IAD contains a SIP ATA,
  let alone a SIP URI.

>   ENUM trees, rather than the failure of the email model for SIP?

The lack of ENUM certainly doesn't help. 

Consider e.g. the Netherlands: I find quotes like "IP telephony
services now account for around 30% of the Dutch voice market."
For all I know, UPC Netherlands, Casema, MultiKabel, Essent and CaiW
account for most of these users. I haven't seen any published
way of calling their users via SIP. Have you?

>   deploying draconian measures, such as restricting the reachability of

Agreed. That's why solving the SPAM/SPIT problem is even more important
with VoIP than with email.

/ol