[OpenSER-Users] transaction flags not visible in CANCEL
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Tue Oct 30 09:44:29 CET 2007
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-transactions/
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 at voice-system.ro]
>> Sent: Tuesday, October 30, 2007 6:07 AM
>> To: Papadopoulos Georgios
>> Cc: users at lists.openser.org
>> Subject: Re: [OpenSER-Users] transaction flags not visible in CANCEL
>>
>> Hi George,
>>
>> There are two cases you are referring at:
>>
>> 1) flags inheritance by the replies (set flag in INVITE and see it in
>> replies) - is this working?
>>
>> 2) 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 a
>>>
>> transaction 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 at 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 at altecnet.gr;user=phone}
>>> 1(18475) DEBUG: get_hdr_field: <To> [41];
>>> uri=[sip:2116872933 at altecnet.gr;user=phone]
>>> 1(18475) DEBUG: to body [<sip:2116872933 at 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 at 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 at 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 at lists.openser.org
>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>
>
More information about the sr-users
mailing list