telecom, Vonage Traffic Clarification

comp.dcom.telecom - Telecommunications digest. (Moderated)


telecom >> Vonage Traffic Clarification

by John Levine » Thu, 12 Aug 2004 06:11:10 GMT

In article < XXXX@XXXXX.COM > you write:

> In one of the posts PAT had mentioned that Vonage to Vonage traffic
> goes completely over Vonage network. Vonage claims that they do not
> have any network infrastructure. Is my understanding of Voange's claim
> wrong or Vonage's traffic is carried over public IP network?

All of Vonage's traffic is carried over the public IP network. If you
call a normal phone, it goes from your terminal adapter box over the
net to Vonage's servers in New Jersey, where it hops onto the regular
phone network. If someone calls you, the call goes to the CLEC switch
that handles your phone number, which (as far as I can tell) then
sends the call to your TA over the net. In my case, for example, I
have an Ithaca, NY number and the switch is in Syracuse, in the same
building as all the other toll switches for this LATA.

But if one Vonage customer calls another, Vonage tells the two TAs to
talk directly to each other over the net, without routing the call
through Vonage's servers at all.

This is nice and efficient, but makes calls hard to tap since there's
no central switch where one could make a copy of the data.

Regards,

John Levine XXXX@XXXXX.COM Primary Perpetrator of The Internet for Dummies,
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

Top

telecom >> Vonage Traffic Clarification

by John R. Covert » Fri, 13 Aug 2004 09:39:59 GMT


> But if one Vonage customer calls another, Vonage tells the two TAs to

While SIP has this capability, Vonage does not use it. Even Vonage to
Vonage calls send the audio traffic via Vonage's switches, not
directly between the TAs. I suppose this facilitates Vonage's ability
to comply with court-ordered wiretaps.

/john
Top
Similar Threads

1. Clarification on 'Vonage Not in my Area Code' Thread

2. Require clarification on IEEE 802.1D -2004 spec on Conformance 

Hello -
We are implementing IEEE 802.1D -2004,spec on our equipment. I want
some clarifications on the specification .

As per the PICS conformance in A.9 (Addressing) ADDR-1 it mentions that
it is Mandatory for each Port have a Seperate MAC Address (Sec 7.12.2)
?

My question :Does this mean that each BPDU frame Txed from a Port  be
assigned a unique Universally Administered MAC address?

Could the experts please throw some light on this ? any clarification
on this would be appreciated

Thanks  and Best Regards
Kott

3. Seeking a clarification on part of RFC 2236 (IGMPv2)

4. need clarification on trunking and setting up port-channel 

Hi,

I need some clarification on setting up trunks and port-channels. I have 
two Cisco switches connected via trunk ports:

1st cable Switch A (port 1) <--> Switch B (port 1)
2nd cable Switch A (port 2) <--> Switch B (port 2)

This is where I need clarification now. Is there a point to configure 
port-channel on these switches? What will I gain by doing so, also are 
there any reasons why I would not want to do it?

Thanks,
AP

5. Clarification on VLANS native and management

6. Cisco PIX authentication proxy clarification 

Hello group,

We currently have a PIX 501 to PIX 501 vpn between two offices.  We
have an AS400 at the main site.  At both locations we would like the
users to authenticate to the PIX locally for internet access.  I
understand that the PIX allows for telnet, ftp and http authentication
locally but will the users have to authenticate against the PIX for
other traffic being passed by the AS400 or other systems on the two
networks via the VPN.  Meaning we only want the user to have to
authenticate to the PIX for internet access only and not have to
authenticate against the PIX for normal traffic between the two sites.
 This traffic should be allowed to flow freely without a user name and
password.  I have read the documentation on this but am unsure if this
is allowed.  ** At both sites internet access routes directly out it
does not tunnel through the VPN.

Thanks as always,

Joe

7. Clarification on DR,BDR selection

8. Fixup Clarification 

Hi.

I have a situation where standard FTP from the inside to DMZ works fine,
however, from the outside to the DMZ it only works for passive FTP (or
that's what i'm told).

In brief:

The only FTP fixup is 21.

On the outside I am told that there are 2/3 FTP ports in the range 19XX.
There is an access-list for each above port permitting tcp from 'any' to
that port including standard ftp & ftp-data (20 & 21). I have a static
mapping the global IP to the FTP's DMZ local IP address.

i.e. access-list blah permit tcp any global_ip eq 19XX

static (DMZ, Outside) global_ip DMZ_FTP_IP netmask 255.255.255.255

The access-group is applied to the outside interface

The DMZ access-list permits the FTP ip address back out to 'any' using
ip as the protocol. The access-list is bound to the DMZ interface.

I assume I don't need another fixup as the outbound connection, if not
specifically allowed in an access-list, would be initiated via a
temporary conduit for the session duration.

Have I missed something.

Regards

Darren