Subject: Re: [Speermint] Re-making or Un-making the PSTN

From: Sukanta ganguly <[email-masked]>
Date: Mon, 16 Apr 2007 16:03:18 -0700 (PDT)

Henry,
   "Internet-minded" peering can work as aon overlay, not to the extent of violating the internal policies. So in essence, it still needs to co-exist with the end-point peering resolution policies. What I was getting as was the fact that it was no different from any peer-to-peer discovery and the fact that the advertiser needs to have control over how he/she can be discovered. This is how we did in the DNS world. Ofcourse, corporations came along with m-n mappings so that users information can be hidden inside corp databases and then we had the NAT folks who build a logical manner to handle this mappings.
   So I am not sure we are getting to the right mode of understanding the problem here. I think we need to qualify the peering topic a little more so that a clear understanding.

Thanks
SG

----- Original Message ----
From: Henry Sinnreich <[email-masked]>
To: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>; "Uzelac, Adam" <[email-masked]>; Sukanta ganguly <[email-masked]>; [email-masked]
Sent: Monday, April 16, 2007 3:15:14 PM
Subject: RE: [Speermint] Re-making or Un-making the PSTN

Penn Pfautz wrote?

>Pure user-to-user calls either aren't an issue or are dealt with in the
>P2P SIP discussions. Do folks disagree?

As pointed out by Medhavi Bhatia, peering issues exist as well when
users are in different P2P networks.

We can only hope that peering between overlays would avoid some of the
issues discussed here, such as policies, QoS, public/private ENUM, etc.,
in short all the constraints inherited from the PSTN mindset and just
focus on security, spam, etc. In short: Internet-minded peering.

The work reported here on IM peering is a good start IMHO since it shows
the huge traffic issues just for IM. The reported IM systems can also do
voice and video :-)

Internet-minded peering will require some work however and the present
exercise may be a useful experience (what to avoid), if we learn from
it.

Thanks, Henry

