<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
The great thing about the vocalized approach is that it maintains the
telephony application passed down to us by AT&T.<br>
<br>
But the tragedy is great, too. We're all working so hard to limit
ourselves to the telephony of 1990:<br>
<br>
-- No video.<br>
<br>
-- No better-than-g711u audio.<br>
<br>
-- No distributed presence.<br>
<br>
-- No simple file transfer (which means you're stuck supporting fax
machines).<br>
<br>
-- No easy conference control (moderation, floor control, remote mute,
etc).<br>
<br>
-- No location conveyance ("Bring me a large pepperoni pizza. Goodbye.").<br>
<br>
-- No simple authentication.<br>
<br>
-- No encryption.<br>
<br>
-- No easy relocation of handsets.<br>
<br>
<br>
<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<br>
On 7/13/10 5:51 PM, Geoff Mina wrote:<br>
<blockquote type="cite">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.<br>
<br>
Not doing so will result in inconsistent and unexpected behavior for
your customers, and that never makes anyone happy.<br>
</blockquote>
<br>
<br>
On 7/13/10 5:18 PM, anorexicpoodle wrote:
<blockquote cite="mid:1279055933.1791.18.camel@poodle-x300" type="cite">
<meta http-equiv="Content-Type"
content="text/html; charset=ISO-8859-1">
<meta name="GENERATOR" content="GtkHTML/3.28.3">
I cant imagine them not just routing this through a media server and
trans-coding between the disparate parties.</blockquote>
<br>
<br>
<br>
On 7/13/10 5:04 PM, Paul Timmins wrote:
<blockquote
cite="mid:60463.2607:f4b8:2:1:222:19ff:fe06:3f1.1279055072.squirrel@secure.timmins.net"
type="cite">
<pre wrap="">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
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
VoiceOps mailing list
<a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
</pre>
</blockquote>
<br>
</body>
</html>