Hello,
As you will see I have merged my branch back into master.
These changes add a new event route [tm:branch-failure] to the tm module
which is run when any failure response is received on a transaction.
The event_route uses a new route type BRANCH_ROUTE which limits the
functions that can be run in the route.
The functions t_check_status(), t_next_contact_flow(), t_relay() and
unregister() can be used in this route.
A new pv $T_reply_ruid is accessible in this route which can be used to
unregister a single contact entry.
The following example route can be used on a registrar to handle failed
or invalid flows:
event_route[tm:branch-failure] {
xlog("L_INFO", "event_route[tm:branch-failure]\n");
if (t_check_status("430|403")) {
if (!unregister("location", "$tu", "$T_reply_ruid"))
{
xlog("L_WARN", "failed to unregister $tu with
ruid $T_reply_ruid\n");
}
if (!t_next_contact_flow())
{
xlog("L_INFO", "No more flows\n");
}
else
{
xlog("L_INFO", "Next flow\n");
t_relay();
}
}
}
Any bugs, memory leaks etc. let me know!
Hugh
--
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.
If a PUBLISH request is sent before a 200 OK for the previous PUBLISH request is received, the E-Tag is reset which leads to inconsistent presentity data in the presence server.
This is happening because the second PUBLISH is sent with the same E-Tag as the previous one, but the presence server has an updated the E-Tag (generated while handling the first PUBLISH).
The pua module should implement a queuing mechanism for subsequent PUBLISH request while a previous PUBLISH transaction is in progress. No new PUBLISH requests should be sent before a response to the previous PUBLISH request was received and the E-Tag updated.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/21
Hello,
```
kamailio -v
version: kamailio 4.4.0-pre0 (i386/linux) f39d14-dirty
flags: STATS: Off, EXTRA_DEBUG, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: f39d14 -dirty
compiled on 17:01:22 Feb 12 2016 with gcc 4.9.3
```
If I read well the RFC 3261 section 20.19 [https://tools.ietf.org/html/rfc3261#section-20.19] a SUBSCRIBE or a PUBLISH may have an Expires value of 2**32-1 = (4294967295).
But it appears to me that this value is not supported in Kamailio even if I allow it as a max_expires option in configuration (modparam("presence", "max_expires", 4294967295)).
Kamailio answers with the following:
```
2016/02/29 09:02:59.343750 192.168.100.1:5060 -> 192.168.2.2:5062
SIP/2.0 423 Interval Too Brief
via: SIP/2.0/UDP 192.168.2.2:5062;branch=z9hG4bK-11535-1-9;rport=5062
From: "User1" <sip:user1@example.com>;tag=11535-1
To: "User1" <sip:user1@example.com>;tag=dfba6eee28f067076993264b7e466d4e.151a
Call-ID: 1-11545(a)192.168.1.1-user1
CSeq: 3 PUBLISH
Expires: -2147483648
SIP-ETag: a.1456732971.11285.1.0
Server: kamailio (4.4.0-pre0 (i386/linux))
Content-Length: 0
```
Which is not compliant with the RFC, the Expires value should not be signed.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/521
The README needs to be up to date with the source code. I noted that the "Outbound proxy" modparam is not documented.
---
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/580
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 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
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 or view it on GitHub:
https://github.com/kamailio/kamailio/issues/564