8 Sep
2010
8 Sep
'10
2:58 p.m.
Hi!
I use acc module with extra accounting.
modparam("acc", "db_extra", "direction=$avp(direction)")
I set $avp(direction) during request processing (in main request route).
The value stored with INVITE and BYE is fine, but ACK requests do not
have the assigned value, but the same value as the INVITE request.
Is this by design? Is this a limitation of tm and AVPs?
Thanks
Klaus
16 Sep
16 Sep
11:31 a.m.
Hi Klaus,
if you print the value of this avp before and after t_relay(), do you
get different values?
Cheers,
Daniel
On 9/8/10 1:58 PM, Klaus Darilion wrote:
Hi!
I use acc module with extra accounting.
modparam("acc", "db_extra", "direction=$avp(direction)")
I set $avp(direction) during request processing (in main request route).
The value stored with INVITE and BYE is fine, but ACK requests do not
have the assigned value, but the same value as the INVITE request.
Is this by design? Is this a limitation of tm and AVPs?
Thanks
Klaus
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com
12:53 p.m.
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
17 Sep
17 Sep
1:21 p.m.
Hello,
On 9/16/10 11:53 AM, Klaus Darilion wrote:
Am 16.09.2010 10:31, schrieb Daniel-Constantin Mierla:
interesting, I have to test this ...
Maybe Andrei has more insights about this behaviour with the tm from sip
router.
Cheers,
Daniel
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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com
2:26 p.m.
On Sep 17, 2010 at 12:21, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
Hello,
On 9/16/10 11:53 AM, Klaus Darilion wrote:
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
Am 16.09.2010 10:31, schrieb Daniel-Constantin Mierla:
interesting, I have to test this ...
Maybe Andrei has more insights about this behaviour with the tm from sip
router. 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:
5183
days inactive
5192
days old
4 comments
3 participants
participants (3)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Klaus Darilion