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@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@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@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@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@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