Subject: RE: [Speermint] Terminology draft - Peering

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 13 Jul 2006 08:06:28 -0400

My apologies.  I lost the *not* in the sentence.

Nevermind :)

Mike

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Thursday, July 13, 2006 7:52 AM
> To: Michael Hammer (mhammer); David Meyer
> Cc: [email-masked]
> Subject: Re: [Speermint] Terminology draft - Peering
> 
> >    Media streams associated with this signaling (if any) are not
> >    constrained to follow the same set of paths.
> 
> I think this is an unnecessary and potentially damaging 
> constraint.  It implies that the media path goes through the 
> same TLS connections and boxes as the signaling at worst.  It 
> may also preclude any optimization of the media path in cases 
> where the calling and called parties are roaming far from 
> their home networks, but sitting on the same cell site.
> I would much prefer that signaling and media paths be loosely coupled.
> 
> [Richard]
>  
> I fully agree with you and that was exactly what I ( and 
> Dave) meant. I did not change this sentence, it is from the 
> original text. I do not see what the problem is here.
>  
> If you have a better or cleare wording, please propose another wording
>  
> Richard
> 
> ________________________________
> 
> Von: Michael Hammer (mhammer) [mailto:[email-masked]]
> Gesendet: Do 13.07.2006 13:42
> An: Stastny Richard; David Meyer
> Cc: [email-masked]
> Betreff: RE: [Speermint] Terminology draft - Peering
> 
> 
> 
> Inline...
> 
> > -----Original Message-----
> > From: Stastny Richard [mailto:[email-masked]]
> > Sent: Wednesday, July 12, 2006 6:55 PM
> > To: David Meyer
> > Cc: [email-masked]
> > Subject: [Speermint] Terminology draft - Peering
> >
> > Proposed wording for Peering
> > 
> > 4.2.  Layer 5 Peering or Session Peering
> >    Layer 5 peering or Session Peering refers to interconnection of
> >    two (VoIP) service providers for the purposes of routing 
> real-time
> >    (or quasi-real time) secure call signaling between their 
> respective
> >    customers using SIP methods.  Such interconnection may 
> be direct or
> >    indirect.
> >    Media streams associated with this signaling (if any) are not
> >    constrained to follow the same set of paths.
> 
> I think this is an unnecessary and potentially damaging 
> constraint.  It implies that the media path goes through the 
> same TLS connections and boxes as the signaling at worst.  It 
> may also preclude any optimization of the media path in cases 
> where the calling and called parties are roaming far from 
> their home networks, but sitting on the same cell site.
> I would much prefer that signaling and media paths be loosely coupled.
> 
> If you feel this is somehow justified, please elaborate on 
> what you mean by path.
> 
> Mike
> 
> 
> 
> > 4.3.  Direct Peering
> >    Direct Peering covers all cases where the two SPs interconnect 
> > without
> >    using an intervening L5 network. Both SP must have a trust 
> > relationship
> >    established (e.g. know they belong to the same federation (see 
> > below))
> >    before opening up a secure communication path on L5.
> > 4.4   Indirect or Transit Peering
> >    Indirect or transit peering is the establishment of a secure 
> > signalling
> >    path via one (or more) referral or transit network(s). 
> In this case 
> > it is
> >    required that a trust relationship is established between the 
> > originating
> >    SP and the transit network on one side and the transit 
> network and 
> > the
> >    termination network on the other side before opening up a secure
> >    communication path on L5.
> > 
> > In addition,
> > I suggest to delete the old section 4.4. on private peering 
> because it 
> > is confusing and and out of scope anyway
> > 
> > 
> >
> > _______________________________________________
> > 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: "Reinaldo Penno" <[email-masked]>
Date: Thu, 13 Jul 2006 11:50:30 -0400

I think RFC3263 states it better than me

"   It is not necessary for the domain suffixes in the NAPTR replacement
   field to match the domain of the original query (i.e., example.com
   above).  "

thanks,

reinaldo

