On 07/13/2010 05:35 PM, Kristian Kielhofner wrote:
I've seen this happen with resellers that only use a proxy between their customers (Bandwidth.com). In that case all transport, codec, and caller ID parameters must be compatible (Bandwidth won't do anything about them).
It's even worse if the end-users behind the ITSP's proxy are behind NAT. You can do signaling-level NAT fixups in a proxy, but without relaying media, you rely on the upstream carrier's edge equipment to do draft-comedia style NAT traversal on the media, whereupon the true UDP source port of the RTP is discovered prior to sending RTP to the end-user leg (on the assumption of symmetric RTP), instead of using the UDP port declared in the SDP body coming from the end-user. Bandwidth.com's edge equipment does not do such fixups, so it is entirely incumbent upon the ITSP to deal with this situation.
With Level(3) Vector they hold media and can make codecs compatible. However, one problem we have found is Caller ID presentation. When going to a peer Level(3) will not do a dip and set the from name, they depend on the originating network to set the CID appropriately or they depend on the terminating network to do a dip.
... in E.164, no less. -- 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/