Subject: RE: [Speermint] Reachability

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 5 Apr 2006 19:21:50 -0400

This is an interesting thread especially for the scenario A-B-C where B
is providing transit services. In near term , I don't see any operator
will like to provide transit services since I don't smell money in this
area ;-) Also, if A doesn't peer C directly, we have our old friend PSTN
to do the work (at least working for the voice service). The
complication of providing transit services is to guarantee service
delivery. In theory, the SIP proxy in B doesn't need to record-route
itself so that it can leave the signaling path as soon as A & C
establish the session. Reality is B must stay in the signaling path
because A signed a peering agreement with B and B signed a peering
agreement with C, there is no agreement between A & C and the agreement
is not transitive. If A sends a mid-dialog request directly to C, C's
policy may probably reject it. For the media flow, I also argue that
even if A & C have directly IP peering connectivity, A's media traffic
should flow through B's IP network then to C's IP network. The reason is
B signed QoS agreement with A & C, but A & C may not have any, so C
won't prioritize the media traffic coming directly from A's IP peering
interface. If the link is congested, the service quality will degrade.

I think peering is above policy. I assume that this WG will take the
lead to define and standardize the peering policy as well as the
protocol distributing the policy.

Yiu

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Sunday, April 02, 2006 9:48 PM
To: 'Stastny Richard'; [email-masked]
Subject: RE: [Speermint] Reachability

Hi Richard, comments inline...

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Saturday, April 01, 2006 2:46 PM
> To: [email-masked]
> Subject: [Speermint] Reachability
> 
> after reading the document from Scott Markus on NGN Interconnect I 
> referenced for weekend reading in my last posting 
> http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1
> .pdf

Indeed that was an interesting paper - thanks for the pointer! (not that
I agree with everything in it)

> and second we always started naturally at provider A in direction of 
> call set-up and not at provider B

Personally, I think the bigger "problem" is the provider C, the one
after B.
:)  C trying to be reachable by A through B.  But that's out of scope I
guess.  It's too bad, because that's when BGP got interesting, for
example.

> Provider B has now (currently only for Public User Identities in the 
> form of E.164 numbers) the OBLIGATION making this PUI reachable for 
> the public by interconnecting with the public network (in this case at

> least via the PSTN) [snipped] So IMHO we can assume that provider B 
> hosting a Public User Identity (a SIP URI) MUST make this PUI 
> reachable in principle.

I would think that would only be true if you define the AoR to be a
public identity in the public domain, and such regulation was to be
created for AoRs.  E.164 numbers are by definition such numbers, I
think.  But if, for example, I build a private enterprise network -
there's no way I'm obligated to do so just because I use the same SIP
fields AoRs are used in.

Having said that, I would think most providers _want_ to make them
reachable, because that increases their value.  But as the paper pointed
out, peering is difficult to manage beyond a few hundred peers, nor do
IP or PSTN providers peer with everyone directly to achieve universal
reachability.  That's why, for me, the more complex problem is the
peer(s) between.  But documenting A-B/B-A is a good start.

> The NRA normally sets the limits to such an offer.

The power of the national rifle association is staggering.  ;)

-hadriel

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

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

---

From: "Patrick Melampy" <[email-masked]>
Date: Wed, 5 Apr 2006 19:47:14 -0400

You bring up a very interesting point. Would A pay B to get to C if B didn't
deliver the media flows also? I would love to go into business where I can
do the signaling and have no further role in the management of the resultant
media session, but I fear the business has no value.

I figure A won't pay B unless the whole session is handled. Which brings up
your point...will anybody take on the role of B? Why?

I'm guessing there are examples with bilateral agreements that involve user
mobility that closely mirror your example. Imagine a user whose home is B
moving to network C. Now the service path passes through network B. Does
network B care to have the session managed? 

Also note that A and C could establish a bilateral agreement, but they may
be competitors and thus may desire not to. Imagine Comcast and Verizon
trying to work out a bilateral agreement. They may decide to use B. Who
would be B? 

I think there will always be networks between -- and the real work of this
group is to figure out the requirements for signaling and media to make
these kinds of session paths work to the benefit of all participants.

-----Original Message-----
From: Lee, Yiu [mailto:[email-masked]] 
Sent: Wednesday, April 05, 2006 7:22 PM
To: Hadriel Kaplan; Stastny Richard; [email-masked]
Subject: RE: [Speermint] Reachability

Yiu

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Sunday, April 02, 2006 9:48 PM
To: 'Stastny Richard'; [email-masked]
Subject: RE: [Speermint] Reachability

-hadriel

---

From: Peter Macaulay <[email-masked]>
Date: Wed, 05 Apr 2006 20:02:00 -0400

Yiu Lee.  Thank you.  You have quickly taken us to the design
issue: Does peering need to include the A-B-C model where A-C
may have a trust relationship, but not A-B nor B-C?

So do we allow;

  (1) A-B-C peering signaling path with no media-relay (do your own)
  (2) A-B-C peering signaling path with media-relay.

Variations will break some security models!  As Melampy says
there will always be "networks between" -- so let's not avoid the
real A-B-C world.  As mentioned earlier, solving the relay issue
has been part of Skype's success.

/PETER MACAULAY