Hadriel, >If phone calls were free for everyone, had no regulation, etc., then I would expect transit providers to not steer media. >(I would in fact expect no transit providers period, ultimately)
Fortunately this is already happening as you may know if you have to make international voice calls using your own SIP box, Skype or any other. You can also see this acknowledged in the trade press. >If there's no value in something, then there's nothing to protect/monitor/troubleshoot/hide/arbitrate/provide-service-for. You have said it here in a nutshell IMO. The Google Mlab tools are just the beginning so far to insure there are no devices mucking with packets e2e. http://www.measurementlab.net/measurement-lab-tools The genie is out of the bottle and more tools will likely be made available by other organizations to protect Internet users. Henry On 4/2/09 6:28 AM, "Hadriel Kaplan" <hkap...@acmepacket.com> wrote: > > > >> > -----Original Message----- >> > From: sip-boun...@ietf.org [mailto:sip-boun...@ietf.org] On Behalf Of Dean >> > Willis >> > Sent: Thursday, April 02, 2009 1:47 AM >> > >>> > > If the peers can circumvent the SP and make their own business >>> > > agreement, then perhaps the SP wasn't actually providing a service. >>> > > >> > >> > And they're afraid the other folks will find out? Hang 'em from the >> > yardarm, Captain Bligh. Those fellows are pirates! > > I don't think they hide them to avoid circumvention - at least not in the > general case. I've heard that argument a few times, but not often. Providers > already know who the origination and termination providers are (they're > identified in the NPAC/LERG/etc.), but they just can't reasonably peer direct > with everyone. There's a demand/need for transit providers mostly because > phone calls cost money, are nationally regulated, users/law-enforcement expect > traceability, and there's a need for identity (ironically). > > Anytime money is involved, for example, it means you need a business > relationship to handle billing arrangements, and providers clearly can't scale > to have a business relationship with every other provider/domain/Enterprise on > the planet. Heck, even in the PSTN right now, SMS messages between very large > mobile providers in the same country go through a middleman, purely because > the middleman acts as the arbiter for billing. > > I'm not saying some transits don't fear circumvention - IP transits feared it > too when BGP first came out and advertised AS paths - I'm just saying it's not > the only, or even a primary, reason for SDP changing in transits. There are > really a lot of reasons the media gets steered through transit providers. The > first one is probably: because that's what is being billed/paid-for. You > yourself, Dean, have said many times that one shouldn't bill on signaling, but > rather bill on media. So providers sort of do that - they bill on the > signaling, but they open/close gates on the media to enforce that billing. > Then of course they also like to measure the QoS of the media (and sometimes > make call routing decisions based on it even), monitor that there actually is > media and that the call didn't just mysteriously fail, etc. > > If phone calls were free for everyone, had no regulation, etc., then I would > expect transit providers to not steer media. (I would in fact expect no > transit providers period, ultimately) If there's no value in something, then > there's nothing to > protect/monitor/troubleshoot/hide/arbitrate/provide-service-for. > > -hadriel > p.s. and not all transits do change SDP, and some only change SDP in certain > circumstances (like for transcoding). > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implement...@cs.columbia.edu for questions on current sip > Use sipp...@ietf.org for new developments on the application of sip >
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement...@cs.columbia.edu for questions on current sip Use sipp...@ietf.org for new developments on the application of sip
