[Devel] non-invite server transactions are terminated too fast

[Bogdan-Andrei Iancu]

Hi,

REGISTER retransmission is a little bit tricky.

If you have a stateless configuration, you will not be able to detect 
retransmissions, so each request will be fully processed as a new one. 
Since we added the cseq checking in register module (according to rfc), 
the retransmissions will be reported as errors due invalid cseq no.
Solution: relax the register checking to accept equal cseq. 
Disadvantage: you still process each register even if it;s 
retransmission - partial solution: try sending an 100 trying once you 
received a REGISTER.

Also you my go for a statefull approach: you will catch all 
retransmissions, but it might have a negative impact on your memory 
usage. Use t_newtran() before save in order to create transactions and 
absorb retransmissions.

regards,
bogdan

Klaus Darilion wrote:

> Juha Heinanen wrote:
>
>> Bogdan-Andrei Iancu writes:
>>
>>  > check the hint hdr in the 400 reply - it may give you some hints. 
>> What I  > suspect it that you have a REGISTER retransmission hitting 
>> usrloc - it  > sees the same CSEQ and deny the registration.
>>
>> this is what is happening.  400 reply has header
>>
>> P-Registrar-Error: Invalid CSeq number
>>
>> but my point was, that re-transmitting register request is perfectly ok
>> and instead of replying with 400, openser should resend the 200 ok until
>> the transaction is terminated (after 32 secods).
>
>
> Thus I suspect the problem is the stateless REGISTER handling. IMO 
> this is bad. We often had problems with slow radius backends. This 
> caused REGISTER retransmissions which were not detected as 
> retransmission by openser and caused multiple radius requests blocking 
> all threads.
>
> I remember once there was patch for from Maxim for statefull REGISTER 
> handling. But there were also some problems which I can't remember now.
>
> regards
> klaus