[OpenSER-Users] uac_replace_from and CANCEL

Bai Shi baishi at nus.edu.sg
Tue Mar 25 17:50:54 CET 2008


Hi Bogdan,
I have attached two log files, one is dump for 1.2.3 and the other is for 1.3.1
I also added packet capture with ngrep in the log file also.
Both config file symbolically linked to the same text file, and I'm calling from exactly the same client.

You can have a look at 1.2.3.txt, line 450 the cancel is sent out with From:"Laohei"
While in 1.3.1.txt, line 466 the cancel is sent out with From:"laobai"

As I first post in the mailing list, I don't know if this is a bug. And I worked around it via sending stateless.

However, I believe there is inconsistency between this two versions.

Thanks for the effort inspecting this.
Best Rgds,
Bai Shi
-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:bogdan at voice-system.ro] 
Sent: 2008年3月25日 19:59
To: Bai Shi
Cc: Andreas Granig; Thomas Gelf; users at openser.org
Subject: Re: [OpenSER-Users] uac_replace_from and CANCEL

Hi Bai Shi,

Andreas also confirmed to work properly (when not used from branch 
route), so it is not a bug, but maybe some cfg/scenario error.

Try placing the call (only the test one) and grab the full debug log 
from openser - post it somewhere and I will take a look.

Regards,
Bogdan

Bai Shi wrote:
> Hi Andreas,
> I called without any branches.
>
> Bogdan, I'd appreciate if you can spare sometime to look at this again.
> Rgds,
> Bai Shi
>
> -----Original Message-----
> From: Andreas Granig [mailto:agranig at sipwise.com] 
> Sent: 2008年3月20日 1:34
> To: Bogdan-Andrei Iancu
> Cc: Bai Shi; Thomas Gelf; users at openser.org
> Subject: Re: [OpenSER-Users] uac_replace_from and CANCEL
>
> Or, to be more specific, I call it from a route which is called by a 
> branch_route. Not sure if that matters.
>
> Andreas
>
> Andreas Granig wrote:
>   
>> 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 Users mailing list