-----Original Message-----
From: PFAUTZ, PENN L, ATTCORP [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 12:03 PM
To: Uzelac, Adam; Sukanta ganguly; [email-masked]
Subject: RE: [Speermint] Re-making or Un-making the PSTN

I thought, however, that the point of Speermint *was* to deal with
peering between service providers.
Pure user-to-user calls either aren't an issue or are dealt with in the
P2P SIP discussions. Do folks disagree? 
Quoting from the charter:
"The most focused deliverables of SPEERMINT are best current practices
regarding exchange of real-time sessions among VoIP and other
real-time application service providers and, in particular, how
such calls are routed."

Did I fall off the wagon somewhere?

Penn Pfautz
AT&T Global Access Management
+1-732-420-4962

-----Original Message-----
From: Uzelac, Adam [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 11:48 AM
To: Sukanta ganguly; [email-masked]
Subject: RE: [Speermint] Re-making or Un-making the PSTN

The point that I am trying to make is that the SIP Peering models being
drawn up here rely too much on the SP representing Bob.  Bob should be
able to represent himself and how the world can reach him without the
help of a service provider.  There are numerous and well documented
reasons that Bill might want a SP to represent him, for services like
authentication, anti-SPIT, etc - but Bill should have another option.
Speermint is gaining more and more of a PSTN coloring in it's attempt to
create universal connectivity by NOT using the PSTN.  There's some irony
in that.

-AU 

> -----Original Message-----
> From: Sukanta ganguly [mailto:[email-masked]] 
> Sent: Friday, April 13, 2007 10:01 PM
> To: Uzelac, Adam; [email-masked]
> Subject: Re: [Speermint] Re-making or Un-making the PSTN
> 
> Adam,
>    I am not sure I follow your complication. The fact that 
> there are two federation of Bob's uri (according to your 
> example) should provide Alice a way to find Bob's uri. Are 
> you concerned about Alice's discovery of Bob's uri? The 
> border element will do that. In that manner it is no 
> different than a classical IP route discovery with a router. 
> If no deterministic way of finding out the uri ownership can 
> be concluded then the next hop makes this attempt. That is 
> the most logical way of doing unless their is uniform and 
> well understood global master. This happens to be how PSTN 
> does it and hence no difference.
> 
> 
> SG
> 
> ----- Original Message ----
> From: "Uzelac, Adam" <[email-masked]>
> To: [email-masked]
> Sent: Friday, April 13, 2007 1:18:44 PM
> Subject: [Speermint] Re-making or Un-making the PSTN
> 
> 
> As I sit here working on the VoIP use-case draft, I can't 
> help but thinking if we aren't just re-making the PSTN, 
> instead of un-making it.
> The crux of this issue lies with the routing.  At some of the 
> basic constructs of next-hop routing decisions that border 
> elements need to do, these use-cases are starting to smell 
> more and more like PSTN-based routing look-ups.  A simple 
> determination of who owns the SIP-URI of the intended 
> recipient can not be determined definitively, so it's just 
> punted off to the next chain in the link.  The ultimate 
> end-point determination needs to occur before the next-hop 
> decision can be made.
> If we then consider B2BUAs in the mix, it's more likely than 
> not that the original calling and called parties are changed. 
>  I realize some of this changes due to local policy, but that 
> still doesn't get to the root of the problem.
> 
> For instance, say there were 2 federations where Bob 
> registered his SIP-URI, so that according to members of both 
> federation, to reach bob sessions should be targeted to 
> [email-masked].  Now if Alice is part of a an external 
> domain to those federations, and with both feds "advertising" 
> reachablity to Bob, how does Alice determine next-hop?
> Basically, who owns Bob's uri?  
> 
> If we were to bring ENUM into the discussion, it even get's 
> worse more wrought with concern due to starting with 
> regulated e164.  I just sharing out some thoughts.
> 
> -AU
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection 
> around http://mail.yahoo.com 
> 

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

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

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 16 Apr 2007 17:02:27 -0700

> I think we need to qualify the peering topic a little more so that a
clear understanding.

I agree and the best starting point would be some application scenarios
for P2P overlay operators, if they agree to share their product view in
the IETF. 

This may not happen any time soon however, for similar reasons as in
VoIP: Policies are not gladly shared between competitors. 

Competition was invoked as one of the reasons why 'best effort' is the
only reasonable policy on the Internet.

It will be interesting to see the extent of peering beyond best effort
that will actually be deployed, except in closed federations that could
be exposed to law suits of various types...

Thanks, Henry

________________________________

From: Sukanta ganguly [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 4:03 PM
To: Henry Sinnreich; PFAUTZ, PENN L, ATTCORP; Uzelac, Adam;
[email-masked]
Subject: Re: [Speermint] Re-making or Un-making the PSTN

Henry,

   "Internet-minded" peering can work as aon overlay, not to the extent
of violating the internal policies. So in essence, it still needs to
co-exist with the end-point peering resolution policies. What I was
getting as was the fact that it was no different from any peer-to-peer
discovery and the fact that the advertiser needs to have control over
how he/she can be discovered. This is how we did in the DNS world.
Ofcourse, corporations came along with m-n mappings so that users
information can be hidden inside corp databases and then we had the NAT
folks who build a logical manner to handle this mappings.

   So I am not sure we are getting to the right mode of understanding
the problem here. I think we need to qualify the peering topic a little
more so that a clear understanding.

Thanks

SG

----- Original Message ----
From: Henry Sinnreich <[email-masked]>
To: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>; "Uzelac, Adam"
<[email-masked]>; Sukanta ganguly <[email-masked]>;
[email-masked]
Sent: Monday, April 16, 2007 3:15:14 PM
Subject: RE: [Speermint] Re-making or Un-making the PSTN

Penn Pfautz wrote?

Thanks, Henry

-----Original Message-----
From: PFAUTZ, PENN L, ATTCORP [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 12:03 PM
To: Uzelac, Adam; Sukanta ganguly; [email-masked]
Subject: RE: [Speermint] Re-making or Un-making the PSTN

Penn Pfautz

-----Original Message-----
From: Uzelac, Adam [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 11:48 AM
To: Sukanta ganguly; [email-masked]
Subject: RE: [Speermint] Re-making or Un-making the PSTN

-AU 

> around http://mail.yahoo.com <http://mail.yahoo.com/>  
> 

 

________________________________

Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos.
<http://us.rd.yahoo.com/evt=48245/*http:/autos.yahoo.com/new_cars.html;_
ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM-

---

From: "Chauhan, Sanjeev" <[email-masked]>
Date: Tue, 17 Apr 2007 10:03:35 -0400

my 0.02 cents - 
 
- in the dns world the issue is simpler - there exists one authoratative
database where the owner of the domain lists how the domain can be
discovered. the peer (or end customer) is not given a choice. 
 
- in ip-communication (ie voip, im ...) world - both the originating and
terminating parties want to have choices (ie control)
    the originating party wants to ensure the call is delivered to the
correct end-point for reasons like
         a. avoid customer service issues
         b. for security reasons
         c. ..
    the terminating party wants to ensure it only gets the calls that it
should be receiving because
         a. reduce extraneous traffic on network
         b. keep QoS 
         c. avoid transiting traffic that it cannot charge for. 
         d. ...
 
in the above i have assumed peering b/w service providers - this could
be extended to peering b/w end-customers. 
 
going back to the original example where 2 service providers (or
federation) have claimed to be able to deliver IMs to bob@company - and
alice@company2 is trying to reach bob - the routing decision on which
one to send should be based on a combination of 
 - originating parties peering relation with the 2 federations
 - federations peering relation with the originating party
 - industry source (enum directory) that provides 3rd-party
authoratative information. 
 
-sanjeev

From: Sukanta ganguly [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 7:03 PM
To: Henry Sinnreich; PFAUTZ, PENN L, ATTCORP; Uzelac, Adam;
[email-masked]
Subject: Re: [Speermint] Re-making or Un-making the PSTN

Henry,
 
Thanks
SG

----- Original Message ----
From: Henry Sinnreich <[email-masked]>
To: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>; "Uzelac, Adam"

Penn Pfautz wrote?

Thanks, Henry

-----Original Message-----
From: PFAUTZ, PENN L, ATTCORP [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 12:03 PM
To: Uzelac, Adam; Sukanta ganguly; [email-masked]
Subject: RE: [Speermint] Re-making or Un-making the PSTN

Penn Pfautz

-----Original Message-----
From: Uzelac, Adam [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 11:48 AM
To: Sukanta ganguly; [email-masked]
Subject: RE: [Speermint] Re-making or Un-making the PSTN

-AU 

Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos.
<http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_cars.html;
_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM
->  
_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 17 Apr 2007 16:20:01 +0200

*       - industry source (enum directory) that provides 3rd-party
authoratative information. 

I do not understand why you need ENUM for delivering a call to a SIP
URI?

In addition, the basic problem we encounter is that we always mix layer
3 and layer 5
in these discussions.

Layer 5 is signalling and layer 3 is traffic including QoS

We should first come up a solution for layer 5 between SIP proxies

The traffic is going between UE and may never touch the networks
(administrative domains, whatever)

of the SIP Proxies

I do not want to carry over the mobile tromboning to IP

Richard

From: Chauhan, Sanjeev [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2007 4:04 PM
To: Sukanta ganguly; Henry Sinnreich; PFAUTZ, PENN L, ATTCORP; Uzelac,
Adam; [email-masked]
Subject: RE: [Speermint] Re-making or Un-making the PSTN

my 0.02 cents - 

         b. for security reasons

         c. ..

         b. keep QoS 

         d. ...

-sanjeev

Henry,

Thanks

SG

----- Original Message ----
From: Henry Sinnreich <[email-masked]>
To: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>; "Uzelac, Adam"

Penn Pfautz wrote?

Thanks, Henry

-----Original Message-----
From: PFAUTZ, PENN L, ATTCORP [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 12:03 PM
To: Uzelac, Adam; Sukanta ganguly; [email-masked]
Subject: RE: [Speermint] Re-making or Un-making the PSTN

Penn Pfautz

-----Original Message-----
From: Uzelac, Adam [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 11:48 AM
To: Sukanta ganguly; [email-masked]
Subject: RE: [Speermint] Re-making or Un-making the PSTN

-AU

---

From: "Chauhan, Sanjeev" <[email-masked]>
Date: Tue, 17 Apr 2007 10:45:46 -0400

richard - all valid points. let me try to restate (my intent below is to
keep peering discussing to layer 5 ie signalling)

    the originating party wants to ensure the call is delivered to the
correct end-point for various reasons 

         b. for security reasons

         c. ..

         b. avoid transiting traffic that it cannot charge for. 

         c.. ...

 - industry source that provides 3rd-party authoratative information. 

From: Stastny Richard [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2007 10:20 AM
To: Chauhan, Sanjeev; Uzelac, Adam; [email-masked]
Subject: RE: [Speermint] Re-making or Un-making the PSTN

of the SIP Proxies

Richard

my 0.02 cents - 

         b. for security reasons

         c. ..

         b. keep QoS 

         d. ...

-sanjeev

Henry,

Thanks

SG

----- Original Message ----
From: Henry Sinnreich <[email-masked]>
To: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>; "Uzelac, Adam"

Penn Pfautz wrote?

Thanks, Henry

-----Original Message-----
From: PFAUTZ, PENN L, ATTCORP [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 12:03 PM
To: Uzelac, Adam; Sukanta ganguly; [email-masked]
Subject: RE: [Speermint] Re-making or Un-making the PSTN

Penn Pfautz

-----Original Message-----
From: Uzelac, Adam [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 11:48 AM
To: Sukanta ganguly; [email-masked]
Subject: RE: [Speermint] Re-making or Un-making the PSTN

-AU