[Serusers] stateless/statefull processing and INVITE method retransmissions

[Jan Janak]

Your description seems to be similar to what radius is doing, perhaps
you could use radius authentication ?

  Jan.

On 14-11 10:13, Michael Kaufmann wrote:
> Hi again,
> 
> I see that the registrar part of SER is using SL module.
> I am trying to build my own authentication - simply use the PRE_SCRIPT_CB 
> callback (without using the configuration file) to send some of the data in 
> SIP requests to my own server without reparsing the message.
> The problem occures when the user is not authorized - when the callback 
> return value is 0 no answer is sent back to the client, and I would like to 
> send him the not authorized reply.
> 
> How can it be done if the only way to hook request answers is using TM?
> 
> Another problem - I really didn't understand from the documentation if the 
> authentication module is able to do what I described above (my server might 
> be in another computer and has to be able to handle more than one SER - It 
> might even exchange data with the SIP clients)
> 
> Can someone give me an idea of how to implement the SER side module for 
> such a server?
> 
> 
> Thanks in advance,
> 
> Micky
> 
> 
> >From: Andrei Pelinescu-Onciul <pelinescu-onciul at fokus.fraunhofer.de>
> >To: Michael Kaufmann <mkaufmannn at hotmail.com>
> >CC: serusers at lists.iptel.org
> >Subject: Re: [Serusers] stateless/statefull processing and INVITE method 
> >retransmissions
> >Date: Fri, 12 Nov 2004 10:17:06 +0100
> >
> >On Nov 11, 2004 at 16:59, Michael Kaufmann <mkaufmannn at hotmail.com> wrote:
> >> Hi,
> >>
> >> Ser is pretty new to me (about 3 weeks of reading about it and working 
> >with
> >> it), so naturally I have some questions:  (attached - the configuration
> >> file I use)
> >>
> >> I saw many examples of configuration files were both SL and TM modules 
> >are
> >> loaded.
> >> In such cases is SL loaded only for REGISTER requests?
> >
> >sl is loaded for stateless replies. If you want to send only an error
> >reply and you haven't called any tm functions (t_newtran, t_rely) and
> >you are not in a failure route, it's faster to use sl_send_reply (it
> >doesn't make sense to keep state in this case).
> >
> >> How can I control which of SER actions are handled with TM and which are
> >> handled with SL?
> >
> >sl handles only stateless replies. If you want to send a request
> >statelessly use forward(uri:host, uri:port).
> >If you use t_relay instead of forward than you use tm.
> >
> >> Is there a way of hooking SER answers to requests without TM?
> >No.
> >
> >>
> >> As I understand from this mail archive - INVITE is a special case in SER
> >> and even though the client doesn't retramit such requests, SER does. Is
> >> there a way to avoid this retransmission? Is there a way to control the
> >> interval time between one retransmission to another?
> >
> >In statefull mode (TM), ser retransmits the request on behalf of the
> >client. THe retransmission stops when a reply is received or after some
> >timeout. The time between retransmissions is not constant, it increases.
> >See the sip rfc for more details (rfc3261).
> >>
> >> It seems that sometimes these retransmissions occure even after the ACK 
> >is
> >> returned...
> >
> >The INVITE retransmissions stops when a reply to it comes.
> >ACKs "control" the replies retransmissions. ACKs to INVITE positive
> >replies are handled a little differently than ACKs to negative replies.
> >You might have a non-matching ACK, or the ACK might not reach the
> >desired target.
> >
> >> Another starnge this is that my clients are on the same domain as the 
> >one
> >> SER is on and still record_route() seems to add many non usefull header
> >> lines for such INVITE messages.
> >
> >If you don't need record routing then don't use it.
> >
> >>
> >> Is it a problem with my configuration file?
> >>
> >
> >
> >Andrei
> 
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today it's FREE! 
> http://messenger.msn.com/
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers