[VoiceOps] The peer of my peer is my peer?

[Hiers, David]

Sure, customers WANT fancy features, but mine DEMAND no less than pstn quality, uptime, and determinism.



David Hiers

CCIE (R/S, V), CISSP
ADP Dealer Services
2525 SW 1st Ave.
Suite 300W
Portland, OR 97201
o: 503-205-4467
f: 503-402-3277


-----Original Message-----
From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Mark R Lindsey
Sent: Wednesday, July 14, 2010 7:48 AM
To: voiceops at voiceops.org
Subject: Re: [VoiceOps] The peer of my peer is my peer?

The great thing about the vocalized approach is that it maintains the telephony application passed down to us by AT&T.

But the tragedy is great, too. We're all working so hard to limit ourselves to the telephony of 1990:

-- No video.

-- No better-than-g711u audio.

-- No distributed presence.

-- No simple file transfer (which means you're stuck supporting fax machines).

-- No easy conference control (moderation, floor control, remote mute, etc).

-- No location conveyance ("Bring me a large pepperoni pizza. Goodbye.").

-- No simple authentication.

-- No encryption.

-- No easy relocation of handsets.




Geoff, anorexicpoodle, and Paul are all arguing for a sober approach: "The job of the network is to ensure people can carry on voice conversations, so the network should do anything necessary to ensure this occurs." So we centralize all our control into a few central, core devices that act a lot like the 1ESS of 1965.


But we're all using technology designed by an entirely different mindset. All through the VoIP RFCs, you get the idea that the job of the network is to allow endpoints to interconnect however they want. Only by pushing intelligence to the leaf nodes of the network can you have scalable distributed applications.

We are selling the services that customers know they want. But please don't pretend that that the network we're building is the final answer for IP-based telecommunications, or even the most interesting realization of VoIP technologies.



On 7/13/10 5:51 PM, Geoff Mina wrote:


	If you are acting as an ITSP for Customer A and Customer B, I would venture to say that it is your responsibility to normalize the media between the two.  Either proxying the rtp and transcoding on-net or hairpining to the PSTN would both be acceptable.
	 
	Not doing so will result in inconsistent and unexpected behavior for your customers, and that never makes anyone happy.
	



On 7/13/10 5:18 PM, anorexicpoodle wrote: 

	  I cant imagine them not just routing this through a media server and trans-coding between the disparate parties.




On 7/13/10 5:04 PM, Paul Timmins wrote: 

	If any of my current suppliers did this, I'd scream bloody murder until
	they fixed it or made it go away. If a provider lets people choose their
	own settings, I fully expect them to transcode it for us. Anything less is
	a bug.
	
	-Paul
	
	  

		Every so often this issue comes up, and I want to get a read on it from
		other VOIP resellers...
		
		Consider a couple of unrelated VOIP resellers that peer with a carrier
		like L3.  Both can interop with L3 using strict SIP and RTP settings (max
		forwards, g729 only, 10ms ptime, whatever).  Both are free to select
		mutually incompatible settings.  For instance, reseller A can chose 729
		only, and reseller B can choose 711 only.  L3 will connect both to the
		PSTN without any trouble.
		
		Everything is good until they try to call each other.  Then the mutually
		incompatible settings will break calls or render predicted usage patterns
		invalid.  Sure, you're still signaling to a L3 SIP server, but some the
		information in the SIP/SDP packets that you receive is controlled by the
		other reseller.
		
		How often do you see problems related to the peer of your peer?
		
		
		
		
		David Hiers
		
		CCIE (R/S, V), CISSP
		ADP Dealer Services
		2525 SW 1st Ave.
		Suite 300W
		Portland, OR 97201
		o: 503-205-4467
		f: 503-402-3277
		
		
		
		This message and any attachments are intended only for the use of the
		addressee and may contain information that is privileged and confidential.
		If the reader of the message is not the intended recipient or an
		authorized representative of the intended recipient, you are hereby
		notified that any dissemination of this communication is strictly
		prohibited. If you have received this communication in error, please
		notify us immediately by e-mail and delete the message and any attachments
		from your system.
		_______________________________________________
		VoiceOps mailing list
		VoiceOps at voiceops.org
		https://puck.nether.net/mailman/listinfo/voiceops
		
		    

	
	
	_______________________________________________
	VoiceOps mailing list
	VoiceOps at voiceops.org
	https://puck.nether.net/mailman/listinfo/voiceops
	  




This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.