I have been looking into peer to peer - where one "dials" the IP
rather than going through a provider. I got the idea from the recent
thread on BT Home Hubs.
I decided to do a bit of local testing myself as I have a Zyxel ATA
with two lines. So I set the phone book up with two entries each
pointing to the other line via the external address (I have fixed IPs)
- You have to use the phone book as you can't "dial" an IP.
If I call either phone from the other using their "land line numbers",
ie it goes to the provider and back again, the other phone rings. But
if I use the speed dial IP entry I just get silence. If I use the
speed dial entry to call the one I am calling from I get engaged as
expected. So "something" is happening, just not what I expected. I set
the phone book entry to be the number provided by the provider for
that line and the ATA's external IP address.
I must be missing something obvious. I someone has a setup that works
by "dialing" IP numbers please PM me and I will give you a number to
try.
With some help from another reader we established that it *can* work
provided that both ends can solve going through NAT. My Zyxel is OK as
it can embed the external IP address in the VOIP packet - but the
other end was not. So my end was trying to reply to his *internal*
address as he normally went through a STUN server. So we ended up with
a one way conversation.
Still no idea why my Line 1 can't call Line 2 though. Snooping the
packets it appears that they are just throwing invites at each other.
Anyone know where I can find the gory details of VOIP packets?
On Fri, 11 Jan 2008 14:54:21 UTC, Paul Hayes
<nomailforme@polog40.co.uk> wrote:
> Dave Saville wrote:
> > Anyone know where I can find the gory details of VOIP packets?
> >
>
> RFC3261 will go into just about as much gory detail as you could ask for.
>
> This website might have some easier to digest information on it though:
>
> http://www.tech-invite.com/
Dave Saville wrote:
> Bad form to reply to one's own post but....
>
> With some help from another reader we established that it *can* work
> provided that both ends can solve going through NAT. My Zyxel is OK as
> it can embed the external IP address in the VOIP packet - but the
> other end was not. So my end was trying to reply to his *internal*
> address as he normally went through a STUN server. So we ended up with
> a one way conversation.
>
> Still no idea why my Line 1 can't call Line 2 though. Snooping the
> packets it appears that they are just throwing invites at each other.
> Anyone know where I can find the gory details of VOIP packets?
>
You don't say which Zyxel ATA but on the 2002's I have here, you just
dial #### and it dials the phone on the other port.
On Fri, 11 Jan 2008 15:32:38 UTC, Desk Rabbit <nospam@example.com>
wrote:
> Dave Saville wrote:
> > Bad form to reply to one's own post but....
> >
> > With some help from another reader we established that it *can* work
> > provided that both ends can solve going through NAT. My Zyxel is OK as
> > it can embed the external IP address in the VOIP packet - but the
> > other end was not. So my end was trying to reply to his *internal*
> > address as he normally went through a STUN server. So we ended up with
> > a one way conversation.
> >
> > Still no idea why my Line 1 can't call Line 2 though. Snooping the
> > packets it appears that they are just throwing invites at each other.
> > Anyone know where I can find the gory details of VOIP packets?
> >
> You don't say which Zyxel ATA but on the 2002's I have here, you just
> dial #### and it dials the phone on the other port.
Yes I know (it is a 2002) but I was trying to test out "dialing by IP"
and did not know anyone to try it with.
On Fri, 11 Jan 2008 15:32:38 UTC, Desk Rabbit <nospam@example.com>
wrote:
> You don't say which Zyxel ATA but on the 2002's I have here, you just
> dial #### and it dials the phone on the other port.
Ops - hit the send key too quickly :-)
The other thing the 2002 book does not say is if it is OK to use the
*same* port numbers for both lines. It would appear from testing that
one can - the firmware obviously selecting by the SIP number as to
which phone to route it to.
"Dave Saville" <dave@nospam.deezee.org> wrote in message
news:fV45K0OBJxbE-pn2-xGd0YmmgYGXu@localhost...
> On Sat, 12 Jan 2008 01:34:33 UTC, "Martin²" <never@give.one> wrote:
>
>> Dave,
>> you CAN dial IP numbers directly, start and end with #. use * for .
>> e.g.
>> #123*45*67*89#
>
> Martin
>
> But what about the number? is it 123456#81*81*81*81# ? And does this
> work on any ATA?
>
You've missed the point, there isn't a number, it's peer to peer.
(And FWIW I haven't got it to work either)
--
Graham
On Sat, 12 Jan 2008 14:38:49 UTC, "Graham." <me@privacy.com> wrote:
>
>
> "Dave Saville" <dave@nospam.deezee.org> wrote in message
> news:fV45K0OBJxbE-pn2-xGd0YmmgYGXu@localhost...
> > On Sat, 12 Jan 2008 01:34:33 UTC, "Martinư" <never@give.one> wrote:
> >
> >> Dave,
> >> you CAN dial IP numbers directly, start and end with #. use * for .
> >> e.g.
> >> #123*45*67*89#
> >
> > Martin
> >
> > But what about the number? is it 123456#81*81*81*81# ? And does this
> > work on any ATA?
> >
>
>
> You've missed the point, there isn't a number, it's peer to peer.
> (And FWIW I haven't got it to work either)
There must be a number - I have two different incoming to the same IP
on the same port - and they work independently with no problem - So
there *must* be something to tell which is which and therefore it must
be the sip number assigned. If you set IP to IP in the phone book you
specify a number/string and the IP.
On Sat, 12 Jan 2008 15:27:26 +0000, Dave Saville wrote:
> On Sat, 12 Jan 2008 14:38:49 UTC, "Graham." <me@privacy.com> wrote:
>> "Dave Saville" <dave@nospam.deezee.org> wrote
>> > But what about the number? is it 123456#81*81*81*81# ? And does this
>> > work on any ATA?
Some ATAs can be configured to ignore calls coming from anywhere other
than where they've registered to.
>> You've missed the point, there isn't a number, it's peer to peer. (And
>> FWIW I haven't got it to work either)
The OP means the 'user' bit of the sip address, ie user@domain [or
user@ip in this case].
> There must be a number - I have two different incoming to the same IP on
> the same port - and they work independently with no problem - So there
> *must* be something to tell which is which and therefore it must be the
> sip number assigned. If you set IP to IP in the phone book you specify a
> number/string and the IP.
Sipgate tells you in their web interface which 'user' registered. Perhaps
your service provider offers a similar feature? In any case you'll have
specified it somewhere in the configuration.
--
<http://ale.cx/> (AIM:troffasky) (UnSoEsNpEaTm@ale.cx)
16:50:15 up 7 days, 7:14, 2 users, load average: 1.33, 1.16, 1.10
2x Broadband/IT/Telecoms support positions in Newcastle city centre.
For more info call 0191 229 8870 and ask for Steve. No agencies.
Dave:
>There must be a number - I have two different incoming to the same IP
>on the same port
That's because they have registered themselves with your VoIP provider and
the SIP protocol can differentiate
between them.
If you dial directly the IP number of a router, it doesn't need any user id
/ no, and would connect to a SIP device on port 5060. If there two then one
or both should ring.
Regards,
Martin
On Sun, 13 Jan 2008 01:31:10 UTC, "Martin²" <never@give.one> wrote:
> Dave:
> >There must be a number - I have two different incoming to the same IP
> >on the same port
>
> That's because they have registered themselves with your VoIP provider and
> the SIP protocol can differentiate
> between them.
>
> If you dial directly the IP number of a router, it doesn't need any user id
> / no, and would connect to a SIP device on port 5060. If there two then one
> or both should ring.
> Regards,
Hmm, I don't think the Zyxel supports dialing an IP. I just tried and
snooped the invite and it says #<ip>#@<provider> where <provider> is
the provider the line is registered to.
On Sun, 13 Jan 2008 21:19:01 UTC, Iain <no-one@hairydog.co.uk> wrote:
> Dave Saville wrote:
> > I have two different incoming to the same IP
> > on the same port - and they work independently with no problem
>
> Which provider?
>
Orbtalk & Voiptalk
> - So
> > there *must* be something to tell which is which and therefore it must
> > be the sip number assigned.
>
> I don't think so, but I'm not sure.
peer to peer 
Linear Mode
