[SR-Users] Calling users on another kamailio server

Charles Chance charles.chance at sipcentric.com
Mon Sep 16 15:49:59 CEST 2013


It is possible if the edge proxy and registrar are separate, as you say.
But if the registrar is at the edge with no separate proxy, add_path() does
nothing (because the message never leaves Kamailio for the header to be
added).


On 16 September 2013 14:42, Peter Dunkley <peter.dunkley at crocodilertc.net>wrote:

> Is there any reason it isn't possible?
>
>
> On 16 September 2013 14:21, Charles Chance <charles.chance at sipcentric.com>wrote:
>
>> Hi,
>>
>> Yes, you are right - and I agree, it would be better if this was possible
>> :)
>>
>> Charles
>>
>>
>>
>>
>> On 16 September 2013 14:15, Peter Dunkley <peter.dunkley at crocodilertc.net
>> > wrote:
>>
>>> Hello,
>>>
>>> It'd be better if the "add_path()" function could be used here.  That
>>> way, if using outbound (RFC5626), the flow-token (the userinfo part of the
>>> Path-URI) would be present and there would be no need to add the
>>> ";received" parameter.
>>>
>>> This would address the one issue remaining for SIP outbound on Kamailio,
>>> which is its use without an edge proxy that is separate from the registrar.
>>>
>>> Regards,
>>>
>>> Peter
>>>
>>>
>>> On 16 September 2013 14:05, Charles Chance <
>>> charles.chance at sipcentric.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> This sounds like a case for sharing same database, and adding Path
>>>> before saving incoming register. That way, no need to replicate register
>>>> message to other servers and all subscribers use the same domain.
>>>>
>>>> Add path something like this before calling save():
>>>>
>>>>                         append_hf("Path: <sip:$Ri:$Rp;
>>>> received=sip:$si:$sp;lr>\r\n");
>>>>                         msg_apply_changes();
>>>>
>>>> Whichever server receives the incoming invite, will perform lookup and
>>>> automatically route to the server which received the register. On the
>>>> proxying server set $du according to received param of route header, add
>>>> record-route, and then t_relay(). As Daniel said, no need to
>>>> re-authenticate or perform lookup again.
>>>>
>>>> Regards,
>>>>
>>>> Charles
>>>>
>>>>
>>>>
>>>> On Mon, Sep 16, 2013 at 7:34 AM, Daniel-Constantin Mierla <
>>>> miconda at gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>>
>>>>> On 9/12/13 10:08 PM, Brian Wallen wrote:
>>>>>
>>>>>> I currently have two independent kamailio servers. I'd like to set
>>>>>> them up in a way that user1 on server1 can make a call to user2 on server2.
>>>>>> After searching I've come up with two ways that this might be able to be
>>>>>> done. Can someone please sanity check these or point me in the right
>>>>>> direction?
>>>>>>
>>>>>> 1. Have one registrar server and convert the other server to a proxy
>>>>>> 2. Keep them both as registrars and somehow make them each aware of
>>>>>> the users on the other server
>>>>>>
>>>>>> I like 2 better because if one server went down users on the other
>>>>>> server would still be up. The only thing is I don't know how to set the
>>>>>> servers up to communicate with each other.
>>>>>>
>>>>> the nat can create problems when a server is down - if the nat is
>>>>> symmetric, only the server that received the registrar can send back calls
>>>>> to the phone.
>>>>>
>>>>> Communication between users on two servers is as simple as using
>>>>> t_relay_to("proto:serverip:**port") after you do lookup("location")
>>>>> and no record is found.
>>>>
>>>>
>>>> Suppose I have three or more kamailio servers. If a call comes in and
>>>> lookup() returns that no record was found, how do I know which server to
>>>> forward to? Is that a case in which I should replicate the database?
>>>>
>>>>
>>>>> You have to add an extra check for the case the call was coming from
>>>>> the other server, not to forward back to it in case of no found again.
>>>>
>>>>
>>>> Thanks for the tip, I hadn't thought of that.
>>>>
>>>>
>>>>> Also, you should skip user authentication for calls from the other
>>>>> server (not do authenticate twice). Another aspect to take care is chaining
>>>>> rtpproxy, you have to use the flat for trusting the other server (r, iirc).
>>>>>
>>>>> You can also replicate the registration, but again, it can add
>>>>> troubles to the nat. Look at t_replicate() (in tm module).
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>>>> --
>>>>> Daniel-Constantin Mierla - http://www.asipto.com
>>>>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/**miconda<http://www.linkedin.com/in/miconda>
>>>>> Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
>>>>>   - more details about Kamailio trainings at http://www.asipto.com -
>>>>>
>>>>>
>>>>> ______________________________**_________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>>> sr-users at lists.sip-router.org
>>>>> http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**users<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>> www.sipcentric.com
>>>>
>>>> Follow us on twitter @sipcentric <http://twitter.com/sipcentric>
>>>>
>>>> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
>>>> office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham
>>>> B7 4EJ.
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>
>>>
>>> --
>>> Peter Dunkley
>>> Technical Director
>>>  Crocodile RCS Ltd
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>
>>
>> --
>> *Charles Chance*
>> Managing Director
>>
>> t. 0121 285 4400    m. 07932 063 891
>>
>> www.sipcentric.com
>>
>> Follow us on twitter @sipcentric <http://twitter.com/sipcentric>
>>
>> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
>> office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham
>> B7 4EJ.
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
>
> --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>


-- 
*Charles Chance*
Managing Director

t. 0121 285 4400    m. 07932 063 891

-- 
www.sipcentric.com

Follow us on twitter @sipcentric <http://twitter.com/sipcentric>

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered 
office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham 
B7 4EJ.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130916/c155bd0f/attachment.html>


More information about the sr-users mailing list