Subject: RE: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 12 Jan 2006 11:31:06 -0500

Richard,

There will be a need to blend terms from the legacy cellular world with
the target NGN/IMS/??? architecture to lead participants from the known
to the unknown.

WRT the visited v. home, and the need for customized services and
features, the originating L5 "network" should always be the originator's
home IMS servers, and the terminating L5 "network" should always be the
terminator's home IMS servers.  This supports the concept that the
service is independent of the access network technology, in which I
include the 3GPP (GSM) v. 3GPP2 (ANSI-41/CDMA) cellular visited
networks.  A user should be able to roam/handover across multiple access
network types, to include WiFi and WiMax.

There are a variety of technologies in play, and we need to account for
all of them in this brave new world of convergence.

Mike

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Wednesday, January 11, 2006 3:00 PM
> To: Tom-PT Taylor
> Cc: Michael Hammer (mhammer); [email-masked]; 
> [email-masked]
> Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: 
> Publishing SIP Peering Policy
> 
> > I'm sure other examples come to mind.
> 
> May I help you: 3GPP and TISPAN IMS ;-)
> 
> I always thought the IETF is specifying the Internet
> 
> Richard
> 
> ________________________________
> 
> Von: Tom-PT Taylor [mailto:[email-masked]]
> Gesendet: Mi 11.01.2006 20:11
> An: Stastny Richard
> Cc: Michael Hammer (mhammer); [email-masked]; 
> [email-masked]
> Betreff: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: 
> Publishing SIP Peering Policy
> 
> 
> 
> I have no problem explaining this term. One example might be 
> if I were trying to make a call from within my corporate 
> network (the visited originating network), through my service 
> provider (the home originating network), etc. To get out of 
> my corporate network my client locates a SIP proxy in that 
> network, which then forwards the call to the peering point of 
> my service provider (which has a relationship with my 
> corporate network that allows this to happen).
> 
> I'm sure other examples come to mind.
> 
> Stastny Richard wrote:
> > Again
> > 
> > Can anybody please explain to me what the term "visited" 
> originating 
> > or terminating network means on L5
> > 
> > Both end-users are registered at their respective home 
> networks (aka 
> > SIP servers). I always thought the SIP model is a trapezoid 
> and not a 
> > hexagon
> > 
> > QoS happens at or below L3 and should be negotiated by the end-user 
> > with his acces provider.
> > 
> > Richard
> >
> > ________________________________
> >
> > Von: Tom-PT Taylor [mailto:[email-masked]]
> > Gesendet: Mi 11.01.2006 19:01
> > An: Michael Hammer (mhammer)
> > Cc: Otmar Lendl; Henry Sinnreich; [email-masked]; 
> > [email-masked]; Stastny Richard; [email-masked]
> > Betreff: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: 
> Publishing SIP 
> > Peering Policy
> >
> >
> >
> > The MSF is defining a scenario they hope to demonstrate, 
> where media 
> > paths cross different domains from signalling. The 
> signalling may be 
> > of the form visited originating network - home originating 
> network - 
> > home terminating network - visited terminating network.  
> This typical 
> > scenario is an obvious example of L5 transit. Then the 
> media path is 
> > optimized to run directly between the visited networks, possibly by 
> > way of a different transit network offering QoS based on diffserv 
> > markings at the egress points of the visited networks.
> >
> > L5 and L3 are linked in the originating and terminating visited 
> > networks, but not in between.
> >
> > Michael Hammer (mhammer) wrote:
> >
> >>There MUST be some association of IP layer protocol elements to L5 
> >>traffic needs, such as low delay, packet loss etc.  If the 
> L5 need is 
> >>real-time transmission, and that translates to a DSCP marking, then 
> >>the IP network needs to meet that need one way or another or very 
> >>simply the real-time service breaks.  The alternative is that the 
> >>peering always must include both L5 and L3 and you get a half-step 
> >>instead of full-step in evolution from PSTN to IP.
> >>
> >>Put another way, is it really necessary to have L5 transit 
> networks?  
> >>If you insist that L3 always be paired with L5 for 
> real-time, that is 
> >>what you get.
> >>
> >>Mike
> >>
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: [email-masked] 
> >>>[mailto:[email-masked]] On Behalf Of Otmar Lendl
> >>>Sent: Monday, January 09, 2006 6:06 PM
> >>>To: Henry Sinnreich
> >>>Cc: 'Michael Haberler'; 'Richard Shockey'; 'David Meyer'; 
> >>>[email-masked]; [email-masked]; [email-masked]; 
> >>>'Stastny Richard'
> >>>Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP 
> Peering Policy
> >>>
> >>>On 2006/01/09 19:01, Henry Sinnreich <[email-masked]> wrote:
> >>>
> >>>
> >>>>Otmar,
> >>>>
> >>>>You say:
> >>>>
> >>>>
> >>>>
> >>>>>All current protocols regarding proxy and transport
> >>>
> >>>selection for SIP
> >>>
> >>>
> >>>>>are only based on the domain. I don't want to diverge from
> >>>
> >>>that model.
> >>>
> >>>
> >>>>What business has the broadband provider to mess with the
> >>>
> >>>user preferences?
> >>>
> >>>
> >>>>Users and enterprises pay for a certain bandwidth and
> >>>
> >>>hopefully will
> >>>
> >>>
> >>>>have the choice to pay extra for Diff Serv and that's the 
> end of it.
> >>>
> >>>In an ideal world, yes.
> >>>
> >>>
> >>>
> >>>>If one domain has DiffServ and the other does not, it's up to the 
> >>>>users to continue the call or switch over to some other
> >>>
> >>>networks, such
> >>>
> >>>
> >>>>as mobile or PSTN. And also to tell the other party to please 
> >>>>subscribe to better broadband :-)
> >>>>
> >>>>What do you think?
> >>>>
> >>>
> >>>My problem with this idea is that "domain" in the sense of 
> >>>SIP-servers is an application layer notion.
> >>>
> >>>DiffServ is a layer 3 issue. My layer 3 network does not 
> neccessarily 
> >>>know which applications I run over them.
> >>>
> >>>If my ISP also acts as my SIP provider, then yes: one can 
> link these 
> >>>two layers into one integrated QoS solution. AFAIK this is 
> one of the 
> >>>aims of the IMS. One of the local Austrian ISPs uses this for his 
> >>>VoIP service: they use separate VLANs/QoS planes for their VoIP 
> >>>offering.
> >>>
> >>>My private playground is quite different: I use an Asterisk 
> >>>installation on a box (the same one I write this mail on) 
> colocated 
> >>>at ISP A whereas my SIP-phone at home is connected via ISP B. The 
> >>>gateway to the PSTN is operated by a commercial provider 
> who uses ISP 
> >>>C.
> >>>If you add my ENUM nameservers, you get one more ISP into 
> the picture.
> >>>To top it off, I could add a SIP line to my office phone 
> which would 
> >>>bring our office connectivity into the game were we 
> basically run own 
> >>>multihomed network.
> >>>
> >>>I really don't know how to get seamless QoS in such a setting.
> >>>
> >>>(As you mentioned before: layer3 networks can't just trust each 
> >>>other's DiffServ settings.)
> >>>
> >>>/ol
> >>>--
> >>>< Otmar Lendl ([email-masked]) | nic.at Systems Engineer > 
> >>>______________________________________________________________
> >>>_______________
> >>>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> >>>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
> >>>
> >>
> >>
> >>_______________________________________________
> >>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: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 12 Jan 2006 15:26:52 -0500

L5 peering happens at every network boundary, not just the one at the 
centre of the call path. In the example I gave three peering 
relationships are needed.

> all of them in this brave new world of convergence.
...