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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**users<http:/…
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)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.