[SR-Users] Calling users on another kamailio server

Mon Sep 16 16:04:07 CEST 2013

I thought append_hf() didn't take affect (unless you use
msg_apply_changes()) until the message left Kamailio too?

If that is the case, and msg_apply_changes() is called, doesn't that mean
the Path: header from add_path() would be added in that scenario?

On 16 September 2013 14:49, Charles Chance <charles.chance at sipcentric.com>wrote:

> 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.
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130916/4e486a6f/attachment-0001.html>