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

[Mark R Lindsey]

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
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20100714/952bb25d/attachment-0001.html>