[asterisk-users] Bug with Realtime?

[Zeeshan Zakaria]

When making an outbound call, if sip peer is not registered, first it
registers itself, and then makes the call. This is why you don't see any
problem dialing out. For receiving, asterisk has to wait until the sip peer
registers, otherwise asterisk has nowhere to send the call.

I know the pain, as I deal with the same situation. So I don't do 'reload'
or 'sip reload' except if sip password (secret) has been changed, in which
case I prefer to use 'sip prune realtime peer <extension>' followed by 'sip
show peer <extension> load'. Most of the sip devices re-register every 60
seconds, or if they don't on a realtime network, depending upon the
bandwidth, they should be made to do so. Or in some cases you can send a
reboot signal to a sip device too. The bottom line is, try not to do a
'reload' as it would affect everybody else too by dropping their
registrations temporarily.

Zeeshan A Zakaria

--
www.ilovetovoip.com

On 2010-09-16 10:04 AM, "Peder" <peder at networkoblivion.com> wrote:

A reload flushes the SIP registration database, so once you do a reload,
that phones reg is gone.  If the reg is set for a short period, say 60
seconds, then in 60 seconds it will re-register and work fine.  Yes, it is a
total pain, but this is the way it has worked since day 1 for realtime.  I
agree that it seems wrong and even argued that several years ago when this
feature came out, but it is what it is.  As someone else said, the answer is
"don't do a 'reload'", do an "extensions reload" or whatever it is specific
to your changes.



-----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bo...

Sent: Thursday, September 16, 2010 8:44 AM
To: Asterisk Users Mailing List - Non-Commercial Discussi...

Subject: Re: [asterisk-users] Bug with Realtime?

> That's not a bug. Only when the phone registers ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100916/06f5b435/attachment.htm