«

Using a Sipura-2100, firmware 3.1.2b

All parameters are as out-of-the-box, except the registration interval
(reduced from 3600 to 60 seconds).

Most of the time everything works fine, but sometimes, at a certain time
in the morning (around 7 o'clock), the ATA stops receiving registration
acknowledgements from the VoIP provider (Voipfone). After about 15
minutes without receiving acknowledgements the ATA stops trying to
register, and goes to sleep for 20 minutes. It then wakes up, tries
again to register, and is successful.

I am now in the process of trying to track down where the problem is
occurring -- is it in the ATA, or in the broadband network (NTL), or at
the VoIP provider?

However, as a side issue, when tracing the registration traffic between
the ATA and the provider, I've noticed something strange happening. Each
minute, the ATA sends a REGISTER request, but the provider always
rejects it. The ATA then immediately sends a second REGISTER request,
and this time the provider always accepts it. The only significant
difference I can see in the payload of the two requests is a difference
in the "branch" string. The first "branch" is obviously wrong, and the
second is right.

So, my question is -- what is the "branch" string, what sets it up, why
does the ATA get it wrong the first time, and how does it get it right
the second time?

--
Ian

"news" <> wrote in message
news:...
> Using a Sipura-2100, firmware 3.1.2b
>
> All parameters are as out-of-the-box, except the registration interval
> (reduced from 3600 to 60 seconds).

Why do you need the registration to be so regular?
3600 is about normal.

Derek

"Derek Knowles" <> wrote in message
news:
> "news" <> wrote in message
> news:...
> > Using a Sipura-2100, firmware 3.1.2b
> >
> > All parameters are as out-of-the-box, except the
> > registration interval (reduced from 3600 to 60 seconds).
>
> Why do you need the registration to be so regular?
> 3600 is about normal.

3600 is hourly. If you disconnect the ATA immediately or shortly after a
registration, the server won't realise you're not there any more until the
next registration interval has passed. This could result in calls not
being correctly routed to voicemail.

Ivor

Hi Ian,

I have also been having the same problems for some time.

I am using Voipfone and my ISP is Virgin (I believe service is NTL
based) through ADSL, BT provided line.

Always seems to be about the same time early in the morning, most odd.
My router is the sip aware intertex IX66.
I have 5 sip phones, Snom 360,2xSnom 220 and 2 Siemens optipoint
400's.
During the week I have tried each phone individually, siemens optipoint
400, snom 360, snom 220,each shows the same problem.
I have changed the registration time on the phones to 60 seconds as
suggested by Voipfone, the log from the phone (snom 360) and (snom 220)
seems to show it responds every 30 seconds!! , I have also changed
various settings in the Router to no avail.
It seems most odd, the other morning I made a call to Voipfone echo
test 152 at 07.00 and even though the Router's log showed a problem
the call connected perfectly, not tried incoming call yet during the
problem in the log.
Every morning the log from the Router shows a problem around, 6.30
through to 7.30!! No matter what phone is coupled up, the more phones
connected the more errors.
Yesterday the Routers log showed a similar problem during the afternoon
but for a much shorter time span.
During the day the log from the Intertex IX66 is near perfect, with
maybe the odd registration error at most.
I also tried registering the phone the other night with sipgate; it
only showed a rejected state once during the night and early morning.
Going back to when I used a Draytek router and a linksys router a
couple of months ago, some mornings the phone showed Password on the
display, just pressing cancel cleared the message. This has also
happened on the Intertex router so am assuming there was a registration
error similar to the ones I am still experiencing.
This one has really got me baffled!! I have reset the router completely
several times during the week rebooted the phones etc,etc, and seems to
make no difference!
To be honest it's not a major problem and the phones still work when
I need them but its rather intriguing why the problem occurs.

With regard to your side issue, I also have this, and was advised some
time ago this was normal behaviour for the SIP traces, snipped reply
below...

The unauthorised messages are part of SIP - they are normal. You try
to
register with no password, you get a unauthorised message with some
authentication keys. Then the phone md5 sums together these keys with
the password, and registers again.
In this way, your password is encrypted so that it can only be checked
by the server that sent the request - you could not reply the encrypted

password later.
That is the very simple explanation.



Hopefully some one will come up with an answer, any thoughts most
welcome.

All the best
John

Ivor Jones wrote:
>
> 3600 is hourly. If you disconnect the ATA immediately or shortly after a
> registration, the server won't realise you're not there any more until the
> next registration interval has passed. This could result in calls not
> being correctly routed to voicemail.
>
It shouldn't do if the service provider knows how to use their software.
What should happen is that it will try connecting to your previous IP,
fail to negotiate and return unavailable, then assuming the rules are
set correctly it should go to voicemail (since the Dial command will
return the Fail state).

I use 3600, purely because that (well 3585), is the highest number that
sipgate will let me negotiate.

If you have a static IP, it would be nicer if you could do away with the
registration business (as you can with gradwell) and just have the
remote machine be configured to forward to your IP. (painfully simple to
do even when writing scripts to modify config files/build them from a
database/use asterisk' ${DB(family/key)} function in your config files.
Assuming you are using something as flexible as asterisk.

news wrote:
> However, as a side issue, when tracing the registration traffic between
> the ATA and the provider, I've noticed something strange happening. Each
> minute, the ATA sends a REGISTER request, but the provider always
> rejects it. The ATA then immediately sends a second REGISTER request,
> and this time the provider always accepts it. The only significant
> difference I can see in the payload of the two requests is a difference
> in the "branch" string. The first "branch" is obviously wrong, and the
> second is right.

That is normal. It is how SIP works.

You try to register, you get rejected, the rejection includes a key
which you mix together with your password and then you try to register
again with the authentication details.


Tim

In message <43b97b91$0$87295$>, Tim Bray
<> writes
>news wrote:
>> However, as a side issue, when tracing the registration traffic
>>between the ATA and the provider, I've noticed something strange
>>happening. Each minute, the ATA sends a REGISTER request, but the
>>provider always rejects it. The ATA then immediately sends a second
>>REGISTER request, and this time the provider always accepts it. The
>>only significant difference I can see in the payload of the two
>>requests is a difference in the "branch" string. The first "branch"
>>is obviously wrong, and the second is right.
>
>That is normal. It is how SIP works.
>
>You try to register, you get rejected, the rejection includes a key
>which you mix together with your password and then you try to register
>again with the authentication details.
>

Thanks, Tim. The time has come to study the RFCs, I think.

--
Ian