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
hi,
For once the RFC seems to be pretty strict in this matter ;) I have been creating sipp scenarios lately, the RFC describes exactly the behaviour I have encountered.
Further down it mentions the following:
If the UAS did not find a matching transaction for the CANCEL according to the procedure above, it SHOULD respond to the CANCEL with a 481 (Call Leg/Transaction Does Not Exist).
are you getting that back?
cheers,
Patrick.
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
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation. Information pursuant to paragraph 14 Austrian Companies Code: UPC Austria GmbH; Registered Office: Wolfganggasse 58-60, 1120 Vienna Company Register Number: FN 189858d at the Commercial Court of Vienna
Hi,
No, I don't, it's just dropped. But I just saw that the Thread "Is it a bug? TM module is sending CANCEL request regardless what the script do with the From Header since 1.3.0" describes the same problem. Let's continue discussion there.
Andreas
Patrick Miccio wrote:
hi,
For once the RFC seems to be pretty strict in this matter ;) I have been creating sipp scenarios lately, the RFC describes exactly the behaviour I have encountered.
Further down it mentions the following:
If the UAS did not find a matching transaction for the CANCEL according to the procedure above, it SHOULD respond to the CANCEL with a 481 (Call Leg/Transaction Does Not Exist).
are you getting that back?
cheers,
Patrick.
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
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation. Information pursuant to paragraph 14 Austrian Companies Code: UPC Austria GmbH; Registered Office: Wolfganggasse 58-60, 1120 Vienna Company Register Number: FN 189858d at the Commercial Court of Vienna
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
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
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
FULL ACK :o)
I'm doing similar things here: uac_replace_from combined with uac_auth, individual (not 1:1) credentials from db, AVPs etc etc... append_branch is useless in your case, you're right (I need it for uac_auth).
It would REALLY be great if this job would be done automagically *BIG HINT HINT* ;-p
Right now I'm struggling with all kinds of call forwarding. Conditional, unconditional, REFER, 3xy etc - getting only SOME of the possible scenarios working (also in combination with PSTN) is a big mess.
Christmas is still far, far away - otherwise I think I knew what to put on my wishlist ;-)
Regards, Thomas Gelf
Andreas Granig schrieb:
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
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
Hi Bai Shi,
I have been running some post-1.3 SVN release for a while, and 1.3.1 since yesterday on my test system. CANCEL behaves fine - even when combined with uac_replace_from. But note that in my setup I'm also authenticating each forwarded call with uac_auth - which may result in different behaviour, even if CANCEL is obviously not "uac_auth'ed".
Cheers, Thomas
Bai Shi schrieb:
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
Hi Thomas, First I think in ur config, rewritehostport won't work, coz t_relay will keep the same uri within one transaction, no matter what you do with it. Actually what I mean is if you modify to something different, it won't work. But for most of the cases, it won't cause problem, but it is simply redundant.
To Thomas and Bogdan:
I tested with 1.3.1 again, while 1.2.3 working perfectly, the 1.3.1 still refuse to do my trick. My openser.cfg contains something like this: route { ... if (method=="BYE" || method=="CANCEL") { xlog("L_NOTICE", "NON-LOOSEROUTE CANCLE OR BYE\n");
route(3); uac_replace_from("hello", "sip:1234@4567.com"); # remove_hf("From"); t_relay(); } } route(3) is my script to update sth in the db. Should have nothing to do with sip signaling. And my ngrep capture is as follows (I'm sorry I need to replace my gw addr to AABBCC according to company rule):
/* from my uac to openser */ U 172.19.171.63:51176 -> 172.19.172.101:5070 CANCEL sip:85281663973@172.19.172.101:5070 SIP/2.0..Via: SIP/2.0/UDP 172.19.171.63:51176;branch=z9hG4bK-d87543- a5171d5ac15be72b-1--d87543-;rport..To: "85281663973"sip:85281663973@172.19.172.101:5070..From: "laobai"<sip:12 34@172.19.172.101:5070>;tag=4a6c2236..Call-ID: 6a10b93eeb394e09YmQxNjQ4NDA1OTU1ZDgwYjg0ZTNmYjEzNjY2NWU5MGY...C Seq: 1 CANCEL..User-Agent: eyeBeam release 1003s stamp 31159..Content-Length: 0....
/* debug info here */ NON-LOOSEROUTE CANCLE OR BYE
/* automatic 1xx response by TM */ # U 172.19.172.101:5070 -> 172.19.171.63:51176 SIP/2.0 200 canceling..Via: SIP/2.0/UDP 172.19.171.63:51176;branch=z9hG4bK-d87543-a5171d5ac15be72b-1--d87543-; rport=51176..To: "85281663973"sip:85281663973@172.19.172.101:5070;tag=06c52d26462d9835792f0cb3537991da-7274..F rom: "laobai"sip:1234@172.19.172.101:5070;tag=4a6c2236..Call-ID: 6a10b93eeb394e09YmQxNjQ4NDA1OTU1ZDgwYjg0ZTN mYjEzNjY2NWU5MGY...CSeq: 1 CANCEL..Server: OpenSER (1.3.1-notls (i386/linux))..Content-Length: 0....
/* sending out by openser */ # U 172.19.172.101:5070 -> AABBCC:5060 CANCEL sip:85281663973@AABBCC:5060 SIP/2.0..Via: SIP/2.0/UDP 172.19.172.101:5070;branch=z9hG4bK4714.e86c 9a35.0..From: "laobai"sip:1234@172.19.172.101:5070;tag=4a6c2236..Call-ID: 6a10b93eeb394e09YmQxNjQ4NDA1OTU1ZD gwYjg0ZTNmYjEzNjY2NWU5MGY...To: "85281663973"sip:85281663973@172.19.172.101:5070..CSeq: 1 CANCEL..Max-Forwards : 70..User-Agent: OpenSER (1.3.1-notls (i386/linux))..Content-Length: 0....
Sorry for attach so much irritating dump, but if you can spare sometime, I'll appreciate your help very very much.
As you can see, the openser is sending out exactly the same From regardless the uac_replace_from(). "NON-LOOSEROUTE CANCLE OR BYE" should prove the execution of this block. The difference between mine and Thomas script is I'm not using append_branch(), to be frank, I'm quite blur when to use append_branch(), but I just tested with append_branch() added. It is the same result.
I'm quite frustrated now. Bogdan, I do beg ur reconfirmation about this. I know I may have made stupid mistake, if you find it please kindly point it out. Thank you very much for your time and effort.
Best Rgds, Bai shi
-----Original Message----- From: users-bounces@lists.openser.org [mailto:users-bounces@lists.openser.org] On Behalf Of Thomas Gelf Sent: 2008年3月13日 4:26 To: users@openser.org Subject: Re: [OpenSER-Users] uac_replace_from and CANCEL
Hi Bai Shi,
I have been running some post-1.3 SVN release for a while, and 1.3.1 since yesterday on my test system. CANCEL behaves fine - even when combined with uac_replace_from. But note that in my setup I'm also authenticating each forwarded call with uac_auth - which may result in different behaviour, even if CANCEL is obviously not "uac_auth'ed".
Cheers, Thomas
Bai Shi schrieb:
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
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
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
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
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
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@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
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: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
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@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
Hi Bogdan,
Not 100% sure since I haven't tested with 1.2.2 and uac_replace_from() NOT being called indirectly from branch_route.
What I can tell though is that with 1.3.1 and calling uac_replace_from from request_route, it works as expected.
Thanks for clarification, Andreas
Bogdan-Andrei Iancu wrote:
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@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
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
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
Sorry, something wrong with the log file. Resend...
-----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
Hi Bogdan, I have attached two log files, one is dump for 1.2.3 and the other is for 1.3.1 I also added packet capture with ngrep in the log file also. Both config file symbolically linked to the same text file, and I'm calling from exactly the same client.
You can have a look at 1.2.3.txt, line 450 the cancel is sent out with From:"Laohei" While in 1.3.1.txt, line 466 the cancel is sent out with From:"laobai"
As I first post in the mailing list, I don't know if this is a bug. And I worked around it via sending stateless.
However, I believe there is inconsistency between this two versions.
Thanks for the effort inspecting this. Best Rgds, 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
Oops, forgot to attach again....
-----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
Sorry to trouble all of you in the list. If any of you failed to receive the log file, it could be downloaded here: http://laohei.net/openser/1.2.3.txt http://laohei.net/openser/1.3.1.txt
Thanks. Rgds, 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
Hi Andreas,
uac_replace_from() is not supposed to be called from branch route (directly or not) - see the documentation. There are some limitation due lumps and flag propagation. Most sure this is the reason for not working correctly in your case.
For branch route support, there is patch/featur request on the tracker, but is not yet working properly.
Regards, Bogdan
Andreas Granig wrote:
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
-
Andreas Granig -
Bai Shi -
Bogdan-Andrei Iancu -
Patrick Miccio -
Thomas Gelf