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

Geoff Mina gmina at connectfirst.com
Tue Jul 13 17:51:26 EDT 2010

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.



Geoff MINA 
Chief Technical Officer

Connect First Inc. 
P: 678.905.0671

T: 888.410.3071

F: 678.265.1158

E:  <mailto:gmina at connectfirst.com> gmina at connectfirst.com
 <http://www.connectfirst.com/> www.connectfirst.com




From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org]
On Behalf Of Mark Holloway
Sent: Tuesday, July 13, 2010 4:58 PM
To: Hiers, David
Cc: voiceops at voiceops.org
Subject: Re: [VoiceOps] The peer of my peer is my peer?


I don't experience this with a provider like Level 3, but on our network
when one customer has an IP PBX with a SIP Trunk calling another on-net
customer with a SIP Trunk, the compatibility lies within those endpoints
playing nice with each other or else the call will fail.  An example of this
is a customer we had as a field trial with a Toshiba CIX SIP Trunk using
G.729 and calling customers on the same SIP network with Adtran TA900's.
The CIX defaults to 40ms packetization with G.729 and the TA900 only
supports up to 30ms packetization. When the CIX customer would call the
other on-net numbers using TA900's they experienced one-way audio.  We were
able to have the customer change the CIX to 20ms.  It's a tricky area and I
think it's going to take several more years to iron out all the kinks..
There is just too much interop testing to do between endpoints and providers
that unless there are standards set in place, I don't see how these sorts of
issues can be avoided 100%.



On Jul 13, 2010, at 1:38 PM, Hiers, David wrote:

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

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


No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.441 / Virus Database: 271.1.1/3001 - Release Date: 07/13/10

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20100713/4cc48811/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3418 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20100713/4cc48811/attachment.jpe>

More information about the VoiceOps mailing list