[OpenSER-Users] uac_replace_from and CANCEL

Bogdan-Andrei Iancu bogdan at voice-system.ro
Tue Mar 25 13:00:21 CET 2008


Hi Andreas,

I guess this is also related to the improper usage of uac_replace_from() 
from branch route, right?

Regards,
Bogdan


Andreas Granig wrote:
> Hi again,
>
> This problem actually applies to the ACK for the 487 if the CANCEL as 
> well, and there it's even worse.
>
> RFC3261 says in 17.1.1.3:
> The ACK request constructed by the client transaction MUST contain
> values for the Call-ID, From, and Request-URI that are equal to the
> values of those header fields in the request passed to the transport
> by the client transaction
>
> On the other hand, in 17.2.3 it says regarding server transaction 
> matching:
> The ACK request matches a transaction if the Request-
> URI, From tag, Call-ID, CSeq number (not the method), and top Via
> header field match those of the INVITE request which created the
> transaction, and the To tag of the ACK matches the To tag of the
> response sent by the server transaction.
>
> Now if for some reason, the UAC in this case is OpenSER and the UAS is 
> a server which not only compares the From tag, but the overall 
> From-Header (like the Cisco PGW in version 9.6 seems to do), then both 
> of the parties don't behave correctly, and it's a little bit hard to 
> argue with vendors who has to move now.
>
> The real problem I have now is that for the CANCEL I can at least 
> manually replace From, but for ACK, OpenSER refuses to do so. In 
> "auto" mode, uac_replace_from bails out with "ERROR:uac:replace_from: 
> decline FROM replacing in sequential request in auto mode (has TO 
> tag)". In "manual" mode, it doesn't complain, but the From still isn't 
> replaced, and also an ugly hack like "remove_hf("From"); 
> insert_hf("From: $var(my_from_hdr)\r\n", "To");" has no effect.
>
> Any advice, since 1.3.1 doesn't seem to help also?
>
> Andreas
>
>
> 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