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:[EMAIL PROTECTED]:5070] Mar 25 21:42:23 [4001] DBG:uac:replace_from: replacement uri is [sip:[EMAIL PROTECTED] 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:[EMAIL PROTECTED]:5070>;tag=ea0e5c79 >, TO=<To: "85285523133"<sip:[EMAIL PROTECTED]: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:[EMAIL PROTECTED] Sent: 2008年3月25日 19:59 To: Bai Shi Cc: Andreas Granig; Thomas Gelf; [EMAIL PROTECTED] 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:[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 >>>>> [email protected] >>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>> _______________________________________________ >>>> Users mailing list >>>> [email protected] >>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> [email protected] >>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>>> >>>>
_______________________________________________ Users mailing list [email protected] http://lists.openser.org/cgi-bin/mailman/listinfo/users
