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
I love the idea of enabling intelligent endpoints to determine their compatible media formats automatically IF that is what I signed up for. In the UK BT runs a VoIP peering fabric that is very feature rich: - Video (H.264, others) - Audio (compressed/narrowband/wideband - iLBC, G.722, G.722.1, etc, etc, etc) - Probably plenty more They also offer a more vanilla PSTN orig/term service that is limited to the standards we're used to seeing (G711a, etc). You purchase, configure, and signal to these groups separately. If I want "traditional PSTN" I want it to be with the parameters specified, regardless of where it goes (on-net, peer, etc). If I want "intelligent" VoIP peering I'll configure my routing, trunking, etc accordingly and use it when and where I want to. On Wed, Jul 14, 2010 at 10:48 AM, Mark R Lindsey <lindsey at e-c-group.com> wrote:
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.
-- Kristian Kielhofner http://www.astlinux.org http://blog.krisk.org http://www.star2star.com http://www.submityoursip.com http://www.voalte.com
On 07/14/2010 02:06 PM, Kristian Kielhofner wrote:
I love the idea of enabling intelligent endpoints to determine their compatible media formats automatically IF that is what I signed up for.
One argument that's possible to make is that standardisation and commoditisation of all the relevant features has to some extent already--and will in the future further--reduce the need for this concern. In other words, it's more and more common to find CPE and network elements that support any conceivable ITU-T codec, any reasonable ptime, all forms of DTMF relay, etc. Obviously, we're not there yet. But I would wager that those capabilities are going to converge faster than it would take for any of the big operators to overhaul their networks with outboard transcoding gear or additional feature cards in every POP and so on. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
In an ideal world, yes. In the real world it's difficult enough to get predictable results negotiating ptime across two different Sonus implementations... I'm not beating up on Sonus here either. Bodies like SIPConnect are in existence because of the wide range of capability and interpretation of spec currently present in the VoIP space. I don't want to seem like a pessimist but for the moment (and foreseeable future) it is simply not acceptable to route production traffic between two VoIP systems that have not undergone extensive interop testing between one another. I'm not just talking about vendor certifications, either. Almost every platform offers enough deviation in software revision and configuration alone to warrant testing between specific networks (and specific known configs at that). Even with adequate testing, how will my media be routed? Between endpoints over the internet? Over some other layer 3 peering fabric? What about potential issues in that transport? There needs to be something like an Acme to scrub the traffic between two incompatible (or suspect) peers. Simply using a SIP proxy as demonstrated in the RFCs (Alice, meet Bob) is a recipe for disaster (Bandwidth.com). On Wed, Jul 14, 2010 at 2:35 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
One argument that's possible to make is that standardisation and commoditisation of all the relevant features has to some extent already--and will in the future further--reduce the need for this concern.
In other words, it's more and more common to find CPE and network elements that support any conceivable ITU-T codec, any reasonable ptime, all forms of DTMF relay, etc.
Obviously, we're not there yet. ?But I would wager that those capabilities are going to converge faster than it would take for any of the big operators to overhaul their networks with outboard transcoding gear or additional feature cards in every POP and so on.
-- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Kristian Kielhofner http://www.astlinux.org http://blog.krisk.org http://www.star2star.com http://www.submityoursip.com http://www.voalte.com
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.
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.
Personally, I don't have a problem with endpoints interconnecting however they want. I do have a problem, though, with the idea that because I use the same provider as another endpoint, the lack of common settings (with the endpoint) results in a failed call, when, if I were using a different provider, the call would succeed. Even worse, because the failure likely occurs after the 200, there's not a great way to fail-route. -jbn Justin B Newman
participants (5)
-
abalashov＠evaristesys.com -
David_Hiers＠adp.com -
justin＠ejtown.org -
kristian.kielhofner＠gmail.com -
lindsey＠e-c-group.com