Hi Bogdan, I tried with both "manual" and "auto". At the time this log was generated, I didn't set this parameter, assuming the "auto" as default.
Rgrds, Ricardo. Bogdan-Andrei Iancu escreveu: > Hi Ricardo, > > What from_restore_mode are you using ? > http://www.opensips.org/html/docs/modules/1.5.x/uac.html#id227233 > > Because indeed, the CANCEL is still using the old FROM: > > Jun 21 02:32:51 [3171] DBG:tm:build_local: using FROM=<From: "tronco2" > <sip:tron...@pabx1>;tag=as13631b36>, TO=<To: > <sip:556139659...@pabx1:5090>>, CSEQ_N=<CSeq: 102> > Jun 21 02:32:51 [3171] DBG:tm:cancel_branch: sending cancel... > > Regards, > Bogdan > > Ricardo Martins wrote: >> Hi Bogdan! There is attached a log with debug 6 of the call. There >> you can see the opensips using the original from to build the cancel >> message before transmiting to the provider. And lots of >> retransmissions without a response from the provider. >> >> The environment is quite simple: The opensips is running on a machine >> with two network interfaces. It receives the INVITE by the private >> network interface (192.168.200.246) and send it to a ppp0 interface >> with a fixed and public ip. >> >> For privacy reasons, I made the replacement of the public ip that >> appears on log and trace, using xxx.xxx.xxx.xxx instead. The original >> u...@domain of the call is tron...@pabx1 and, after replacement, >> [email protected]. >> >> Thanks for your help. I think that there is something tricky on my >> environment that is making this cancel to skip working "automagicaly". >> >> Regards! Ricardo. >> >> >> >> >> >> Bogdan-Andrei Iancu escreveu: >>> Hi Ricardo, >>> >>> >>> Ricardo Martins wrote: >>>> Guys, I've been reading a lot on the list and testing on our >>>> servers (opensips 1.5) for some time but I still have a big issue! >>>> >>>> 1) If I use uac_replace_from on REQUEST route, the from header got >>>> miswritten (truncates) when using it twice. Bad for me, when >>>> intended to use it to provide backup routes on a call failure. But... >>>> >>> yes, because the function can be called only once per branch - the >>> correct approach is the 2) >>>> 2) When I use uac_replace_from on BRANCH route, the replacement >>>> works realy fine. In order to use a backup provider, I just arm the >>>> branch_route and, on branch route, execute uac_replace_from with >>>> the proper username/domain for that specific provider. The result >>>> is ok. The from header is properly rewriten, many times I need at >>>> the same transaction. But... >>>> >>> so, no problems here, right ? >>>> 3) When opensips receives a CANCEL, it do not rewrite the from >>>> header, prior to send it to the provider. Neither using the >>>> uac_replace_from function, neither using subst function (from >>>> textops). I read that CANCEL is locally generated, and that's why >>>> those funcions do not affect it. I read too that the >>>> uac_replace_from used on INVITE was expected to work on CANCELs >>>> automaticaly. But apears to not work when using uac_replace_from on >>>> BRANCH routes. And I tryied it with from_restore_mode parameter on >>>> 'manual' and on 'auto' mode. >>>> >>> indeed, the CANCEL is internally generated, so whatever changes you >>> do for the received CANCEL in script are useless. But TM does >>> automagically update the FROM hdr in CANCELS (if the INVITE FROM was >>> changes), in any mode... If this does not happen, please post traces >>> and debug=6 logs for the call. >>> >>>> 4) Thats why I got a big of an issue! I MUST use the >>>> uac_replace_from on BRANCH routes to work with backup providers. >>>> And I MUST replace the from hdr of CANCEL, as my providers are >>>> rejecting CANCELs with diferent from headers! >>>> >>> you do not have to deal with the CANCELs - they automatically done.. >>> see 3) >>>> Do anybody could put this kind of environment to work? Have any >>>> clue about it? >>>> >>> >>> see 3), about traces and logs.. >>> >>> Regards, >>> Bogdan >>>> Regards! >>>> >>>> Ricardo. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> [email protected] >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>> >>> >> > > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
