[OpenSER-Users] uac_replace_from and CANCEL

Andreas Granig agranig at sipwise.com
Wed Mar 19 18:24:15 CET 2008


Bogdan,

I just tested with 1.3.1, and there the From of the CANCEL is also NOT 
updated. A probably not so unimportant side-note is that I call 
uac_replace_from() from a branch_route.

Andreas

Bogdan-Andrei Iancu wrote:
> Hi Bai Shi,
> 
> I just tested (to be sure no bugs are present) and in 1.3, the CANCELs 
> are automatically updated (the FROM header), as expected.
> 
> Regards,
> Bogdan
> 
> Bai Shi wrote:
>> Hi, Thomas,
>> This will do in openser 1.2, however, in openser 1.3 it won't do any 
>> help. The CANCEL will be sent out regardless what you have done to the 
>> request, but follow the information in the original INVITE. I tested 
>> it and suffered a lot ;(
>> Rgds,
>> BS
>>
>> -----Original Message-----
>> From: users-bounces at lists.openser.org 
>> [mailto:users-bounces at lists.openser.org] On Behalf Of Andreas Granig
>> Sent: 2008年3月13日 2:54
>> To: Thomas Gelf
>> Cc: users at openser.org
>> Subject: Re: [OpenSER-Users] uac_replace_from and CANCEL
>>
>> Hi Thomas,
>>
>> Yes, I'm doing it that way now (without that "append_branch()" 
>> though), but if you have an uuid-based setup where you fetch the uuid 
>> from the subscriber table during authentication of the INVITE and then 
>> with that uuid fetch dynamic data from the usr_preferences table to be 
>> used for "uac_rewrite_host()", then you have to do some work-arounds 
>> and hacks to get that data for the CANCEL as well, which could be 
>> quite a pain.
>>
>> So yes, it would be really great if this could be done automatically 
>> *hint hint* :)
>>
>> Andreas
>>
>> Thomas Gelf wrote:
>>  
>>> Applying uac_replace_from() to the CANCEL request should do the job,
>>> it sadly doesn't happen automagically :'-(
>>>
>>> Try something like:
>>>
>>>      if(is_method("CANCEL") && uri =~ "^sip:...")
>>>      {
>>>          if(t_check_trans())
>>>          {
>>>              rewritehostport("...");
>>>              uac_replace_from("...");
>>>              append_branch();
>>>          }
>>>          if(!t_relay())
>>>          {
>>>              sl_reply_error();
>>>          }
>>>      }
>>>
>>> Cheers,
>>> Thomas Gelf
>>>
>>> Andreas Granig schrieb:
>>>    
>>>> Hi,
>>>>
>>>> I hit another problem with a Cisco PGW in combination with CANCEL, 
>>>> and I'm not sure which fault it is. If I do uac_replace_from in the 
>>>> INVITE, the From-Header is altered somehow and sent to the PGW. So 
>>>> if A calls B where B is a PGW, the From from A to OpenSER is for 
>>>> example sip:a at somedomain and from OpenSER to B it's 
>>>> sip:other-a at somedomain.
>>>>
>>>> If the call is cancelled, the From-header isn't altered, so the From 
>>>> from A to OpenSER is sip:a at somedomain and from OpenSER to B it's 
>>>> sip:a at somedomain as well.
>>>>
>>>> Now the PGW seems to ignore this CANCEL, and I guess it's because of 
>>>> the different From-usernames, since it works if I don't do any 
>>>> uac_replace_from.
>>>>
>>>> RFC3261 says in §9.1:
>>>> The Request-URI, Call-ID, To, the numeric part of CSeq, and From header
>>>> fields in the CANCEL request MUST be identical to those in the
>>>> request being cancelled, including tags.
>>>>
>>>> So is it correct behavior of the PGW because the From header in the 
>>>> CANCEL is different from the From header in the INVITE? Should 
>>>> OpenSER alter the From in the CANCEL as well? Or should the PGW just 
>>>> check the  From tags, but not the From URI?
>>>>
>>>> Andreas
>>>>
>>>>       
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.openser.org
>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>     
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.openser.org
>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.openser.org
>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>   
> 




More information about the sr-users mailing list