Hi Bogdan,
Thanks for replying. I have attached a debug level 4 log. I think it is complete enough.
In line 267-269 it shows:
Mar 25 21:42:23 [4001] DBG:uac:replace_from: removing display ["laobai"]
Mar 25 21:42:23 [4001] DBG:uac:replace_from: uri to replace
[sip:1234@172.19.172.101:5070]
Mar 25 21:42:23 [4001] DBG:uac:replace_from: replacement uri is
[sip:852133143235@172.19.172.176]
So till here From: is successfully replaced.
After that from 273 to 294:
Mar 25 21:42:23 [4001] DBG:tm:t_newtran: transaction on entrance=0xffffffff
Mar 25 21:42:23 [4001] DBG:core:parse_headers: flags=ffffffffffffffff
Mar 25 21:42:23 [4001] DBG:core:parse_headers: flags=78
Mar 25 21:42:23 [4001] DBG:tm:t_lookup_request: start searching: hash=55692, isACK=0
Mar 25 21:42:23 [4001] DBG:tm:matching_3261: RFC3261 transaction matching failed
Mar 25 21:42:23 [4001] DBG:tm:t_lookup_request: no transaction found
Mar 25 21:42:23 [4001] DBG:tm:t_lookupOriginalT: searching on hash entry 55692
Mar 25 21:42:23 [4001] DBG:tm:matching_3261: RFC3261 transaction matched,
tid=-d87543-912ace5f9f7da033-1--d87543-
Mar 25 21:42:23 [4001] DBG:tm:t_lookupOriginalT: canceled transaction found
(0xb5e83410)!
Mar 25 21:42:23 [4001] DBG:tm:t_lookupOriginalT: REF_UNSAFE: after is 1
Mar 25 21:42:23 [4001] DBG:tm:t_lookupOriginalT: t_lookupOriginalT completed
Mar 25 21:42:23 [4001] DBG:core:parse_headers: flags=ffffffffffffffff
Mar 25 21:42:23 [4001] DBG:core:check_via_address: params 172.19.172.176, 172.19.172.176,
0
Mar 25 21:42:23 [4001] DBG:core:_shm_resize: resize(0) called
Mar 25 21:42:23 [4001] DBG:tm:cleanup_uac_timers: RETR/FR timers reset
Mar 25 21:42:23 [4001] DBG:tm:insert_timer_unsafe: [2]: 0xb5e85cf0 (1133)
Mar 25 21:42:23 [4001] DBG:tm:_reply_light: reply sent out. buf=0x818a2f0: SIP/2.0 2...,
shmem=0xb5e876e8: SIP/2.0 2
Mar 25 21:42:23 [4001] DBG:tm:_reply_light: finished
Mar 25 21:42:23 [4001] DBG:tm:build_local: using FROM=<From:
"laobai"<sip:1234@172.19.172.101:5070>;tag=ea0e5c79
, TO=<To:
"85285523133"<sip:85285523133@172.19.172.101:5070>
, CSEQ_N=<CSeq: 1>
Mar 25 21:42:23 [4001] DBG:tm:cancel_branch: sending cancel...
So here The from is the one supposed to be removed "removing display
["laobai"]"
I'm not sure whether no transaction found is true or canceled transaction
found(0xb5e834100 stats the situation.
What I found is if I don't modify the From: it won't say no transaction found.
Thank you for your time and effort.
Best Regards,
Bai Shi
-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
Sent: 2008年3月25日 19:59
To: Bai Shi
Cc: Andreas Granig; Thomas Gelf; users(a)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@sipwise.com]
Sent: 2008年3月20日 1:34
To: Bogdan-Andrei Iancu
Cc: Bai Shi; Thomas Gelf; users(a)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(a)lists.openser.org
>>> [mailto:users-bounces@lists.openser.org] On Behalf Of Andreas Granig
>>> Sent: 2008年3月13日 2:54
>>> To: Thomas Gelf
>>> Cc: users(a)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@somedomain and from OpenSER to B it's
>>>>> sip:other-a@somedomain.
>>>>>
>>>>> If the call is cancelled, the From-header isn't altered, so the
>>>>> From from A to OpenSER is sip:a@somedomain and from OpenSER to B
>>>>> it's sip:a@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(a)lists.openser.org
>>>>
http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)lists.openser.org
>>>
http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)lists.openser.org
>>>
http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>
>>>