[SR-Users] Calling users on another kamailio server

Brian Wallen bwallen at gmail.com
Mon Sep 16 15:22:14 CEST 2013


Thanks for the tips guys. I'll try them out today and report back.


On Mon, Sep 16, 2013 at 9:21 AM, 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130916/148d8bfe/attachment-0001.html>


More information about the sr-users mailing list