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.