I've been trying to track this issue down myself for the last two days but it appears the value is coming from somewhere in the tm module or somewhere else lower than that, which I haven't worked with at all. I have siptrace turned on and I'm using the destination port from the HEPv2 header but it seems to always come to me as 5060 even if the packet is actually sent to a different port (such as 51000). I'm able to reproduce this with my Polycom phone by having two registrations (one UDP and …
[View More]one TCP) going through a Kamailio server from the same phone. It looks like the first request comes from 5060 and is responded to on 5060, but the second connection comes from a random port on the phone (let's say 35000). When the reply (such as a 200) comes back from the server sitting behind the Kamailio proxy, the siptrace HEP header says the packet is going back to 5060 when it's actually being sent to 35000. I'm not even sure where the 5060 value is coming from in the first place
.
I've tracked the '5060' value to `t.uas.response.dst.to.sin.sin_port` in `t_reply.c:reply_received()` but the value of `t` is retrieved from `get_t()` and I'm not sure where that's added to the hash table in the first place. I can see the actual value of the destination port with `t.uas.request.rcv.src_port` within that same `t_reply.c:reply_received()` but I can't figure out how to get that value into the destination port at the source.
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/581
[View Less]
When I use get_body_part on a multipart body, it doesn't detect properly the ending of multipart headers:
For instance in:
```
--vvemeemm0wqr7ayc5h367f3v8e66mc9t
Content-Type: application/sdp
Content-Length: 479
v=0
o=- 3669362310 3669362310 IN IP4 192.168.2.4
[...]
```
"Content-Length: 479" is taken into get_body_part("application/sdp", "$var(sdp)");
I will try to provide more details later.
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly …
[View More]or view it on GitHub:
https://github.com/kamailio/kamailio/issues/564
[View Less]
The sipcapture module works great when you send hepv3 packets over the UDP transport however if kamailio start listening those hepv3 packtes on TCP and sending those hepv3 on TCP it will concern about it.
**This is what Kamilio receives over TCP.**
> T 52.10.155.177:47283 -> 172.19.8.21:9060 [AP]
> HEP3.0...................
> .........
> ...........[.............
> W*y6...
> .
> ..h......
> .................OPTIONS sip:edge.rarevase.com;transport=tcp SIP/2.0.
> …
[View More]Via: SIP/2.0/TCP 172.19.16.130:53083;rport;branch=z9hG4bKPj66df463f-ca4b-4f98-ba17-722fe3fc4a92;alias.
> From: <sip:asterisk@172.19.16.130>;tag=86ebab1d-eb4e-4986-898d-c7392b6b747b.
> To: <sip:edge.rarevase.com>.
> Contact: <sip:asterisk@172.19.16.130:53083;transport=TCP>.
> Call-ID: ed24ab3c-4f42-4a9d-8e2d-9a3acd5b5b70.
> CSeq: 3809 OPTIONS.
> Max-Forwards: 70.
> User-Agent: Asterisk PBX 13.8.0.
> Content-Length: 0.
> .
>
> ##
> T 52.10.155.177:47283 -> 172.19.8.21:9060 [AP]
> HEP3.\...................
> .........
> ...................[.....
> W*y6...
> .
> ..|......
> .................SIP/2.0 200 OK.
> Via: SIP/2.0/TCP 172.19.16.130:53083;rport=53083;received=172.19.16.130;branch=z9hG4bKPj66df463f-ca4b-4f98-ba17-722fe3fc4a92;alias.
> From: <sip:asterisk@172.19.16.130>;tag=86ebab1d-eb4e-4986-898d-c7392b6b747b.
> To: <sip:edge.rarevase.com>;tag=24voZr.
> Call-ID: ed24ab3c-4f42-4a9d-8e2d-9a3acd5b5b70.
> CSeq: 3809 OPTIONS.
> Max-Forwards: 70.
> Content-Length: 0.
> Supported: path,gruu,outbound.
> Accept: */*.
> Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,INFO,UPDATE,SUBSCRIBE,NOTIFY,REFER,MESSAGE,REGISTER.
> .
>
**This are the logs on the Kamailio.**
`May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP
May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0)
May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: DEBUG: <core> [parser/msg_parser.c:604]: parse_msg(): parse_msg: invalid message
May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: ERROR: <core> [parser/msg_parser.c:690]: parse_msg(): ERROR: parse_msg: message=<HEP3#003<98>>
May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: ERROR: <core> [receive.c:173]: receive_msg(): core parsing of SIP message failed (52.10.155.177:59607/2)`
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/599
[View Less]
Requests send with uac module's functions like uac_req_send() and remote registrations use the TM module, but don't actually do (DNS) failover when a destination is unreachable or sends a 503.
In the tm's uac.c, t_uac_prepare() function, i can already see that the dns handle is stored in a throwaway variable instead of in the transaction, but fixing the issue isn't as simple as just storing it in the transaction (print_uac_request_from_buf() needs a uas in the transaction).
Due to github not …
[View More]supporting attachments to issues, the sample config and debug log are inline.... :(
DNS entry:
```
$ host -t SRV _sip._udp.failover.test.speakup.nl
_sip._udp.failover.test.speakup.nl has SRV record 10 0 1111 try1.test.speakup.nl.
_sip._udp.failover.test.speakup.nl has SRV record 100 0 2222 try2.test.speakup.nl.
```
Log snippet:
```syslog
Jun 15 10:00:03 rio UACFailover[18178]: INFO: <script>: Sending OPTIONS request to sip:failover.test.speakup.nl
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: tm [uac.c:249]: t_uac_prepare(): DEBUG:tm:t_uac: next_hop=<sip:failover.test.speakup.nl>
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (_sip._udp.failover.test.speakup.nl(34), 33), h=825
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [resolve.c:937]: get_record(): skipping 8 NS (p=0x9ea284, end=0x9ea3e9)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [resolve.c:952]: get_record(): parsing 9 ARs (p=0x9ea335, end=0x9ea3e9)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:1741]: dns_get_related(): (0x7f225233eb38 (_sip._udp.failover.test.speakup.nl, 33), 33, *0x7f2257baf2b8) (0)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:840]: dns_cache_add_unsafe(): adding _sip._udp.failover.test.speakup.nl(34) 33 (flags=0) at 825
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:840]: dns_cache_add_unsafe(): adding try1.test.speakup.nl(20) 1 (flags=0) at 310
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:840]: dns_cache_add_unsafe(): adding try2.test.speakup.nl(20) 1 (flags=0) at 307
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:2336]: dns_srv_get_nxt_rr(): (0x7f225233eb38, 0, 0, 1597643831): selected 0/1 in grp. 0 (rand_w=0, rr=0x7f225233eba0 rd=0x7f225233ebb8 p=10 w=0 rsum=0)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (try1.test.speakup.nl(20), 1), h=310
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:2926]: dns_a_resolve(): (try1.test.speakup.nl, 0) returning 0
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:3169]: dns_srv_resolve_ip(): ("_sip._udp.failover.test.speakup.nl", 0, 0), ret=0, ip=192.168.1.245
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:3260]: dns_srv_sip_resolve(): (failover.test.speakup.nl, 0, 0), srv0, ret=0
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: tm [uac.c:150]: dlg2hash(): DEBUG: dlg2hash: 54501
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: tm [uac.c:351]: t_uac_prepare(): executing event_route[tm:local-request]
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:606]: parse_msg(): SIP Request:
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:608]: parse_msg(): method: <OPTIONS>
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:610]: parse_msg(): uri: <sip:failover.test.speakup.nl>
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:612]: parse_msg(): version: <SIP/2.0>
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK5e4d.47adbbf5000000000000000000000000.0>; state=16
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=10
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:173]: get_hdr_field(): DEBUG: get_hdr_field: <To> [22]; uri=[sip:to.example.com]
Jun 15 10:00:03 rio UACFailover[18178]: [97B blob data]
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:153]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <10> <OPTIONS>
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: pv [pv_core.c:376]: pv_get_xto_attr(): no Tag parameter
Jun 15 10:00:03 rio UACFailover[18178]: INFO: <script>: [udp:172.28.4.128:6789] [10 OPTIONS] Request (cid: 6cd531e47cc63e20-18178(a)172.28.4.128 Branch: -1 ToTag: <null> len:382) To <sip:failover.test.speakup.nl> via <sip:failover.test.speakup.nl>
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil)
Jun 15 10:00:05 rio UACFailover[18176]: DEBUG: tm [t_reply.c:1230]: t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=408
Jun 15 10:00:05 rio UACFailover[18176]: WARNING: tm [t_reply.c:957]: run_failure_handlers(): Warning: run_failure_handlers: no UAC support (1, 0)
Jun 15 10:00:05 rio UACFailover[18176]: DEBUG: tm [t_reply.c:2016]: local_reply(): DEBUG: local_reply: branch=0, save=0, winner=0
Jun 15 10:00:05 rio UACFailover[18176]: DEBUG: tm [t_reply.c:2053]: local_reply(): DEBUG: local transaction completed
```
Sample config:
```python
#------------------
# Flags
#------------------
debug=3
memdbg=5
mem_summary=5
#fork=no # This option should not be present to enable forking but disable daemonize, also -D commandline parameter is needed
log_stderror=no
sip_warning=no
listen=172.28.4.128
port=6789
children=2
shm_mem_size=64
log_name="UACFailover"
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
dns_use_search_list=no
use_dns_failover=yes
dns_srv_lb=yes
disable_tcp=yes
mpath="/usr/lib/x86_64-linux-gnu/kamailio/modules/"
loadmodule "pv.so"
loadmodule "tm.so"
loadmodule "tmx.so"
loadmodule "sl.so"
loadmodule "xlog.so"
loadmodule "rr.so"
loadmodule "uac.so"
loadmodule "rtimer.so"
# -----------------------------------------------------------------
# Module settings
# -----------------------------------------------------------------
modparam("pv", "varset", "server=s:LOGNAME")
modparam("tm", "auto_inv_100", 0)
# Time until provisional response (eg "100 Trying") is received
modparam("tm", "fr_timer", 2000)
# Time to await final response on INVITE per branch (eg per branch ring time)
modparam("tm", "fr_inv_timer", 10000)
# Time to await final response on INVITE (eg ring time)
modparam("tm", "max_inv_lifetime", 20000)
modparam("tm", "restart_fr_on_each_reply", 0)
modparam("tm", "failure_reply_mode", 3)
modparam("rtimer", "timer", "name=uac;interval=10;mode=1;")
modparam("rtimer", "exec", "timer=uac;route=TIMER")
route {
xlog("L_NOTICE", "[$pr:$si:$sp] [$cs $rm] Request. (cid: $ci <$fu> => <$ru> len: $ml)");
drop();
}
event_route[tm:local-request] {
xlog("L_INFO", " [$pr:$si:$sp] [$cs $rm] Request (cid: $ci Branch: $T_branch_idx ToTag: $tt len:$ml) To <$ru> via <$du>");
}
onreply_route {
xlog("L_INFO", " [$pr:$si:$sp] [$cs $rm] Reply (cid: $ci Branch: $T_branch_idx Status: $rs $rr ToTag: $tt len:$ml)");
}
route[TIMER] {
if not $var(done) == 1 {
$var(done) = 1;
$uac_req(method) = "OPTIONS";
$uac_req(ruri) = "sip:failover.test.speakup.nl";
$uac_req(furi) = "sip:from.example.com";
$uac_req(turi) = "sip:to.example.com";
xlog("L_INFO", "Sending $uac_req(method) request to $uac_req(ruri)");
uac_req_send();
}
}
```
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/210
[View Less]
Module: kamailio
Branch: master
Commit: b7c588dff06030a82f305b210573be5bbc961cec
URL: https://github.com/kamailio/kamailio/commit/b7c588dff06030a82f305b210573be5…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2015-09-07T15:56:45+02:00
tm: store last received response code before running onreply_route
- otherwise an innapropriate cancel can happen if the current branch got
before an 1xx response, and the …
[View More]script writer enforces another reply
code with t_reply()
- reported by Thomas Sevestre, GH#315
---
Modified: modules/tm/t_reply.c
---
Diff: https://github.com/kamailio/kamailio/commit/b7c588dff06030a82f305b210573be5…
Patch: https://github.com/kamailio/kamailio/commit/b7c588dff06030a82f305b210573be5…
---
diff --git a/modules/tm/t_reply.c b/modules/tm/t_reply.c
index b2e6e53..8da3205 100644
--- a/modules/tm/t_reply.c
+++ b/modules/tm/t_reply.c
@@ -2286,10 +2286,21 @@ int reply_received( struct sip_msg *p_msg )
backup_xavps = xavp_set_list(&t->xavps_list);
#endif
setbflagsval(0, uac->branch_flags);
+ if(msg_status>last_uac_status) {
+ /* current response (msg) status is higher that the last received
+ * on the same branch - set it temporarily so functions in onreply_route
+ * can access it (e.g., avoid sending CANCEL by forcing another t_relply()
+ * in onreply_route when a negative sip response was received) */
+ uac->last_received = msg_status;
+ }
+
/* Pre- and post-script callbacks have already
* been executed by the core. (Miklos)
*/
run_top_route(onreply_rt.rlist[onreply_route], p_msg, &ctx);
+
+ /* restore brach last_received as before executing onreply_route */
+ uac->last_received = last_uac_status;
/* transfer current message context back to t */
if (t->uas.request) t->uas.request->flags=p_msg->flags;
getbflagsval(0, &uac->branch_flags);
[View Less]
I have a situation that I can't get my head around. Every so often I have a SCA seized and I need to manually release it. Here is the log of the sca and bye from the event logs.
messages-20150920:Sep 18 14:35:28 sip-registrar /usr/sbin/kamailio[7608]: ERROR: sca [sca_call_info.c:1580]: sca_call_info_bye_handler(): sca_call_info_bye_handler: sip:Mindfield@kamailio.newgarllc.com dialog leg 96b9ad37-9a7fa462-15c35d3(a)192.168.1.117;1c389191866 is not active
messages-20150920:Sep 18 14:35:28 sip-…
[View More]registrar /usr/sbin/kamailio[7610]: NOTICE: acc [acc.c:317]: acc_log_request(): ACC: transaction answered: timestamp=1442601328;method=BYE;from_tag=76C3EC1F-114D759A;to_tag=1c389191866;call_id=96b9ad37-9a7fa462-15c35d3(a)192.168.1.117;code=200;reason=OK;src_user=Mindfield;src_domain=kamailio.newgarllc.com;src_ip=192.168.1.40;dst_ouser=Mindfield;dst_user=Mindfield;dst_domain=192.168.1.117
And the kamcmd showing the seize line (in this case both are seized)
sip:Mindfield@kamailio.newgarllc.com 1 active 1442601278 sip:Mindfield@192.168.1.117 sip:1030@192.168.1.40:5060 96b9ad37-9a7fa462-15c35d3(a)192.168.1.117 76C3EC1F-114D759A 1c389191866
I am running Kamailio 4.2.6. The phones are Polycom VVX 310/410 running 5.3.1. And the PSTN gateway is an Audiocodes Mediant 1000 running 6.60A.292.001.
The call volume is light so I don't think there is a lot of traffic but there is about 16 phones one SCA. It is not happening all time. Could be a couple days that nothing happens and then there could be a couple days that it happens multiple times a day. I can't find a common element that would be causing this unless the 'bye' is closing the call before the SCA has a chance to do something with it.
Thanks
Kev
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/341
[View Less]
In the contact-expired event route I want to check if the expired AOR is registered elsewhere, by checking replicated location tables like "location-peer". Using the registered("location-peer", "<aor>") function causes Kamailio to go to sleep and not respond to rpc commands.
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/577