> From: Reinaldo Penno
> Sent: Thursday, July 13, 2006 8:47 AM
> To: 'Stastny Richard'; David Meyer
> Cc: [email-masked]
> Subject: RE: [Speermint] Terminology draft - Peering
> 
> So, what I'm trying to say is that the domain part of the AOR does not
> tell you which VSP actually hosts it. You can have vanity domains,
company
> domains, etc, etc. Just like you can have a domain at your home but
use
> your providers SMTP to relay email to you.
> 
> Okay, let's put some call flows around it putting the federation thing
> aside for a moment. So, adapted from RFC 3263...example.com is
actually at
> vspc.com
> 
> As an example, consider a client that wishes to resolve
>    sip:[email-masked].  The client performs a NAPTR query for that
>    domain, and the following NAPTR records are returned:
> 
>    ;          order pref flags service      regexp  replacement
>       IN NAPTR 50   50  "s"  "SIPS+D2T"     ""  _sips._tcp.vspb.com.
>       IN NAPTR 90   50  "s"  "SIP+D2T"      ""  _sip._tcp.vspb.com
>       IN NAPTR 100  50  "s"  "SIP+D2U"      ""  _sip._udp.vspb.com.
> 
>    This indicates that the server supports TLS over TCP, TCP, and UDP,
>    in that order of preference.  Since the client supports TCP and
UDP,
>    TCP will be used, targeted to a host determined by an SRV lookup of
>    _sip._tcp.vspb.com.  That lookup would return:
> 
>    ;;          Priority Weight Port   Target
>        IN SRV  0        1      5060   server1.vspb.com
>        IN SRV  0        2      5060   server2.vspb.com
> 
> 
> When the INVITE gets to server1.vspb.com it would eventually send to
> server1.vspc.com because that's the proxy/VSP that provides VoIP
services
> to example.com. I might begetting this wrong, is there something wrong
> with this example?
> 
> Thanks,
> 
> Reinaldo
> 
> > Sent: Thursday, July 13, 2006 8:28 AM
> > To: Reinaldo Penno; David Meyer
> > Cc: [email-masked]
> > I think we are getting ahead of ourselves here
> >
> > I always have to start with the AoR and look up the domain there
> >
> > Here I may find a NAPTR indicating the federation (and eventually a
> > policy)
> > and I alsi find there the 3263 NAPTR and SRV, pointing to the
servers
> > where
> > I should send the invites to
> >
> > If there is an indirect peering, I may be diverted to (the domain
of)
> VSP
> > B,
> > where I also may finally look up the 3263 SRV to find the ingress
points
> > to send the invite too. How VSP B is no going further to reach B is
none
> > of my business
> > Von: Reinaldo Penno [mailto:[email-masked]]
> > Gesendet: Do 13.07.2006 17:19
> > Richard,
> > I think you are assuming the domain part of AORs maps to the VSP
that
> > actually host his VoIP service and this relationship is not well
> > defined.
> >
> > I can be in VSP A and make a DNS query for [email-masked]
and
> > get as a result a proxy server at VSP B. Now, some-company.com is
> > actually served by VSP C, but the DNS returns VSP B because that's
where
> > you need to send your signaling to get to some-company.com
> >
> > In this case, VSP A has no way of knowing that some-company.com is
> > actually "hosted" (for a lack of a better term) in VSP C.
> >
> > A VSP can serve many domains. Just because the VSP is called
vspb.com
> > does not mean it cannot serve, e.g., supervoip.com, voip'r'us.com,
> > voipathome.com, etc, etc
> >
> > Thanks,
> >
> > Reinaldo
> >
> >
> >
> > > Sent: Thursday, July 13, 2006 8:02 AM
> > > To: Reinaldo Penno; David Meyer
> > > Cc: [email-masked]
> > > >VSPA <-----> VSP B <-----> VSP C
> > >
> > > >Is VSP B providing layer 5 "transit" or we can just say it peers
with
> > A
> > > and B?
> > >
> > > >VSP A might not even know that is talking with VSP C through VSP
B.
> > For
> > > >all purposes, VSP B is VSP C...
> > >
> > > VSP A must know that the call terminates at VSP C, because he
> > basically
> > > has
> > > an AoR for VSP C.
> > >
> > > He looks up VSP C and sees he cannot peer with VSP C directly, but
> > gets
> > > the pointer to VSP B (somehow)
> > >
> > > Now he peers with VSP B and VSP B peers with VSP C
> > >
> > > Richard
> > >
> > > Von: Reinaldo Penno [mailto:[email-masked]]
> > > Gesendet: Do 13.07.2006 15:49
> > > I thought at some point we kind of agreed to get rid of the
transit
> > > term, wasn't it?
> > >
> > > Anyway, in the following case
> > >
> > > VSPA <-----> VSP B <-----> VSP C
> > >
> > > Is VSP B providing layer 5 "transit" or we can just say it peers
with
> > A
> > > and B?
> > >
> > > VSP A might not even know that is talking with VSP C through VSP
B.
> > For
> > > all purposes, VSP B is VSP C...
> > >
> > > Thanks,
> > >
> > > Reinaldo
> > >
> > >
> > >
> > > > Sent: Wednesday, July 12, 2006 9:18 PM
> > > > To: Reinaldo Penno; David Meyer
> > > > Cc: [email-masked]
> > > > >[[Reinaldo]]
> > > > >SPs or VSPs?
> > > > Both
> > > > >Is this transit network just providing IP transit or it is
actually
> > a
> > > > >Layer 5 transit network? I think the requirements are different
in
> > > > >two scenarios.
> > > > L5
> > > > Von: Reinaldo Penno [mailto:[email-masked]]
> > > > Gesendet: Do 13.07.2006 04:32
> > > > Hello Richard,
> > > > > Sent: Wednesday, July 12, 2006 3:55 PM
> > > > > To: David Meyer
> > > > > Cc: [email-masked]
> > > > >    customers using SIP methods.  Such interconnection may be
> > direct
> > > or
> > > > >    indirect.
> > > > >    Direct Peering covers all cases where the two SPs
> > > > [[Reinaldo]]
> > > >
> > > > SPs or VSPs?
> > > >
> > > > interconnect without
> > > > below)
> > > > >    path via one (or more) referral or transit network(s). In
this
> > > case
> > > > it
> > > > > is
network
> > > and
> > > > [[Reinaldo]]
> > > > Is this transit network just providing IP transit or it is
actually
> > a
> > > > Layer 5 transit network? I think the requirements are different
in
> > > > two scenarios.
> > because
> > > > > it is confusing and and out of scope anyway
> > > > >
> > > > >
> > > > >

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 13 Jul 2006 13:20:00 -0400

