Hi Bogdan,
Flag inheritance by the replies works.
I did not know that it was not supposed to work for the CANCEL. It is good to know because I was starting to loose my mind... Maybe a note somewhere in the project's site would be useful. It is very strange behaviour because t_check_trans() returns true which means that the CANCEL belongs to an existing transaction, but the flags are not the same as the original.
Last question: What about Re-INVITEs? The flags are not working there either? If this is true, then the only way to save some information about the transaction is to add it as a parameter in the contact? Or is there some other way?
Thank you.
Best regards
George
-----Original Message----- From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] Sent: Tuesday, October 30, 2007 6:07 AM To: Papadopoulos Georgios Cc: users@lists.openser.org Subject: Re: [OpenSER-Users] transaction flags not visible in CANCEL
Hi George,
There are two cases you are referring at:
- flags inheritance by the replies (set flag in INVITE and see it in
replies) - is this working?
- flags inheritance by the CANCEL (set flag in INVITE and
see it in CANCEL req/reply) - this is know not to work as so far the CANCEL was a different transaction then the INVITE, but starting with 1.3 it is the same, so it should be fixed.
Regards, Bogdan
Papadopoulos Georgios wrote:
Hello all,
I am running into a strange problem with message (or transaction) flags. I set a message flag while processing the INVITE,
but this flag
does not appear in any messages that belong to the same
transaction. I
discovered this while trying to resolved an issue with
Re-INVITEs. Now
I am testing it with a simple INVITE-CANCEL senario and I see that again the flag does not appear when processing the CANCEL.
My script
is pretty basic, at least for the CANCEL processing. The
debug output
is at the end of the email.
if (is_method("CANCEL")) { if (!t_check_trans()) { # Must be a CANCEL for atransaction that has
not been established. # Drop it and the client will resend it. exit; } else xlog("L_ERR","$rm: tran found flags=0x$mF bflags=0x$bF\n"); .... t_relay(); } Searching on the internet I came across this
http://openser.org/dokuwiki/doku.php/modules:1.2.x:t_check_trans_comme
nts
http://caravan5.webcrossing.com/People/emin-gabrielyan/public/070413-o
penser-transactions/
So what is the story? Am I doing something wrong?
thank you for any help
George
1(18475) SIP Request: 1(18475) method: <CANCEL> 1(18475) uri: sip:2116872933@altecnet.gr;user=phone 1(18475) version: <SIP/2.0> 1(18475) parse_headers: flags=2 1(18475) Found param type 232, <branch> = <z9hG4bK-mcodgtqb0696>; state=6 1(18475) Found param type 235, <rport> = <n/a>; state=17 1(18475) end of header reached, state=5 1(18475) parse_headers: Via found, flags=2 1(18475) parse_headers: this is the first via 1(18475) After parse_msg... 1(18475) preparing to run routing scripts... 1(18475) parse_headers: flags=100 1(18475) DEBUG:parse_to:end of header reached, state=10 1(18475) DBUG:parse_to: display={}, ruri={sip:2116872933@altecnet.gr;user=phone} 1(18475) DEBUG: get_hdr_field: <To> [41]; uri=[sip:2116872933@altecnet.gr;user=phone] 1(18475) DEBUG: to body [sip:2116872933@altecnet.gr;user=phone ] 1(18475) get_hdr_field: cseq <CSeq>: <2> <CANCEL> 1(18475) DEBUG:maxfwd:is_maxfwd_present: value = 70 1(18475) DBG:maxfwd:process_maxfwd_header: value 70 decreased to 10 1(18475) check_via_address(213.5.17.236, 213.5.17.236, 0) 1(18475) parse_headers: flags=80 1(18475) DEBUG: add_param: tag=b59u54s6kf 1(18475) DEBUG:parse_to:end of header reached, state=29 1(18475) DBUG:parse_to: display={"snom"}, ruri={sip:demo2@altecnet.gr} 1(18475) parse_headers: flags=200 1(18475) DEBUG: get_hdr_body : content_length=0 1(18475) found end of header 1(18475) find_first_route: No Route headers found 1(18475) loose_route: There is no Route HF 1(18475) grep_sock_info - checking if host==us: 11==10 && [altecnet.gr] == [213.5.43.4] 1(18475) grep_sock_info - checking if port 5060 matches port 5060 1(18475) grep_sock_info - checking if host==us: 11==10 && [altecnet.gr] == [213.5.43.7] 1(18475) grep_sock_info - checking if port 5060 matches port 5060 1(18475) grep_sock_info - checking if host==us: 11==10 && [altecnet.gr] == [213.5.43.8] 1(18475) grep_sock_info - checking if port 5060 matches port 5060 1(18475) grep_sock_info - checking if host==us: 11==10 && [altecnet.gr] == [213.5.43.9] 1(18475) grep_sock_info - checking if port 5060 matches port 5060 1(18475) grep_sock_info - checking if host==us: 11==12 && [altecnet.gr] == [172.31.100.5] 1(18475) grep_sock_info - checking if port 5060 matches port 5060 1(18475) parse_headers: flags=78 1(18475) DEBUG: t_lookupOriginalT: searching on hash entry 13236 1(18475) DEBUG: RFC3261 transaction matched, tid=-mcodgtqb0696 1(18475) DEBUG: t_lookupOriginalT: canceled transaction found (0xb616b3d8)! 1(18475) DEBUG:tm:REF_UNSAFE: after is 1 1(18475) DEBUG: t_lookupOriginalT completed 1(18475) CANCEL: tran found flags=0x00000000 bflags=0x00000000 1(18475) route9: CANCEL
sip:2116872933@altecnet.gr;user=phone <null>
fl=0x00000000 bfl=0x00000000 branch_id=0 1(18475) DEBUG: t_newtran: T on entrance=0xffffffff 1(18475) parse_headers: flags=ffffffffffffffff 1(18475) parse_headers: flags=78 1(18475) t_lookup_request: start searching: hash=13236, isACK=0 1(18475) DEBUG: RFC3261 transaction matching failed 1(18475) DEBUG: t_lookup_request: no transaction found 1(18475) DBG: trans=0xb616fc50, callback type 1, id 0 entered 1(18475) check_via_address(213.5.17.236, 213.5.17.236, 0) 1(18475) DEBUG:tm:set_timer: relative timeout is 1000000 1(18475) DEBUG: add_to_tail_of_timer[4]: 0xb616fd9c (5200000) 1(18475) DEBUG:tm:set_timer: relative timeout is 3 1(18475) DEBUG: add_to_tail_of_timer[0]: 0xb616fdb8 (7) 1(18475) DEBUG: e2e_cancel: e2e cancel proceeding 1(18475) parse_headers: flags=ffffffffffffffff 1(18475) check_via_address(213.5.17.236, 213.5.17.236, 0) 1(18475) WARNING:vqm_resize: resize(0) called 1(18475) DEBUG:tm:_reply_light: reply sent out. buf=0x817a358: SIP/2.0 2..., shmem=0xb6171780: SIP/2.0 2 1(18475) DEBUG:tm:_reply_light: finished 1(18475) DEBUG:tm:t_relay_to: new transaction fwd'ed 1(18475) DEBUG:tm:UNREF_UNSAFE: after is 0 1(18475) DEBUG:tm:UNREF_UNSAFE: after is 0 1(18475) DEBUG:destroy_avp_list: destroying list (nil) 1(18475) receive_msg: cleaning up
Disclaimer
The information in this e-mail and any attachments is
confidential. It
is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or person responsible for delivering this information to the intended
recipient,
please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it. E-mail transmission cannot be guaranteed to be
secure or
error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
--
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Hi George,
Papadopoulos Georgios wrote:
Hi Bogdan,
Flag inheritance by the replies works.
OK :)
I did not know that it was not supposed to work for the CANCEL. It is good to know because I was starting to loose my mind... Maybe a note somewhere in the project's site would be useful.
There was some statement about this here:
http://caravan5.webcrossing.com/People/emin-gabrielyan/public/070413-openser...
Otherwise, please update the wiki section about the flags.
It is very strange behaviour because t_check_trans() returns true which means that the CANCEL belongs to an existing transaction, but the flags are not the same as the original.
yes, it returns true as the CANCEL matches an existing INVITE transaction... It is a matter of how you say it :)
Last question: What about Re-INVITEs? The flags are not working there either? If this is true, then the only way to save some information about the transaction is to add it as a parameter in the contact? Or is there some other way?
re-INVITEs are different transaction and the flags are limited to transaction, so they will not be visible. If you add some information in the dialog, the best place is the RR (as you will get it all the time).
Regards, Bogdan
Thank you.
Best regards
George
-----Original Message----- From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] Sent: Tuesday, October 30, 2007 6:07 AM To: Papadopoulos Georgios Cc: users@lists.openser.org Subject: Re: [OpenSER-Users] transaction flags not visible in CANCEL
Hi George,
There are two cases you are referring at:
- flags inheritance by the replies (set flag in INVITE and see it in
replies) - is this working?
- flags inheritance by the CANCEL (set flag in INVITE and
see it in CANCEL req/reply) - this is know not to work as so far the CANCEL was a different transaction then the INVITE, but starting with 1.3 it is the same, so it should be fixed.
Regards, Bogdan
Papadopoulos Georgios wrote:
Hello all,
I am running into a strange problem with message (or transaction) flags. I set a message flag while processing the INVITE,
but this flag
does not appear in any messages that belong to the same
transaction. I
discovered this while trying to resolved an issue with
Re-INVITEs. Now
I am testing it with a simple INVITE-CANCEL senario and I see that again the flag does not appear when processing the CANCEL.
My script
is pretty basic, at least for the CANCEL processing. The
debug output
is at the end of the email.
if (is_method("CANCEL")) { if (!t_check_trans()) { # Must be a CANCEL for atransaction that has
not been established. # Drop it and the client will resend it. exit; } else xlog("L_ERR","$rm: tran found flags=0x$mF bflags=0x$bF\n"); .... t_relay(); } Searching on the internet I came across this
http://openser.org/dokuwiki/doku.php/modules:1.2.x:t_check_trans_comme
nts
http://caravan5.webcrossing.com/People/emin-gabrielyan/public/070413-o
penser-transactions/
So what is the story? Am I doing something wrong?
thank you for any help
George
1(18475) SIP Request: 1(18475) method: <CANCEL> 1(18475) uri: sip:2116872933@altecnet.gr;user=phone 1(18475) version: <SIP/2.0> 1(18475) parse_headers: flags=2 1(18475) Found param type 232, <branch> = <z9hG4bK-mcodgtqb0696>; state=6 1(18475) Found param type 235, <rport> = <n/a>; state=17 1(18475) end of header reached, state=5 1(18475) parse_headers: Via found, flags=2 1(18475) parse_headers: this is the first via 1(18475) After parse_msg... 1(18475) preparing to run routing scripts... 1(18475) parse_headers: flags=100 1(18475) DEBUG:parse_to:end of header reached, state=10 1(18475) DBUG:parse_to: display={}, ruri={sip:2116872933@altecnet.gr;user=phone} 1(18475) DEBUG: get_hdr_field: <To> [41]; uri=[sip:2116872933@altecnet.gr;user=phone] 1(18475) DEBUG: to body [sip:2116872933@altecnet.gr;user=phone ] 1(18475) get_hdr_field: cseq <CSeq>: <2> <CANCEL> 1(18475) DEBUG:maxfwd:is_maxfwd_present: value = 70 1(18475) DBG:maxfwd:process_maxfwd_header: value 70 decreased to 10 1(18475) check_via_address(213.5.17.236, 213.5.17.236, 0) 1(18475) parse_headers: flags=80 1(18475) DEBUG: add_param: tag=b59u54s6kf 1(18475) DEBUG:parse_to:end of header reached, state=29 1(18475) DBUG:parse_to: display={"snom"}, ruri={sip:demo2@altecnet.gr} 1(18475) parse_headers: flags=200 1(18475) DEBUG: get_hdr_body : content_length=0 1(18475) found end of header 1(18475) find_first_route: No Route headers found 1(18475) loose_route: There is no Route HF 1(18475) grep_sock_info - checking if host==us: 11==10 && [altecnet.gr] == [213.5.43.4] 1(18475) grep_sock_info - checking if port 5060 matches port 5060 1(18475) grep_sock_info - checking if host==us: 11==10 && [altecnet.gr] == [213.5.43.7] 1(18475) grep_sock_info - checking if port 5060 matches port 5060 1(18475) grep_sock_info - checking if host==us: 11==10 && [altecnet.gr] == [213.5.43.8] 1(18475) grep_sock_info - checking if port 5060 matches port 5060 1(18475) grep_sock_info - checking if host==us: 11==10 && [altecnet.gr] == [213.5.43.9] 1(18475) grep_sock_info - checking if port 5060 matches port 5060 1(18475) grep_sock_info - checking if host==us: 11==12 && [altecnet.gr] == [172.31.100.5] 1(18475) grep_sock_info - checking if port 5060 matches port 5060 1(18475) parse_headers: flags=78 1(18475) DEBUG: t_lookupOriginalT: searching on hash entry 13236 1(18475) DEBUG: RFC3261 transaction matched, tid=-mcodgtqb0696 1(18475) DEBUG: t_lookupOriginalT: canceled transaction found (0xb616b3d8)! 1(18475) DEBUG:tm:REF_UNSAFE: after is 1 1(18475) DEBUG: t_lookupOriginalT completed 1(18475) CANCEL: tran found flags=0x00000000 bflags=0x00000000 1(18475) route9: CANCEL
sip:2116872933@altecnet.gr;user=phone <null>
fl=0x00000000 bfl=0x00000000 branch_id=0 1(18475) DEBUG: t_newtran: T on entrance=0xffffffff 1(18475) parse_headers: flags=ffffffffffffffff 1(18475) parse_headers: flags=78 1(18475) t_lookup_request: start searching: hash=13236, isACK=0 1(18475) DEBUG: RFC3261 transaction matching failed 1(18475) DEBUG: t_lookup_request: no transaction found 1(18475) DBG: trans=0xb616fc50, callback type 1, id 0 entered 1(18475) check_via_address(213.5.17.236, 213.5.17.236, 0) 1(18475) DEBUG:tm:set_timer: relative timeout is 1000000 1(18475) DEBUG: add_to_tail_of_timer[4]: 0xb616fd9c (5200000) 1(18475) DEBUG:tm:set_timer: relative timeout is 3 1(18475) DEBUG: add_to_tail_of_timer[0]: 0xb616fdb8 (7) 1(18475) DEBUG: e2e_cancel: e2e cancel proceeding 1(18475) parse_headers: flags=ffffffffffffffff 1(18475) check_via_address(213.5.17.236, 213.5.17.236, 0) 1(18475) WARNING:vqm_resize: resize(0) called 1(18475) DEBUG:tm:_reply_light: reply sent out. buf=0x817a358: SIP/2.0 2..., shmem=0xb6171780: SIP/2.0 2 1(18475) DEBUG:tm:_reply_light: finished 1(18475) DEBUG:tm:t_relay_to: new transaction fwd'ed 1(18475) DEBUG:tm:UNREF_UNSAFE: after is 0 1(18475) DEBUG:tm:UNREF_UNSAFE: after is 0 1(18475) DEBUG:destroy_avp_list: destroying list (nil) 1(18475) receive_msg: cleaning up
Disclaimer
The information in this e-mail and any attachments is
confidential. It
is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or person responsible for delivering this information to the intended
recipient,
please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it. E-mail transmission cannot be guaranteed to be
secure or
error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
--
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-
Bogdan-Andrei Iancu -
Papadopoulos Georgios