<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
the next version will have ability to add multiple proxies. We just
didn't get it in time for this beta. One of the challenges of course is
that we want to continue to do smart NAT/firewall penetration. Stun
isn't enough as you probably know. How do you allow other proxies, but
still do smart network traversal? It's a bit tricky. <br>
<br>
You can dial any sip url from Gizmo, just enter in the fully qualified
uri like this:<br>
<a class="moz-txt-link-abbreviated" href="mailto:sip:user@proxy.domain.com">sip:user@proxy.domain.com</a><br>
<br>
I just checked and you can add to addressbook as well, but it doesn't
seem to be dialing correctly. That's clearly a bug. You should and wil
be able to dial any URI or enter it into addressbook. <br>
<br>
Yes, it's true we're not using e.164 numbers ourselves. We actually
likely will have an overlay of some sorts, but you'll see why making up
a private number makes sense as we announce some of the partnerships we
have in the works. A private number and enum can peacefully co-exist. <br>
<br>
-- MR<br>
<br>
John Todd wrote:
<blockquote cite="midp06020409bef3084bf3c5@loligo.com" type="cite">At
4:32 PM -0700 on 7/6/05, Michael Robertson wrote:
<br>
<blockquote type="cite">DUNDI peeps,
<br>
<br>
We just released beta of Gizmo Project at
<a class="moz-txt-link-rfc2396E" href="http://www.gizmoproject.com"><http://www.gizmoproject.com></a><a class="moz-txt-link-freetext" href="http://www.gizmoproject.com">http://www.gizmoproject.com</a>. Set
aside the non-imaginative name we think this Mac/Win and soon Lin VOIP
client is interesting. It does NAT/firewall traversal as well as Skype,
but it's based on open standard SIP and we're trying to connect to
every one with a commitment to an open directory. Of course this means
DUNDI too!
<br>
<br>
Gizmo is a snazzy VOIP client with nice features like voicemail, call
record, etc. but more importantly for this list a Gizmo user can call
DUNDI numbers with no additional configuration. We'd like to get some
testers specifically of the DUNDI connection.
<br>
<br>
We're looking for ways to make it work better with Astericks in
general. Ideally, we'd like to make the client configurable to work
with an Astericks setup, but still do the firewall/NAT traversal stuff
so it could be used as a remote client from anywhere on the net.
<br>
<br>
Please give it a try and let me know how it works for you and any
suggestions you might have.
<br>
<br>
Go astericks!
<br>
<br>
-- MR
<br>
<br>
Michael Robertson
<br>
<a class="moz-txt-link-rfc2396E" href="mailto:michael@linspire.com"><mailto:michael@linspire.com></a><a class="moz-txt-link-abbreviated" href="mailto:michael@linspire.com">michael@linspire.com</a> Read the
latest Michael's Minute <a class="moz-txt-link-rfc2396E" href="http://www.lindows.com/mm"><http://www.lindows.com/mm></a>here
<br>
</blockquote>
<br>
Michael -
<br>
I actually downloaded Gizmo a few days ago on my Mac and got it
working - congrats on that, at least! I am typically the worst
possible installation candidate, and the software did what it was
supposed to.
<br>
<br>
I do have a few issues with Gizmo, though. It's not a software
client - it's a service. You don't allow for alternate SIP servers to
be specified in the configuration, therefore this is not something that
is very useful to me. I don't have any control over where my calls go,
or how they're handled. I can't opt out of DUNDi, if you're using it,
or ENUM, or...? I assume you're using ENUM lookups as well? What
roots? (Hint: the ENUM question may directly link into your query
about how to get DUNDi e164 calls to the advertising destination,
depending on your configuration.)
<br>
<br>
Looking for DUNDi integration into your service is perhaps getting
ahead of yourself with the wrong audience, though I do commend the
desire to deliver calls via IP for free. However, you may wish to
review this policy if you have paying customers - there is always the
real possibility of number hijack if you are subscribing to a directory
service with weak authentication (friend-of-a-friend-of-a-friend...)
It's one thing when people using the system know that the possibility
exists, it's quite another when you have otherwise-unaware people
paying for the service.
<br>
<br>
I understand that you're not pitching this product (the client) to
the advanced user, so perhaps I'm barking up the wrong tree when I say
I'm disappointed in the inextricable client/service linkage. You
indicate that you're looking to do more Asterisk integration somehow,
so I'm anxious to see what results from that effort and if it's useful
to me.
<br>
<br>
Lastly, you're not using e164 numbers. You're using an area code
that you've picked out of the air - we've had this discussion before. I
applaud your desire to be _similar_ to e164, but you're not. A better
choice would be to go to NANP and apply for some non-geographic number
space, or to talk with the people using the +878 country code (though
you'll be talking to a very expensive and Bell-shaped brick wall.) If
you want to be e164-compliant, you need to actually use e164 numbers.
While I don't have time to read it at the moment, I would hope that the
DUNDi GPA does not allow for "spurious" number ranges to be introduced
(<cough>1700<cough>) since that sets a very bad precedent
and will lead to distrust of the number pool right out of the starting
blocks. It's been a while since I read that doc; maybe there's a
provision for "private" numbers with a flag...
<br>
<br>
<br>
PS: I get continual timeout errors when trying to send a SIP subscribe
to one or more of your services that your app "secretly" subscribes
to. Here's a snipped of the fast-paced tethereal dump of 5060
information buzzing by (almost all of it errors or overly aggressive
re-SUBSCRIBE requests) on my laptop:
<br>
209.291017 202.1.16.19 -> 198.65.166.131 SIP Request: SUBSCRIBE
sip:17474746000@proxy01.sipphone.com:5060
<br>
210.207193 198.65.166.131 -> 202.1.16.19 SIP Status: 408 Request
Timeout
<br>
<br>
<br>
PPS: The inability to specify a SIP URI address (despite the
nomenclature on the "Add User" interface that says "SIP number") as a
location indicator is especially frustrating, considering your previous
dedication to open standards. When I try to put "<a class="moz-txt-link-abbreviated" href="mailto:jtodd@loligo.com">jtodd@loligo.com</a>" in
this field, I get an error of "Add contact failed, error 1. The name
"jtoddloligocom" is not an existing username. Check the name or leave
that field blank." This appears to my untrained eye that the service
format is moving BACKWARDS into the anti-standards world of Skype, by
disallowing connectivity to any subscriber identifier that doesn't a
member. (Note: SIP URIs are inherently different than e164 numbers as
far as reliability goes, so my comments above re: trustworthiness of
endpoints are not contradictory to the desire to have URI dialing
capability.)
<br>
<br>
<br>
JT
<br>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<title></title>
<br>
Michael Robertson<br>
<a class="moz-txt-link-abbreviated" href="mailto:michael@linspire.com">michael@linspire.com</a> Read the latest Michael's Minute <a
href="http://www.lindows.com/mm">here</a><br>
<br>
<a href="http://www.linspire.com">Linspire</a> - World's Easiest
Desktop Linux<br>
<a href="http://www.sipphone.com">SIPphone</a> - Call worldwide for free<br>
<a href="http://www.mp3tunes.com/">MP3tunes</a> - Own your music, don't
rent it and listen anywhere with <a href="http://www.mp3beamer.com">MP3beamer</a><br>
</div>
</body>
</html>