> >    Direct Peering covers all cases where the two SPs

I think we ought to just say "domains" and not go down this road again
on ITSP vs VSP vs SP vs Carrier vs whatever.  ;-)

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 17 Jul 2006 11:46:51 -0400

> I would much prefer that signaling and media paths be loosely coupled.

Jason (me) said:

I'm confused - seems like you are both saying the same thing, that media
and signaling need not follow the same path through the network.

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 17 Jul 2006 11:46:56 -0400

> On a bit of a side-note, currently it is unclear the extent 
> to which bearer/media should be addressed within the 
> SPEERMINT scope.  I plan on supplying Jean-Francois feedback 
> on that section [3.3] of the requirements draft - and I 
> encourage others to do the same to fully vet out the requirements.

Please do comment.  We should explictly address the questions around
media and signaling paths/flows, and this is a subject that comes up
often here.  We should strive to resolve this question soon.

It seems like we have a few options:

A - Signaling and Media MUST follow the same path.

B - Signaling and Media MAY or MAY NOT follow the same path.  (I am sure
there's some nuance in here.)

C - Signaling and Media SHOULD NOT follow the same path.

Option B seems like it may be the optimal compromise that allows for
maximum flexibility.  Any other options possible?

Jason

---

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Mon, 17 Jul 2006 11:44:27 -0500

We will need all three options depending on the peering situation. 

-----Original Message-----
From: Livingood, Jason [mailto:[email-masked]] 
Sent: Monday, July 17, 2006 10:47 AM
To: Uzelac, Adam; [email-masked]; Stastny Richard
Cc: [email-masked]
Subject: RE: [Speermint] Terminology draft - Peering

> On a bit of a side-note, currently it is unclear the extent to which 
> bearer/media should be addressed within the SPEERMINT scope.  I plan 
> on supplying Jean-Francois feedback on that section [3.3] of the 
> requirements draft - and I encourage others to do the same to fully 
> vet out the requirements.

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 21 Jul 2006 15:02:28 -0400

All of this makes sense to me for now...

Jason 

> From: Daryl Malas [mailto:[email-masked]] 
> Sent: Monday, July 17, 2006 7:31 PM
> To: Michael Hammer (mhammer)
> Cc: Livingood, Jason; Uzelac, Adam; [email-masked]; 
> Stastny Richard; [email-masked]
> Mike,  I agree, the following three options will occur.  We 
> MUST allow for all of these methods (a,b, and c). --Daryl
> 
> On Mon, 2006-07-17 at 11:56 -0400, Michael Hammer (mhammer) wrote:
> > Jason,
> > 
> > Could we say it as follows:
> > 
> > Signaling will determine:
> > a) whether the media must follow the same path as signaling,
> > b) whether it must follow a different path than signaling, or
> > c) whether may follow a direct path not controlled by signaling.
> > 
> > In the above, a) may point to a composed SBC, b) may point to the 
> > media part of a decomposed SBC, and c) may let IP routing 
> mechanisms 
> > direct the media across any edge router toward the destination.
> > 
> > Make sense?
> > 
> > Mike
> > 
> > 
> > > Sent: Monday, July 17, 2006 11:47 AM
> > > to which
> > > > requirements draft - and I encourage others to do the same to 
> > > > fully vet out the requirements.
> > > 
> > > B - Signaling and Media MAY or MAY NOT follow the same path.  
> > > (I am sure there's some nuance in here.)
> > >