[sip-comm-dev] support for "NO REGISTRAR" accounts and direct calls


Hey folks,

Those of you listening on the SVN maling list. Might have noticed that
I've just committed support for serverless accounts and direct calls.

The feature is now available for testing in build 1414 (r4542). You can
create serverless accounts with the normal sip wizard. All you need to
do is *only* enter a user name (without the @ sign) so that the server
fields would remain empty.

Making calls from a no-registrar account should work as is, so simply
type in your dest URI and off you go.

E2E presence and instant messaging should also work as expected.

If you need to receive calls or messages however then keep in mind that
you need to check what port your account is bound on. Even though the it
would try to have 5060 by default it has no guarantee of succeeding and
may go to a random one. If that bothers you then delete all your other
sip accounts and then make sure you have no other SIP applications
running on your box.

I've tested the whole thing in a few situations so it should be
relatively stable. I do expect to have some glitches though, since my
priority was to make sure that standard accounts continue working as
they previously did.

A few notes on the implementation.

During the last few months we've had a lot of requests for that kind of
behaviour (both off and on list). Most of the people who asked were
research folk that needed this because not having a server greatly
simplifies testing protocol optimizations. I completely agree so I hope
you guys are happy now :wink:

The reason why this has taken so long is because not having a server
makes things a bit more complicated for double stack (IPv4 and IPv6) and
multihomed machines (which are not that rare nowadays). Contrary to what
one would expect from an application layer protocol, SIP does care a lot
about these things because of the Via, Contact, and (in the case of P2P
accounts) From fields.

So, having a registrar makes life easy because it adds the comfort of
always having a "control" connection. Pretty much like ftp does (thanks
for the analogy Enrico!). This way every time we need to put our IP
address somewhere we'd simply pick the one we currently use to
communicate with our registrar and leave difficult choices to our
routing table.

This is of course quite wrong but it was an easy hack so it seemed like
a nice compromise back at the time.

The right behaviour is of course always determining a source address
based on our destination. This means picking our IPv6 address for IPv6
destinations, the IP of our VPN tunnel for calls in the company network
and the address we have from our ISP for whatever needs to go to other
destinations. It does sound easy when you put it like this but it
required a lot of refactoring because that was not what we were
previously doing.

You probably know that Emanuel Onica and Michael Koch provided a patch
with an early version of this feature. Guys, your patch was very helpful
and many of my changes were based on ideas that were in there. It was
also quite comforting to know that someone has already been there so
I've also used it as a sanity check whenever in doubt! Thank you both!

Well I guess that's pretty much it. I am looking forward to your
comments although I expect to be pretty busy during the next few days.
Therefore, if you want to improve your chances of getting a bug fixed,
there's nothing like accompanying your report with a patch! :wink:



To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net