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.cha...@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.dunk...@crocodilertc.net>wrote: > >> Is there any reason it isn't possible? >> >> >> On 16 September 2013 14:21, Charles Chance <charles.cha...@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.dunk...@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.cha...@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 < >>>>> mico...@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@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@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@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@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@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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users