Hi Kaiser, you mean you call twice the uac_replace_from() in failure_route for the same request? or for different ones?
because for a request/branch, you must call only once the uac_replace_from() function. Regards, Bogdan kaiser wrote: > Bogdan, > > After calling twice uac_replace_from() in failure route > > > the 200 OK reply restores the from header as > > Status-Line: SIP/2.0 200 OK > > Via: SIP/2.0/UDP > 63.28.2.7:5060;branch=z9hG4bK58da20a7bfb4a3161fe339136a58343d > Record-Route: > <sip:63.26.2.3;lr=on;ftag=3449301004-70991;did=246.22c92a05> > From: "k100" <sip:99910...@63.28.2.7:5060>;tag=3449301004-70991 > From: "k100" <sip:99910...@63.28.2.7:5060>;tag=3449301004-70991 > To: <sip:92140...@63.28.2.7:5060;transport=udp>;tag=as7b56bdb1 > Call-ID: 214351-3449301004-70...@msx1.mydomain.com > CSeq: 1 INVITE > User-Agent: IPPBX > > > There are 2 FROM hd in this message which from hdr restored. > > I try to find a way to output a trace in a compact format, it's long... > > best regards > kaiser > > > Bogdan-Andrei Iancu 提到: >> Hi Kaiser, >> >> kaiser wrote: >>> Bogdan, >>> >>> We have tested several ways: >>> >>> 1. use uac_replace_from in failure route only: >>> this make redundant "from" header in reply 200 OK. >> so you use it only in failure_route, this should be ok - what do you >> mean by redundant FROM hdr? can you post a trace ? >>> >>> 2. use uac_replace_from in request route and failure route: >>> It makes outgoping INVITE with strange from header. >> yes, this is is not correct. When doing uac_replace_from from request >> route, you do the change for all future branches. >> >> Regards, >> Bogdan >>> >>> br >>> kk >>> >>> >>> Bogdan-Andrei Iancu 提到: >>>> Hi KK, >>>> >>>> do you do uac_replace_from() in other routes than failure_route() ? >>>> like in request route when you process the request for the first time? >>>> >>>> Regards, >>>> Bogdan >>>> >>>> Gentrice's kaiser wrote: >>>>> Dear Sir: >>>>> >>>>> >>>>> I wrote a failure route for serial call mechanism, it help for no >>>>> answer call ... >>>>> but all these serial calls need to have a new CallerID, >>>>> so I use replace_from for this purpose. >>>>> >>>>> >>>>> >>>>> modparam("uac","from_restore_mode","auto") >>>>> >>>>> >>>>> failure_route[3] >>>>> { >>>>> log(1,"******* I'm failure_route[3] *******\n"); >>>>> >>>>> if (avp_pushto("$ru", "$avp(forward)")) >>>>> { >>>>> append_branch(); >>>>> avp_delete("$avp(forward)"); >>>>> uac_replace_from("sip:1...@$fd"); # change from header >>>>> t_on_failure("3"); # try next , recursive >>>>> >>>>> t_relay(); >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> If only one forward number in AVP array , this code working fine, >>>>> the issue will happen if multiple forward number trying, ( forward >>>>> 2nd,3rd ...number) >>>>> the UAC module will restore from header in 200 OK of its following >>>>> message when a UA answered, >>>>> we will have a duplicated "from header" in 200 OK (sending out >>>>> opensips). >>>>> It means we will have 2 "from" headers (in 200 OK) to caller, if >>>>> 2nd forwarded callee answer. >>>>> >>>>> Caller ---> Invite ---> opensips ----> UA 0, no answer >>>>> ----> UA 1, no answer >>>>> ---->UA 2, answer >>>>> <----200 OK >>>>> <---200OK<--- >>>>> >>>>> this 200ok will have 2 "from" header. >>>>> >>>>> >>>>> >>>>> Most of UA just ignore redundant from header, but some can not. >>>>> I think it should be UAC modules issue, anyone can help me? >>>>> >>>>> best regards >>>>> KK >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users@lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>> >>> >> > _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users