On 28 Jul 2019, at 10:01 am, Andrew White <andrew@uconnected.com.au> wrote:Hi Alex,Thanks for the speedy reply!The initial BYE has an R-URI with Kamailio as the host portion. When you say the remote contact, you mean the PBX?My preference is to not expose the real addressing details of the PBX, but instead to present Kamailio as the contact point to anything outside of my network, effectively hiding my topology. Is this infeasible?If I do need to expose real addressing, I’m guessing I need to sent that through as the host portion of the Contact in the initial INVITE?Thanks!AndrewOn 28 Jul 2019, at 9:57 am, Alex Balashov <abalashov@evaristesys.com> wrote:Is the BYE's RURI domain == that of Kamailio, or the remote contact
domain? It needs to be the latter.
On Sun, Jul 28, 2019 at 09:54:17AM +1000, Andrew White wrote:Hi all,
I’ve got a call flow where PBX makes a call via Kamailio, which uses the UAC modules to make the call to the trunk. This works great, however I’ve noticed recently that when the BYE comes from the trunk, Kamailio doesn’t recognise the dialog and throws back a 404. Due to this, the PBX never knows the session has ended, and keeps its session open.
Here’s the flow from Wireshark:
https://i.imgur.com/BxPRrXP.png <https://i.imgur.com/BxPRrXP.png>
As you can see, the BYE is received from the trunk, and Kamailio throws a 404. I checked with an rpc dlg.list and at this point the dialog had gone. 30 seconds later, I threw a BYE from the PBX, and because the dialog no longer existed, it got a 481 back.
The INVITE to the trunk has the following Record-Route header:
Record-Route: <sip:kamailio.public-ip;lr;ftag=mjKtcKaBteQ4Q;vst=AAAAAAYFBQUHAwYHBgRzMwIRGRMcAgJBWBEVCwAbBhtADxBjdGVkLmNvbS5hdQ--;did=624.b2e1>
When the first BYE comes in, it still has same did in the Route header.
Below I’ve put the output from the dialog list rpc call (before the first BYE) and the relevant log lines.
{
h_entry: 1062
h_id: 7723
ref: 2
call-id: a9d32620-2b68-1238-048a-0cc47a18705a
from_uri: sip:61400123123@pbx.local:5060
to_uri: sip:61400123123@10.0.0.2
state: 4
start_ts: 1564269942
init_ts: 1564269929
end_ts: 0
timeout: 1564313142
lifetime: 43200
dflags: 643
sflags: 0
iflags: 16
caller: {
tag: mjKtcKaBteQ4Q
contact: sip:pbx.local
cseq: 7581172
route_set:
socket: udp:10.0.0.2:5060
}
callee: {
tag: SD5ptp899-1177933201-1564269931305
contact: sip:SDd3mt8-nn9jnirnmqcrvfmvkpm0hmhvgggjgv2io788of70s84u9@trunk.remote:5060;transport=udp
cseq: 0
route_set:
socket: udp:10.0.0.2:5060
}
profiles: {
}
variables: {
{
cseq_diff: 1
}
}
}
Jul 28 09:27:30 ip-10-0-0-2 /usr/local/sbin/kamailio[11061]: NOTICE: {2 450917085 BYE a9d32620-2b68-1238-048a-0cc47a18705a} acc [acc.c:279]: acc_log_request(): ACC: transaction answered: timestamp=1564270050;method=BYE;from_tag=SD5ptp899-1177933201-1564269931305;to_tag=mjKtcKaBteQ4Q;call_id=a9d32620-2b68-1238-048a-0cc47a18705a;code=404;reason=Not here;src_user=0400123123;src_domain=trunk.remote;src_ip=trunk.remote;dst_ouser=0400123123;dst_user=0400123123;dst_domain=kamailio.public-ip
I’m assuming the 404 is because the Contact header I sent from Kamailio -> Trunk is rewritten, that Contact is Kamailio’s public contact IP. However the dialog has the caller contact within it referencing back to the local PBX, so I would think when Kamailio gets this dialog ID back with a BYE it would relay it back to the original contact, wouldn’t it?
Thanks!
Andrew_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users