Hi,
Actually with 1.3.1 and calling uac_replace_from() NOT for a specific
branch, the From header in CANCEL and ACK are indeed updated correctly.
So the problem in my case was jumping to a route from within a
branch_route, and there calling uac_replace_from(). Calling
uac_replace_from() prior to t_relay() fixes my problems.
Thanks,
Andreas
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:[EMAIL PROTECTED] Sent: 2008年3月20日
>> 1:34
>> To: Bogdan-Andrei Iancu
>> Cc: Bai Shi; Thomas Gelf; [EMAIL PROTECTED]
>> 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: [EMAIL PROTECTED]
>>>>> [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Granig
>>>>> Sent: 2008年3月13日 2:54
>>>>> To: Thomas Gelf
>>>>> Cc: [EMAIL PROTECTED]
>>>>> 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:[EMAIL PROTECTED] and
>>>>>>> from OpenSER to B it's sip:[EMAIL PROTECTED]
>>>>>>>
>>>>>>> If the call is cancelled, the From-header isn't altered, so the
>>>>>>> From from A to OpenSER is sip:[EMAIL PROTECTED] and from OpenSER to B
>>>>>>> it's sip:[EMAIL PROTECTED] 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@lists.openser.org
>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users@lists.openser.org
>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users@lists.openser.org
>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>>
>
_______________________________________________
Users mailing list
Users@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
