Re: [reSIProcate] Registar behaviour

[Byron Campen <bcampen@xxxxxxxxxxxx>]

	Actually, repro does not have a BerkeleyDB or MySQL  
RegistrationPersistenceManager. It can persist _configuration_ using  
these, but it still uses the InMemoryRegistrationDatabase for  
registrations.

Best regards,
Byron Campen

> You have to implement subclass of ServerRegistrationHandler.
> Here there are some registration related callbacks.
> Use dum.setServerRegistrationHandler(...) next.
>
> Subclass from RegistrationPersistentManager to implement database  
> used to
> store registrations info.
> Use dum.setRegistrationPersistentManager(...) to setup.
>
> DUM library contains InMemoryRegistrationDatabase implementation of
> RegistrationPersistentManager interface.
>
> Repro project contains Berkeley and MySql implementations.
>
> Regards,
> Alex
>
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of  
> Nicolas
> LEGROS
> Sent: Monday, October 09, 2006 12:37 PM
> To: resiprocate-devel; Jean-Pierre HENEAU
> Subject: [reSIProcate] Registar behaviour
>
>
> Hi!
>
> I've a question concerning the behaviour of Resiprocate/DUM when  
> acting
> as a Registrar.
> When Resiprocate/DUM receives a Register from a SIP Phone:
> Will the stack ask the application (via a callback) if the  
> registration
> is accepted or refused?
> Or does the stack handle by itself the registration (which means that
> Resiprocate has its own database)?
>
> Thanks by advance,
>
> Nicolas L.
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel

Attachment: smime.p7s
Description: S/MIME cryptographic signature