Douglas Garstang wrote:
Ollie.
It's "Olle" :-)
I said it in a previous post. Just to make it clear... :) Realtime does not support
> having multiple Asterisk systems all accessing a central database for
SIP users/registration
> information. Digium have admitted it doesn't work and have said that
it will take the better part of a year to fix.
There are more developers out here than those that work for Digium.
And by the way, SIP users does *not* register in Asterisk.
Oh, and on the SIP result codes... how about all of them? Seriously, why not? Or maybe a function to check a SIP result code.
Can you please explain a bit more how that would help you?
/Olle
-----Original Message-----
From: Olle E. Johansson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 21, 2005 1:59 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] SIP Subscriptions
1. SIP subscriptions are stored in memory and cleared when you do a 'reload'.
So, if you make any configuration changes and 'reload' you lose all your BLF
lights. People take this stuff for granted and expect it to work.
I think we cleared that up in previous postings. Saving the
subscriptions in astDB as we save registrations might solve this issue.
2. No common SIP registration information. Not even using realtime with SIP
users, which doesn't work, there's no way outside this to share location info
between more than one (ie 'enterprise-grade') Asterisk systems.
Have you checked realtime SIP peers? We do save registration data in
the realtime database as well as the astDB. However, if you have NAT
between you and the device you need to make sure you send the call from
the proper IP.
3. The 'Dial' application seem to have very limited ability to be able to determine
what SIP response it gets back from a peer. "Not
Found", "Busy", "Moved" etc. I know Asterisk isn't a SIP proxy, but
without the ability to check the SIP message status in a dial, it makes
redundancy very very difficult. Redundancy is normally an important part
of 'enterprise-grade'. Without this, how do you get upstream redundancy?
I have something working right now, but it isn't pretty!
This is one of the effects of being a multiprotocol PBX. We have to
hide the protocol-layer specific signalling from the dialplan and
applications in order to behave in a common way.
Can you explain a bit more which SIP error codes that you want
to reach and why? Im curious.
4. DNS SRV lookups aren't implemented properly. Another important part of
redundancy and 'enterprise-grade' software.
This is a well known and well documented bug in Asterisk. It's not easy
to fix, believe me, I've tried for a long time. The new DNS manager is a
way forward and many of the core developers are trying to build a
foundation to solve this issue once and for all.
/O
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
