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. 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(a)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: _______________________________________________ Users mailing list Users(a)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: _______________________________________________ Users mailing list Users(a)lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

Hi, Thomas, This will do in openser 1.2, however, in openser 1.3 it won't do any help. The CANCEL will be sent out regardless what you have done to the request, but follow the information in the original INVITE. I tested it and suffered a lot ;( Rgds, BS -----Original Message----- From: users-bounces(a)lists.openser.org [mailto:users-bounces@lists.openser.org] On Behalf Of Andreas Granig Sent: 2008年3月13日 2:54 To: Thomas Gelf Cc: users(a)openser.org Subject: Re: [OpenSER-Users] uac_replace_from and CANCEL Hi Thomas, Yes, I'm doing it that way now (without that "append_branch()" though), but if you have an uuid-based setup where you fetch the uuid from the subscriber table during authentication of the INVITE and then with that uuid fetch dynamic data from the usr_preferences table to be used for "uac_rewrite_host()", then you have to do some work-arounds and hacks to get that data for the CANCEL as well, which could be quite a pain. So yes, it would be really great if this could be done automatically *hint hint* :) Andreas Thomas Gelf wrote: > Applying uac_replace_from() to the CANCEL request should do the job, > it sadly doesn't happen automagically :'-( > > Try something like: > > if(is_method("CANCEL") && uri =~ "^sip:...") > { > if(t_check_trans()) > { > rewritehostport("..."); > uac_replace_from("..."); > append_branch(); > } > if(!t_relay()) > { > sl_reply_error(); > } > } > > Cheers, > Thomas Gelf > > Andreas Granig schrieb: >> Hi, >> >> I hit another problem with a Cisco PGW in combination with CANCEL, and >> I'm not sure which fault it is. If I do uac_replace_from in the INVITE, >> the From-Header is altered somehow and sent to the PGW. So if A calls B >> where B is a PGW, the From from A to OpenSER is for example >> sip:a@somedomain and from OpenSER to B it's sip:other-a@somedomain. >> >> If the call is cancelled, the From-header isn't altered, so the From >> from A to OpenSER is sip:a@somedomain and from OpenSER to B it's >> sip:a@somedomain as well. >> >> Now the PGW seems to ignore this CANCEL, and I guess it's because of the >> different From-usernames, since it works if I don't do any uac_replace_from. >> >> RFC3261 says in §9.1: >> The Request-URI, Call-ID, To, the numeric part of CSeq, and From header >> fields in the CANCEL request MUST be identical to those in the >> request being cancelled, including tags. >> >> So is it correct behavior of the PGW because the From header in the >> CANCEL is different from the From header in the INVITE? Should OpenSER >> alter the From in the CANCEL as well? Or should the PGW just check the >> From tags, but not the From URI? >> >> Andreas

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:

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 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 guess this is also related to the improper usage of uac_replace_from() from branch route, right? Regards, Bogdan Andreas Granig wrote:

, TO=<To: "85285523133"<sip:85285523133@172.19.172.101:5070> , CSEQ_N=<CSeq: 1>

Hi Andreas, I called without any branches. Bogdan, I'd appreciate if you can spare sometime to look at this again. Rgds, Bai Shi -----Original Message----- From: Andreas Granig [mailto:agranig@sipwise.com] Sent: 2008年3月20日 1:34 To: Bogdan-Andrei Iancu Cc: Bai Shi; Thomas Gelf; users(a)openser.org Subject: Re: [OpenSER-Users] uac_replace_from and CANCEL Or, to be more specific, I call it from a route which is called by a branch_route. Not sure if that matters. Andreas Andreas Granig wrote: > Bogdan, > > I just tested with 1.3.1, and there the From of the CANCEL is also NOT > updated. A probably not so unimportant side-note is that I call > uac_replace_from() from a branch_route. > > Andreas > > Bogdan-Andrei Iancu wrote: > >> Hi Bai Shi, >> >> I just tested (to be sure no bugs are present) and in 1.3, the CANCELs >> are automatically updated (the FROM header), as expected. >> >> Regards, >> Bogdan >> >> Bai Shi wrote: >> >>> Hi, Thomas, >>> This will do in openser 1.2, however, in openser 1.3 it won't do any >>> help. The CANCEL will be sent out regardless what you have done to >>> the request, but follow the information in the original INVITE. I >>> tested it and suffered a lot ;( >>> Rgds, >>> BS >>> >>> -----Original Message----- >>> From: users-bounces(a)lists.openser.org >>> [mailto:users-bounces@lists.openser.org] On Behalf Of Andreas Granig >>> Sent: 2008年3月13日 2:54 >>> To: Thomas Gelf >>> Cc: users(a)openser.org >>> Subject: Re: [OpenSER-Users] uac_replace_from and CANCEL >>> >>> Hi Thomas, >>> >>> Yes, I'm doing it that way now (without that "append_branch()" >>> though), but if you have an uuid-based setup where you fetch the uuid >>> from the subscriber table during authentication of the INVITE and >>> then with that uuid fetch dynamic data from the usr_preferences table >>> to be used for "uac_rewrite_host()", then you have to do some >>> work-arounds and hacks to get that data for the CANCEL as well, which >>> could be quite a pain. >>> >>> So yes, it would be really great if this could be done automatically >>> *hint hint* :) >>> >>> Andreas >>> >>> Thomas Gelf wrote: >>> >>> >>>> Applying uac_replace_from() to the CANCEL request should do the job, >>>> it sadly doesn't happen automagically :'-( >>>> >>>> Try something like: >>>> >>>> if(is_method("CANCEL") && uri =~ "^sip:...") >>>> { >>>> if(t_check_trans()) >>>> { >>>> rewritehostport("..."); >>>> uac_replace_from("..."); >>>> append_branch(); >>>> } >>>> if(!t_relay()) >>>> { >>>> sl_reply_error(); >>>> } >>>> } >>>> >>>> Cheers, >>>> Thomas Gelf >>>> >>>> Andreas Granig schrieb: >>>> >>>> >>>>> Hi, >>>>> >>>>> I hit another problem with a Cisco PGW in combination with CANCEL, >>>>> and I'm not sure which fault it is. If I do uac_replace_from in the >>>>> INVITE, the From-Header is altered somehow and sent to the PGW. So >>>>> if A calls B where B is a PGW, the From from A to OpenSER is for >>>>> example sip:a@somedomain and from OpenSER to B it's >>>>> sip:other-a@somedomain. >>>>> >>>>> If the call is cancelled, the From-header isn't altered, so the >>>>> From from A to OpenSER is sip:a@somedomain and from OpenSER to B >>>>> it's sip:a@somedomain as well. >>>>> >>>>> Now the PGW seems to ignore this CANCEL, and I guess it's because >>>>> of the different From-usernames, since it works if I don't do any >>>>> uac_replace_from. >>>>> >>>>> RFC3261 says in §9.1: >>>>> The Request-URI, Call-ID, To, the numeric part of CSeq, and From >>>>> header >>>>> fields in the CANCEL request MUST be identical to those in the >>>>> request being cancelled, including tags. >>>>> >>>>> So is it correct behavior of the PGW because the From header in the >>>>> CANCEL is different from the From header in the INVITE? Should >>>>> OpenSER alter the From in the CANCEL as well? Or should the PGW >>>>> just check the From tags, but not the From URI? >>>>> >>>>> Andreas >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)lists.openser.org >>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)lists.openser.org >>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)lists.openser.org >>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>> >>>

Hi Andreas, I called without any branches. Bogdan, I'd appreciate if you can spare sometime to look at this again. Rgds, Bai Shi -----Original Message----- From: Andreas Granig [mailto:agranig@sipwise.com] Sent: 2008年3月20日 1:34 To: Bogdan-Andrei Iancu Cc: Bai Shi; Thomas Gelf; users(a)openser.org Subject: Re: [OpenSER-Users] uac_replace_from and CANCEL Or, to be more specific, I call it from a route which is called by a branch_route. Not sure if that matters. Andreas Andreas Granig wrote: > Bogdan, > > I just tested with 1.3.1, and there the From of the CANCEL is also NOT > updated. A probably not so unimportant side-note is that I call > uac_replace_from() from a branch_route. > > Andreas > > Bogdan-Andrei Iancu wrote: > >> Hi Bai Shi, >> >> I just tested (to be sure no bugs are present) and in 1.3, the CANCELs >> are automatically updated (the FROM header), as expected. >> >> Regards, >> Bogdan >> >> Bai Shi wrote: >> >>> Hi, Thomas, >>> This will do in openser 1.2, however, in openser 1.3 it won't do any >>> help. The CANCEL will be sent out regardless what you have done to >>> the request, but follow the information in the original INVITE. I >>> tested it and suffered a lot ;( >>> Rgds, >>> BS >>> >>> -----Original Message----- >>> From: users-bounces(a)lists.openser.org >>> [mailto:users-bounces@lists.openser.org] On Behalf Of Andreas Granig >>> Sent: 2008年3月13日 2:54 >>> To: Thomas Gelf >>> Cc: users(a)openser.org >>> Subject: Re: [OpenSER-Users] uac_replace_from and CANCEL >>> >>> Hi Thomas, >>> >>> Yes, I'm doing it that way now (without that "append_branch()" >>> though), but if you have an uuid-based setup where you fetch the uuid >>> from the subscriber table during authentication of the INVITE and >>> then with that uuid fetch dynamic data from the usr_preferences table >>> to be used for "uac_rewrite_host()", then you have to do some >>> work-arounds and hacks to get that data for the CANCEL as well, which >>> could be quite a pain. >>> >>> So yes, it would be really great if this could be done automatically >>> *hint hint* :) >>> >>> Andreas >>> >>> Thomas Gelf wrote: >>> >>> >>>> Applying uac_replace_from() to the CANCEL request should do the job, >>>> it sadly doesn't happen automagically :'-( >>>> >>>> Try something like: >>>> >>>> if(is_method("CANCEL") && uri =~ "^sip:...") >>>> { >>>> if(t_check_trans()) >>>> { >>>> rewritehostport("..."); >>>> uac_replace_from("..."); >>>> append_branch(); >>>> } >>>> if(!t_relay()) >>>> { >>>> sl_reply_error(); >>>> } >>>> } >>>> >>>> Cheers, >>>> Thomas Gelf >>>> >>>> Andreas Granig schrieb: >>>> >>>> >>>>> Hi, >>>>> >>>>> I hit another problem with a Cisco PGW in combination with CANCEL, >>>>> and I'm not sure which fault it is. If I do uac_replace_from in the >>>>> INVITE, the From-Header is altered somehow and sent to the PGW. So >>>>> if A calls B where B is a PGW, the From from A to OpenSER is for >>>>> example sip:a@somedomain and from OpenSER to B it's >>>>> sip:other-a@somedomain. >>>>> >>>>> If the call is cancelled, the From-header isn't altered, so the >>>>> From from A to OpenSER is sip:a@somedomain and from OpenSER to B >>>>> it's sip:a@somedomain as well. >>>>> >>>>> Now the PGW seems to ignore this CANCEL, and I guess it's because >>>>> of the different From-usernames, since it works if I don't do any >>>>> uac_replace_from. >>>>> >>>>> RFC3261 says in §9.1: >>>>> The Request-URI, Call-ID, To, the numeric part of CSeq, and From >>>>> header >>>>> fields in the CANCEL request MUST be identical to those in the >>>>> request being cancelled, including tags. >>>>> >>>>> So is it correct behavior of the PGW because the From header in the >>>>> CANCEL is different from the From header in the INVITE? Should >>>>> OpenSER alter the From in the CANCEL as well? Or should the PGW >>>>> just check the From tags, but not the From URI? >>>>> >>>>> Andreas >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)lists.openser.org >>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)lists.openser.org >>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)lists.openser.org >>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>> >>>

Hi Andreas, I called without any branches. Bogdan, I'd appreciate if you can spare sometime to look at this again. Rgds, Bai Shi -----Original Message----- From: Andreas Granig [mailto:agranig@sipwise.com] Sent: 2008年3月20日 1:34 To: Bogdan-Andrei Iancu Cc: Bai Shi; Thomas Gelf; users(a)openser.org Subject: Re: [OpenSER-Users] uac_replace_from and CANCEL Or, to be more specific, I call it from a route which is called by a branch_route. Not sure if that matters. Andreas Andreas Granig wrote: > Bogdan, > > I just tested with 1.3.1, and there the From of the CANCEL is also NOT > updated. A probably not so unimportant side-note is that I call > uac_replace_from() from a branch_route. > > Andreas > > Bogdan-Andrei Iancu wrote: > >> Hi Bai Shi, >> >> I just tested (to be sure no bugs are present) and in 1.3, the CANCELs >> are automatically updated (the FROM header), as expected. >> >> Regards, >> Bogdan >> >> Bai Shi wrote: >> >>> Hi, Thomas, >>> This will do in openser 1.2, however, in openser 1.3 it won't do any >>> help. The CANCEL will be sent out regardless what you have done to >>> the request, but follow the information in the original INVITE. I >>> tested it and suffered a lot ;( >>> Rgds, >>> BS >>> >>> -----Original Message----- >>> From: users-bounces(a)lists.openser.org >>> [mailto:users-bounces@lists.openser.org] On Behalf Of Andreas Granig >>> Sent: 2008年3月13日 2:54 >>> To: Thomas Gelf >>> Cc: users(a)openser.org >>> Subject: Re: [OpenSER-Users] uac_replace_from and CANCEL >>> >>> Hi Thomas, >>> >>> Yes, I'm doing it that way now (without that "append_branch()" >>> though), but if you have an uuid-based setup where you fetch the uuid >>> from the subscriber table during authentication of the INVITE and >>> then with that uuid fetch dynamic data from the usr_preferences table >>> to be used for "uac_rewrite_host()", then you have to do some >>> work-arounds and hacks to get that data for the CANCEL as well, which >>> could be quite a pain. >>> >>> So yes, it would be really great if this could be done automatically >>> *hint hint* :) >>> >>> Andreas >>> >>> Thomas Gelf wrote: >>> >>> >>>> Applying uac_replace_from() to the CANCEL request should do the job, >>>> it sadly doesn't happen automagically :'-( >>>> >>>> Try something like: >>>> >>>> if(is_method("CANCEL") && uri =~ "^sip:...") >>>> { >>>> if(t_check_trans()) >>>> { >>>> rewritehostport("..."); >>>> uac_replace_from("..."); >>>> append_branch(); >>>> } >>>> if(!t_relay()) >>>> { >>>> sl_reply_error(); >>>> } >>>> } >>>> >>>> Cheers, >>>> Thomas Gelf >>>> >>>> Andreas Granig schrieb: >>>> >>>> >>>>> Hi, >>>>> >>>>> I hit another problem with a Cisco PGW in combination with CANCEL, >>>>> and I'm not sure which fault it is. If I do uac_replace_from in the >>>>> INVITE, the From-Header is altered somehow and sent to the PGW. So >>>>> if A calls B where B is a PGW, the From from A to OpenSER is for >>>>> example sip:a@somedomain and from OpenSER to B it's >>>>> sip:other-a@somedomain. >>>>> >>>>> If the call is cancelled, the From-header isn't altered, so the >>>>> From from A to OpenSER is sip:a@somedomain and from OpenSER to B >>>>> it's sip:a@somedomain as well. >>>>> >>>>> Now the PGW seems to ignore this CANCEL, and I guess it's because >>>>> of the different From-usernames, since it works if I don't do any >>>>> uac_replace_from. >>>>> >>>>> RFC3261 says in §9.1: >>>>> The Request-URI, Call-ID, To, the numeric part of CSeq, and From >>>>> header >>>>> fields in the CANCEL request MUST be identical to those in the >>>>> request being cancelled, including tags. >>>>> >>>>> So is it correct behavior of the PGW because the From header in the >>>>> CANCEL is different from the From header in the INVITE? Should >>>>> OpenSER alter the From in the CANCEL as well? Or should the PGW >>>>> just check the From tags, but not the From URI? >>>>> >>>>> Andreas >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)lists.openser.org >>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)lists.openser.org >>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)lists.openser.org >>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>> >>>