[sr-dev] sip router and presence setup

Klaus Darilion klaus.mailinglists at pernau.at
Thu Jan 21 18:04:41 CET 2010


forgotten to cc the list :-)

Klaus Darilion schrieb:
> 
> 
> Aymeric Moizard schrieb:
>>
>>
>> On Thu, 21 Jan 2010, Klaus Darilion wrote:
>>
>>> Aymeric Moizard schrieb:
>>
>> [...]
>>
>>>> Last general question: What about mixing kamailio & ser? I've seen
>>>> for example modules with same namings: "auth" and "auth_db" in both
>>>> modules_s & modules_k: does this means we can use the same core but
>>>> have to choose between using modules_s or modules_k?
>>>
>>> You can mix, but not arbitrarily. The biggest difference between ser 
>>> and kamailio is the database structure. ser uses a new database 
>>> schema with numeric user-ids which map to SIP AoR. kamailio still 
>>> uses the old (ser 0.9.x) database schema where every user has a fixed 
>>> AoR.
>>>
>>> Therefore you can not mix modules which require different database 
>>> layouts.
>>>
>>> Thus, in your scenario you have to mix database layouts: 
>>> provisioning/location from ser and presence from kamailio. That might 
>>> work. But probably much easier would be to use kamailio modules only 
>>> (unless you need numeric user ids).
>>
>> Then my first comment would be: why have the "pa" been removed if it's
>> not possible to use the presence module from kamailio...
> 
> I think you can (I have not tried, but it should work, maybe needs some 
> tuning) - as presence tables are not related to provisioning/location 
> tables. But it is more work.
> 
>> In my mind, presence & presence_xml are using different independant 
>> database table and doesn't conflict with ser database?
>>
>> Most probably, there could be conflict with modules that depends
>> on usrloc for example? (like pua_usrloc) Looking at developper APIs,
>> for both usrloc kam/ser modules they are very close.
> 
> Agreed.
> 
>> I don't fully understand yet what "numeric user ids" are, but I would 
>> really like to use the ser database layout for 
>> user/location/credentials which seems really flexible compared to 
>> kamailio.
>>
>> So where sip-router is going? Do you target to have only the same
>> core for both kamailio & ser, but still be different projects?
> 
> There is already the same "core". But different database schema (used by 
> modules)
> 
>> Is having a common database layout an objective of the sip-router
>> project?
> 
> I think this is not agreed yet. But as it is planned to merge common 
> modules, this probably includes merging the schema too.
> 
> The problem is existing schemas. Although ser's schema is more flexible, 
> users avoid changing their existing schema (as this impacts the whole 
> provisioning/billing subsystems).
> 
>> If I intent to implement to additionnal event package, do you advise
>> me to stick with kamailio subscriber layout?
> 
> Do you need subscriber layout for the presence module? Maybe you can 
> describe your module a bit more.
> 
>> I finally understood why my "make deb" was compiling a ser version:
>> I just forgot to checkout the kamailio branch... That was also a
>> source of confusion for understanding why normal step for the
>> kamailio branch was to setup a ser database layout... Because
>> of that error, I though first the same layout was already used...
> 
> This is what I do to build kamailio:
> git clone ..uri...
> cd sip-router
> git branch --track kamailio_3.0 origin/kamailio_3.0
> git checkout kamailio_3.0
> make deb
> 
> regards
> klaus
> 
> 
>>
>> Tks,
>> Aymeric MOIZARD / ANTISIP
>> amsip - http://www.antisip.com
>> osip2 - http://www.osip.org
>> eXosip2 - http://savannah.nongnu.org/projects/exosip/
>>
>>
>>> regards
>>> klaus
>>>
>>>>
>>>> Tks much for your help & advise,
>>>>
>>>> Aymeric MOIZARD / ANTISIP
>>>> amsip - http://www.antisip.com
>>>> osip2 - http://www.osip.org
>>>> eXosip2 - http://savannah.nongnu.org/projects/exosip/
>>>>
>>>>
>>>> _______________________________________________
>>>> sr-dev mailing list
>>>> sr-dev at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>
> 



More information about the sr-dev mailing list