Am 16.09.2010 10:31, schrieb Daniel-Constantin Mierla:

Hi Klaus,

if you print the value of this avp before and after t_relay(), do you get different values?

t_relay does not even return for ACK:

if (is_method("INVITE")) { $avp(revdir) = 11; }

if (is_method("ACK")) { $avp(revdir) = 12; }

xlog("L_NOTICE","$rm before t_relay(): $$avp(revdir) = $avp(revdir) ...\n"); if (!t_relay()) { xlog("L_NOTICE"," t_relay() failed, sending stateless reply ...\n"); sl_reply_error(); } xlog("L_NOTICE","$rm after t_relay(): $$avp(revdir) = $avp(revdir) ...\n"); exit;

results in:

INVITE before t_relay(): $avp(revdir) = 11 ... INVITE after t_relay(): $avp(revdir) = 11 ... ACK has totag ... ACK has totag and is loose-routed ... ACK before t_relay(): $avp(revdir) = 12 ...

Thus, the xlog after t_relay() is not executed for ACK.

following is the log output of debug=4 during t_relay() of the ACK.

notice: NOTICE: <script>: ACK before t_relay(): $avp(revdir) = 12 ... debug: DEBUG: tm [t_lookup.c:1375]: DEBUG: t_newtran: msg id=1 , global msg id=0 , T on entrance=0xffffffff debug: DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=59956, isACK=1 debug: DEBUG: tm [t_lookup.c:720]: DEBUG: t_lookup_request: e2e proxy ACK found debug: DEBUG: tm [t_reply.c:276]: DEBUG: totag for e2e ACK found: 0 debug: DEBUG: tm [t_hooks.c:288]: DBG: trans=0xb323aa68, callback type 4, id 0 entered debug: DEBUG: pv [pv_core.c:853]: no destination URI debug: DEBUG: tm [t_funcs.c:315]: SER: forwarding ACK statelessly debug: DEBUG: <core> [msg_translator.c:200]: check_via_address(83.136.33.3, 10.10.0.51, 0) debug: DEBUG: <core> [forward.c:509]: Sending: ACK sip:123@83.136.32.20 SIP/2.0 Via: SIP/2.0/UDP 88.198.53.113;branch=0 Via: SIP/2.0/UDP 10.10.0.51:20854;received=83.136.33.3;branch=z9hG4bK-d8754z-e157d00da261e52b-1---d8754z-;rport=20854 Max-Forwards: 69 Contact: sip:user1@83.136.33.3:20854;transport=udp To: "123"sip:123@foobar;tag=as55bbb5b5 From: sip:user1@foobar;tag=5c57523a Call-ID: NGViYTU2MjFmZjgyYjA0YWMzNTMyNjU2NjFlYjM1MjI. CSeq: 1 ACK User-Agent: eyeBeam release 1102q stamp 51814 Content-Length: 0 . debug: DEBUG: <core> [forward.c:511]: orig. len=460, new_len=483, proto=1 debug: DEBUG: <core> [usr_avp.c:639]: DEBUG:destroy_avp_list: destroying list 0xb323c178 debug: DEBUG: <core> [usr_avp.c:639]: DEBUG:destroy_avp_list: destroying list (nil) debug: DEBUG: <core> [usr_avp.c:639]: DEBUG:destroy_avp_list: destroying list (nil) debug: DEBUG: <core> [usr_avp.c:639]: DEBUG:destroy_avp_list: destroying list (nil) debug: DEBUG: <core> [usr_avp.c:639]: DEBUG:destroy_avp_list: destroying list (nil) debug: DEBUG: <core> [usr_avp.c:639]: DEBUG:destroy_avp_list: destroying list (nil) debug: DEBUG: <core> [receive.c:280]: receive_msg: cleaning up

regards Klaus

On Sep 17, 2010 at 12:21, Daniel-Constantin Mierla miconda@gmail.com wrote:

Hello,

On 9/16/10 11:53 AM, Klaus Darilion wrote:

...

Am 16.09.2010 10:31, schrieb Daniel-Constantin Mierla:

...

Hi Klaus,

if you print the value of this avp before and after t_relay(), do you get different values?

t_relay does not even return for ACK:

interesting, I have to test this ...

Maybe Andrei has more insights about this behaviour with the tm from sip router.

t_relay() exits the script if called for an end2end ACK (this is the same as in kamilio <=1.5). What's different is that t_relay() _will_ _not_ exit the script for retransmissions or ACK to negative replies (but this is not related to the avp stuff).

For all the ACK processed by tm, the registered callbacks will be called with the corresponding INVITE transaction contexts as long as this is still available. This means that the ACK callbacks will see the avps setup for the INVITE and not the avps setup before t_relay(). This is a feature.

The same is true for retransmissions (the avps setup for the original transactions are seen inside the callbacks and not the ones setup in the script before t_relay()).

Note that the xlog() before and after t_relay() is irrelevant anyway (it would always print the same values even if the E2E ACK processing would not end the script) since the current avps do not change, the callbacks are just called with the original transaction context.

Andrei