[OpenSIPS-Users] Ways of manipulating the From header of CANCEL

Bogdan-Andrei Iancu bogdan at voice-system.ro
Tue Jun 23 11:57:35 CEST 2009


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:tronco2 at pabx1>;tag=as13631b36>, TO=<To: 
<sip:556139659184 at 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 
> user at domain of the call is tronco2 at pabx1 and, after replacement, 
> 617056557 at nheen.net.br.
>
> 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
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>   
>>
>>
>




More information about the Users mailing list