20 Jan
2023
20 Jan
'23
7:19 a.m.
I try to workout if - currently it would work, or - where and how to debug more:
I face - 2 interfacec - public internet (so, TLS + sRTP) is desired
and private - old infrastructure - i mus only use plain RTP
172.23.9.70 - private ip - from this endpoint of kamailio and rtpengine should send only
basic RTP
172.23.210.75:5060 private - target for kamailio
1.2.3.24 obfuscated public IP (TLS + sRTP required)
kamailio 5.4.4 (x86_64/linux)
rtpengine -v Version: 11.1.1.4-1~bpo11+1
all i do is:
if (proto==TLS) {
rtpengine_manage("RTP/AVP ICE=remove replace-session-connection
replace-origin pad-crypto ptime=20 codec-transcode-PCMA record-call=on allow-transcoding
direction=external direction=internal record-call=on");
} else if ($ru =~ "transport=tls") {
rtpengine_manage("DTLS=on SRTP AVPF ICE=remove
replace-session-connection replace-origin pad-crypto ptime=20 codec-transcode-PCMA
record-call=on allow-transcoding direction=internal direction=external record-call=on
media-address=1.2.3.24");
}
# 1.2.3.24 obfuscated public IP
172.23.210.75:5060 is in dispatch.cfg, as '11'
route[SBC_CORE] {
append_hf("X-My-SRTP: removed31337\r\n");
### i see this text in invtes from kamailio 172.23.9.70 towards 172.23.210.75:5060
### i see only RTP, so as expected
if (!ds_select_dst("11", "0")) {
xwarn("I:$var(i) DROP(DOWN!) FWD:$rm [$fU->$tU] [SBCVIP] to
$du\n");
sl_send_reply("503", "Destination down");
exit;
}
what i did:
certificate is a paid one (the public party needs it)
TLS works
i deleted - entries in (not kamailo) cryptosuite that caused this:
13:08:05 localhost rtpengine[15140]: ERR: [51ad8758-b64d-4d2f-9fd0-41d03a38f74d]: [core]
Failed to parse a=crypto attribute, ignoring: unknown crypto suite
Tried to search for any "ready" examples for this - only found old threads and -
that this should be possible, but - no example for woking config.
what i see:
Jan 19 19:00:57 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000038 sec
Jan 19 19:00:58 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000036 sec
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] Closing call due to timeout
Jan 19 19:00:59 localhost rtpengine[17301]: DEBUG: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] Redis delete_async=0
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] Final packet stats:
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] --- Tag 'JVR5LTs', created 60:00 ago for branch ''
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] --- subscribed to ''
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] --- subscription for ''
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] ------ Media #1 (audio over RTP/SAVP) using unknown codec
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] --------- Port 1.2.3.24:30136 <> 52.129.106.28:17030, SSRC 0, in 0 p, 0
b, 0 e, 3600 ts, out 0 p, 0 b, 0 e
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] --------- Port 1.2.3.24:30137 <> 52.129.106.28:17031 (RTCP), SSRC 0, in 0
p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] --- Tag '', created 60:00 ago for branch ''
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] --- subscribed to 'JVR5LTs'
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] --- subscription for 'JVR5LTs'
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] ------ Media #1 (audio over RTP/AVP) using unknown codec
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] --------- Port 172.23.9.70:30014 <> :0 , SSRC 0, in 0
p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] --------- Port 172.23.9.70:30015 <> :0 (RTCP), SSRC 0,
in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] Moved metadata file
"/var/spool/rtpengine/tmp/rtpengine-meta-c17bab16-5eea-492e-b1c4-ac9387f3e265-7003946f152c6c8d.tmp"
to "/var/spool/rtpengine/metadata"
Jan 19 19:00:59 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000828 sec
Jan 19 19:01:00 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000053 sec
route(SBC_CORE);
maybe any hint or - someone has working exmaple of kamailio config + rtpengine settings ?
i use only userspace daemon rtp forwarding (this is a test, dont need any performance
here)
Thanks,
20 Jan
20 Jan
2:22 p.m.
On 20/01/2023 01.19, kdrewicz+kamailio(a)cludo.pl wrote:
I try to workout if - currently it would work, or -
where and how to debug more:
I face - 2 interfacec - public internet (so, TLS + sRTP) is desired
and private - old infrastructure - i mus only use plain RTP
...
all i do is:
if (proto==TLS) {
rtpengine_manage("RTP/AVP ICE=remove replace-session-connection
replace-origin pad-crypto ptime=20 codec-transcode-PCMA record-call=on allow-transcoding
direction=external direction=internal record-call=on");
} else if ($ru =~ "transport=tls") {
rtpengine_manage("DTLS=on SRTP AVPF ICE=remove
replace-session-connection replace-origin pad-crypto ptime=20 codec-transcode-PCMA
record-call=on allow-transcoding direction=internal direction=external record-call=on
media-address=1.2.3.24");
}
Double check that one of these is actually triggered for each
offer/answer (invite/ok).
(Your usage of `media-address` is probably not what you want - usually
it's the "advertised address" syntax of the interface config that people
want)
what i see:
...
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] --- Tag '', created 60:00 ago for branch ''
...
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] --------- Port 172.23.9.70:30014 <> :0 , SSRC 0, in 0
p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] --------- Port 172.23.9.70:30015 <> :0 (RTCP), SSRC 0,
in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e
This looks like no "answer" was seen, which is what makes me think your
script doesn't actually trigger the function for the answer.
Cheers
4:10 p.m.
Hi,
pt., 20 sty 2023 o 14:46 Richard Fuchs <rfuchs(a)sipwise.com> napisał(a):
I think that i need more in depth understanding how this works - i
need to use rtpengine_ofer - before TLS w/ sRTP hits my kamailio
script ? and then, rtpengine_manage towards the no-SRTP endpoint, and
then - finally rtpengine_answer - ? So - 6 times - rtpengine_X ? (one
for incoming leg, 2nd for - outgoing)
Thanks for your input on this.
BR
O
Mayby any working example - this is preety common use of rtpenine +
kamalio i think, but - well - every available article is - old like 7
years ago or - does not cover this scenario.
if (proto==TLS) {
rtpengine_manage("RTP/AVP ICE=remove replace-session-connection
replace-origin pad-crypto ptime=20 codec-transcode-PCMA record-call=on allow-transcoding
direction=external direction=internal record-call=on");
} else if ($ru =~ "transport=tls") {
rtpengine_manage("DTLS=on SRTP AVPF ICE=remove
replace-session-connection replace-origin pad-crypto ptime=20 codec-transcode-PCMA
record-call=on allow-transcoding direction=internal direction=external record-call=on
media-address=1.2.3.24");
}
Double check that one of these is actually triggered for each
offer/answer (invite/ok).
(Your usage of `media-address` is probably not what
you want - usually
it's the "advertised address" syntax of the interface config that people
want)
Looking into that!
...
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] --------- Port 172.23.9.70:30014 <> :0 , SSRC 0, in 0
p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]:
[core] --------- Port 172.23.9.70:30015 <> :0 (RTCP), SSRC 0,
in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e
This looks like no "answer" was seen, which is what makes me think your
script doesn't actually trigger the function for the answer.
6:01 p.m.
On 20/01/2023 10.10, [EXT] Krzysztof Drewicz wrote:
I think that i need more in depth understanding how
this works - i
need to use rtpengine_ofer - before TLS w/ sRTP hits my kamailio
script ? and then, rtpengine_manage towards the no-SRTP endpoint, and
then - finally rtpengine_answer - ? So - 6 times - rtpengine_X ? (one
for incoming leg, 2nd for - outgoing)
You just need one invocation each: one for the offer, one for the
answer. (Assuming single offer/answer exchange and no branches.)
You can use rtpengine_manage() for either of them if you want to let the
module figure out whether the message is an offer or an answer. But you
will want to use different flags for the two cases, mostly depending on
where the message is going to.
If the message is going to a plain RTP (non-SRTP, non-ICE, etc) client,
use "RTP/AVP ICE=remove" etc. If the message is going to an SRTP,
ICE-enabled client, use "RTP/SAVPF ICE=force" etc.
For the "direction=" flags you want to pay attention both to where the
message is coming from (first "direction") and where it is going to
(second "direction").
If you want to manually distinguish between offers and answers instead
of using rtpengine_manage(), in general you only need to give these
flags for the offer. In that case you can then leave the flags for the
answer (mostly - there are some exceptions) blank.
Cheers
25 Jan
25 Jan
3:59 p.m.
pt., 20 sty 2023 o 18:13 Richard Fuchs <rfuchs(a)sipwise.com> napisał(a):
You just need one invocation each: one for the offer, one for the
answer. (Assuming single offer/answer exchange and no branches.)
You can use rtpengine_manage() for either of them if you want to let the
module figure out whether the message is an offer or an answer. But you
will want to use different flags for the two cases, mostly depending on
where the message is going to.
Thanks!
you were right (obviously)
If the message is going to a plain RTP (non-SRTP, non-ICE, etc) client,
use "RTP/AVP ICE=remove" etc. If the message is going to an SRTP,
ICE-enabled client, use "RTP/SAVPF ICE=force" etc.
That is 100% true, also pad-crypto.
If you want to manually distinguish between offers and
answers instead
of using rtpengine_manage(),
Nope, no need for that, just doing simple POC that - it could work.
Still - my encrypted party plays tricks with, me, is there a way - to
see unencrypted traffic towards TLS endpoint (maybe a simple pcap
before encryption or dumping in plain text somewhere),
my party needs a R-URI - blahblahblah.byoc.mypurecloud.de, so i do this:
if(proto != TLS) {
xlog("L_INFO", "[R-MAIN] from my ciamajda to
my gienio non tls $ru from $si\n");
if (!ds_select_dst("19", "0")) {
xwarn("I:$var(i) DROP(DOWN!) FWD:$rm
[$fU->$tU] [SBCVIP] to $du\n");
sl_send_reply("503", "Destination
down");
exit;
}
xlog("L_INFO","Request URI was -> [$ou] [$ru]
[$rU]\n");
rewritehostporttrans("blahblahblah.byoc.mypurecloud.de:5061;transport=tls");
xlog("L_INFO","Request URI changed MAM [$ou] [$ru]
[$rU]\n");
in dispach.list:
17 SIP:blahblahblah.byoc.mypurecloud.de:5061;transport=tls 0
1 socket=tls:1.2.3.24:5061
18 SIP:blahblahblah.byoc.mypurecloud.de:5061;transport=tls
19 SIP:blahblahblah.byoc.mypurecloud.de:5061;transport=tls 0 1
socket=tls:1.2.3.24:5061;ping_from=sip:myfqdnsbc.realhostname.gq
(mod dispatcher - as I believe can and whould give options via TLS - right ?)
Any hints? Maybe someone has already tried and succeeded with
mypurecloud ? (not so popular like o365/ms-teams trunking but still)
thanks,
6:51 p.m.
Hi,
If you want the signaling that is encrypted see in plaintext you can use
Kamailio module siptrace.
sipdump and sipcapture maybe also good for that, I didn't use these.
Krzysztof Drewicz <kdrewicz+kamailio(a)cludo.pl> schrieb am Mi., 25. Jan.
2023, 16:33:
pt., 20 sty 2023 o 18:13 Richard Fuchs
<rfuchs(a)sipwise.com> napisał(a):
You just need one invocation each: one for the offer, one for the
answer. (Assuming single offer/answer exchange and no branches.)
You can use rtpengine_manage() for either of them if you want to let the
module figure out whether the message is an offer or an answer. But you
will want to use different flags for the two cases, mostly depending on
where the message is going to.
Thanks!
you were right (obviously)
If the message is going to a plain RTP (non-SRTP, non-ICE, etc) client,
use "RTP/AVP ICE=remove" etc. If the message is going to an SRTP,
ICE-enabled client, use "RTP/SAVPF ICE=force" etc.
That is 100% true, also pad-crypto.
If you want to manually distinguish between
offers and answers instead
of using rtpengine_manage(),
Nope, no need for that, just doing simple POC that - it could work.
Still - my encrypted party plays tricks with, me, is there a way - to
see unencrypted traffic towards TLS endpoint (maybe a simple pcap
before encryption or dumping in plain text somewhere),
my party needs a R-URI - blahblahblah.byoc.mypurecloud.de, so i do this:
if(proto != TLS) {
xlog("L_INFO", "[R-MAIN] from my ciamajda to
my gienio non tls $ru from $si\n");
if (!ds_select_dst("19", "0")) {
xwarn("I:$var(i) DROP(DOWN!) FWD:$rm
[$fU->$tU] [SBCVIP] to $du\n");
sl_send_reply("503", "Destination
down");
exit;
}
xlog("L_INFO","Request URI was -> [$ou] [$ru]
[$rU]\n");
rewritehostporttrans("blahblahblah.byoc.mypurecloud.de:5061
;transport=tls");
xlog("L_INFO","Request URI changed MAM [$ou] [$ru]
[$rU]\n");
in dispach.list:
17 SIP:blahblahblah.byoc.mypurecloud.de:5061;transport=tls 0
1 socket=tls:1.2.3.24:5061
18 SIP:blahblahblah.byoc.mypurecloud.de:5061;transport=tls
19 SIP:blahblahblah.byoc.mypurecloud.de:5061;transport=tls 0 1
socket=tls:1.2.3.24:5061;ping_from=sip:myfqdnsbc.realhostname.gq
(mod dispatcher - as I believe can and whould give options via TLS -
right ?)
Any hints? Maybe someone has already tried and succeeded with
mypurecloud ? (not so popular like o365/ms-teams trunking but still)
thanks,
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
26 Jan
26 Jan
3:16 p.m.
śr., 25 sty 2023 o 19:22 Karsten Horsmann <khorsmann(a)gmail.com> napisał(a):
Hi,
If you want the signaling that is encrypted see in plaintext you can use Kamailio module
siptrace.
Is siptrace only for working with homer? I just need a plaintext dump
to a file or something like that.
sipdump and sipcapture maybe also good for that, I
didn't use these.
should look into this.
Thanks
3:50 p.m.
Here's a quick guide on how to capture and decrypt encrypted traffic:
https://voipembedded.wordpress.com/2021/03/22/troubleshooting-kamailio-encr…
-ovidiu
On Thu, Jan 26, 2023 at 9:46 AM Krzysztof Drewicz
<kdrewicz+kamailio(a)cludo.pl> wrote:
śr., 25 sty 2023 o 19:22 Karsten Horsmann <khorsmann(a)gmail.com> napisał(a):
--
VoIP Embedded, Inc.
http://www.voipembedded.com
Hi,
If you want the signaling that is encrypted see in plaintext you can use Kamailio module
siptrace.
Is siptrace only for working with homer? I just need a plaintext dump
to a file or something like that.
sipdump and sipcapture maybe also good for that,
I didn't use these.
should look into this.
Thanks
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
1 Feb
1 Feb
11:01 a.m.
Thanks !
czw., 26 sty 2023 o 16:01 Ovidiu Sas <osas(a)voipembedded.com> napisał(a):
Here's a quick guide on how to capture and decrypt encrypted traffic:
https://voipembedded.wordpress.com/2021/03/22/troubleshooting-kamailio-encr…
Now i see my mistake -
│SIP/2.0 200 OK
172.23.210.210:5060 172.23.9.70:5060
1.2.3.22:5061 │Via: SIP/2.0/UDP 172.23.210.210;received1
8.197.58.44:57301───┬───────── ──────────┬─────────
──────────┬───────── │72.23.210.210;rport=5060;branch=z9hG4bKm─
▒ 10:22:15.656278 │ INVITE (SDP) │
│ │a4jBUK71BH
▒ +0.000730 │ ──────────────────────────> │
│ │Record-Route: <sip:10.72.42.1:5060;r2=on
▒ 10:22:15.657008 │ 100 trying -- your call is │
│ │tag=KmZjt3Fr4HgZB;lr>,<sip:18.197.58.44:
▒ +0.004722 │ <────────────────────────── │
│ │61;r2=on;transport=tls;ftag=KmZjt3Fr4HgZ
▒ 10:22:15.661730 │ │
│ IN│lr>,<sip:1.2.3.22:5061;transport=tl
▒ +0.027368 │ │
│ ─────────│r2=on;lr=on;ftag=KmZjt3Fr4HgZB>,<sip:172
▒ 10:22:15.689098 │ │
│ 1│3.9.70;r2=on;lr=on;ftag=KmZjt3Fr4HgZB>
▒ +0.267998 │ │
│ <────────│To: <sip:+48732122479@cludotls.byoc.mypu
▒ 10:22:15.957096 │ │
│ 20│cloud.de>;tag=mDL0l1E
▒ +0.003231 │ │
│ <────────│From: "221223977" <sip:221223977@cludo.p
▒ 10:22:15.960327 │ 200 OK (SDP) │
│ │;tag=KmZjt3Fr4HgZB
▒ +0.001268 │ <────────────────────────── │
│ │Contact: <sip:+48732122479@172.23.9.70:5
▒ 10:22:15.961595 │ ACK │
│ │0;alias=18.197.58.44~5061~3>
▒ +0.000164 │ ──────────────────────────> │
│ │Call-ID: c565792b-1cb4-123c-708c-001851b
▒ 10:22:15.961759 │ ACK │
│ │1ff
▒ +0.020839 │ ──────────────────────────> │
│ │CSeq: 63067878 INVITE
▒ 10:22:15.982598 │ BYE │
│ │Allow: INVITE, ACK, CANCEL, BYE, OPTIONS
│ +0.003088 │ ──────────────────────────> │
│ │INFO
│ 10:22:15.985686 │ │
│ │Supported: norefersub, timer
│ +0.471166 │ │
│ ─────────│Accept: application/sdp
│ 10:22:16.456852 │ │
│ 20│x-inin-cnv: b8c9493d-0b01-4f57-b0b6-673d
│ +0.001765 │ │
│ <<<──────│788f5a
│ 10:22:16.458617 │ ACK │
│ │Session-Expires: 3600;refresher=uac
│ +0.000088 │ ──────────────────────────> │
│ │Require: timer
│ 10:22:16.458705 │ ACK │
│
ACKs from - plain RTP don't travel from kamailio and rtpengien to sRTP
part there are two ACKs and they don't go to TLS+sRTP party.
what i do:
(..)
# Wrapper for relaying requests
route[RELAY] {
handle_ruri_alias();
record_route();
if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {
if (!t_is_set("branch_route"))
t_on_branch("MANAGE_BRANCH");
xlog("L_ERR","ACK I:$var(i) branch_route \n");
}
(..)
and
# Handle requests within SIP dialogs
route[WITHINDLG] {
if (!has_totag()) return;
if ($si=="PBXIP" && $(ru{param.value,alias})!=$null) {
xlog("L_INFO","[R-WINDLG_INPBX]: jestem w srodku
$si:$sp $ru\n");
route(RTPMANAGE);
route(RELAY);
exit;
}
if (loose_route()) {
if ( is_method("NOTIFY") ) {
record_route();
}
route(RTPMANAGE);
route(RELAY);
exit;
}
if ( is_method("ACK|BYE") ) {
route(RTPMANAGE);
route(RELAY);
}
simply copy and paste from many examples lying in the internet - but
well - i'm stuck here.
The sRTP and TLS part - work as dedigned :)
scenario when call comes from TLS/sRTP party - towards the unencrytped
part - also works.
BR
2:51 p.m.
What is see is that ACK is being not recognized in any living session
Feb 1 14:46:37 localhost kamailio[1463]: DEBUG: {1 udp 63075809 ACK
b39129b0-1cd9-123c-718c-001851b691ff} <core> [core/receive.c:3 79]:
receive_msg(): preparing to run routing scripts...
Feb 1 14:46:37 localhost kamailio[1463]: DEBUG: {1 udp 63075809 ACK
b39129b0-1cd9-123c-718c-001851b691ff} sl [sl_funcs.c:443]:
sl_filter_ACK(): too late to be a local ACK!
Feb 1 14:46:37 localhost kamailio[1463]: DEBUG: {1 udp 63075809 ACK
b39129b0-1cd9-123c-718c-001851b691ff} tm [t_lookup.c:497]:
t_lookup_request(): start searching: hash=383, isACK=1
Feb 1 14:46:37 localhost kamailio[1463]: DEBUG: {1 udp 63075809 ACK
b39129b0-1cd9-123c-718c-001851b691ff} tm [t_lookup.c:455]:
matching_3261(): RFC3261 transaction matching failed - via branch
[z9hG4bKyUr334QyvjKNB]
Feb 1 14:46:37 localhost kamailio[1463]: DEBUG: {1 udp 63075809 ACK
b39129b0-1cd9-123c-718c-001851b691ff} tm [t_lookup.c:675]:
t_lookup_request(): no transaction found
Feb 1 14:46:37 localhost kamailio[1463]: DEBUG: {1 udp 63075809 ACK
b39129b0-1cd9-123c-718c-001851b691ff} <core>
[core/parser/parse_addr_spec.c:185]: parse_to_param(): add param:
tag=QcU134KD12NSc
Feb 1 14:46:37 localhost kamailio[1463]: DEBUG: {1 udp 63075809 ACK
b39129b0-1cd9-123c-718c-001851b691ff} <core>
[core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header
reached, state=29
Feb 1 14:46:37 localhost kamailio[1463]: DEBUG: {1 udp 63075809 ACK
b39129b0-1cd9-123c-718c-001851b691ff} siptrace [siptrace_hep.c:496]:
pipport2su(): the port string is 5060
śr., 1 lut 2023 o 11:01 Krzysztof Drewicz <kdrewicz+kamailio(a)cludo.pl>
napisał(a):
Thanks !
czw., 26 sty 2023 o 16:01 Ovidiu Sas <osas(a)voipembedded.com> napisał(a):
Here's a quick guide on how to capture and decrypt encrypted traffic:
https://voipembedded.wordpress.com/2021/03/22/troubleshooting-kamailio-encr…
Now i see my mistake -
│SIP/2.0 200 OK
172.23.210.210:5060 172.23.9.70:5060
1.2.3.22:5061 │Via: SIP/2.0/UDP 172.23.210.210;received1
8.197.58.44:57301───┬───────── ──────────┬─────────
──────────┬───────── │72.23.210.210;rport=5060;branch=z9hG4bKm─
▒ 10:22:15.656278 │ INVITE (SDP) │
│ │a4jBUK71BH
▒ +0.000730 │ ──────────────────────────> │
│ │Record-Route: <sip:10.72.42.1:5060;r2=on
▒ 10:22:15.657008 │ 100 trying -- your call is │
│ │tag=KmZjt3Fr4HgZB;lr>,<sip:18.197.58.44:
▒ +0.004722 │ <────────────────────────── │
│ │61;r2=on;transport=tls;ftag=KmZjt3Fr4HgZ
▒ 10:22:15.661730 │ │
│ IN│lr>,<sip:1.2.3.22:5061;transport=tl
▒ +0.027368 │ │
│ ─────────│r2=on;lr=on;ftag=KmZjt3Fr4HgZB>,<sip:172
▒ 10:22:15.689098 │ │
│ 1│3.9.70;r2=on;lr=on;ftag=KmZjt3Fr4HgZB>
▒ +0.267998 │ │
│ <────────│To: <sip:+48732122479@cludotls.byoc.mypu
▒ 10:22:15.957096 │ │
│ 20│cloud.de>;tag=mDL0l1E
▒ +0.003231 │ │
│ <────────│From: "221223977" <sip:221223977@cludo.p
▒ 10:22:15.960327 │ 200 OK (SDP) │
│ │;tag=KmZjt3Fr4HgZB
▒ +0.001268 │ <────────────────────────── │
│ │Contact: <sip:+48732122479@172.23.9.70:5
▒ 10:22:15.961595 │ ACK │
│ │0;alias=18.197.58.44~5061~3>
▒ +0.000164 │ ──────────────────────────> │
│ │Call-ID: c565792b-1cb4-123c-708c-001851b
▒ 10:22:15.961759 │ ACK │
│ │1ff
▒ +0.020839 │ ──────────────────────────> │
│ │CSeq: 63067878 INVITE
▒ 10:22:15.982598 │ BYE │
│ │Allow: INVITE, ACK, CANCEL, BYE, OPTIONS
│ +0.003088 │ ──────────────────────────> │
│ │INFO
│ 10:22:15.985686 │ │
│ │Supported: norefersub, timer
│ +0.471166 │ │
│ ─────────│Accept: application/sdp
│ 10:22:16.456852 │ │
│ 20│x-inin-cnv: b8c9493d-0b01-4f57-b0b6-673d
│ +0.001765 │ │
│ <<<──────│788f5a
│ 10:22:16.458617 │ ACK │
│ │Session-Expires: 3600;refresher=uac
│ +0.000088 │ ──────────────────────────> │
│ │Require: timer
│ 10:22:16.458705 │ ACK │
│
ACKs from - plain RTP don't travel from kamailio and rtpengien to sRTP
part there are two ACKs and they don't go to TLS+sRTP party.
what i do:
(..)
# Wrapper for relaying requests
route[RELAY] {
handle_ruri_alias();
record_route();
if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {
if (!t_is_set("branch_route"))
t_on_branch("MANAGE_BRANCH");
xlog("L_ERR","ACK I:$var(i) branch_route \n");
}
(..)
and
# Handle requests within SIP dialogs
route[WITHINDLG] {
if (!has_totag()) return;
if ($si=="PBXIP" && $(ru{param.value,alias})!=$null) {
xlog("L_INFO","[R-WINDLG_INPBX]: jestem w srodku
$si:$sp $ru\n");
route(RTPMANAGE);
route(RELAY);
exit;
}
if (loose_route()) {
if ( is_method("NOTIFY") ) {
record_route();
}
route(RTPMANAGE);
route(RELAY);
exit;
}
if ( is_method("ACK|BYE") ) {
route(RTPMANAGE);
route(RELAY);
}
simply copy and paste from many examples lying in the internet - but
well - i'm stuck here.
The sRTP and TLS part - work as dedigned :)
scenario when call comes from TLS/sRTP party - towards the unencrytped
part - also works.
BR
444
days inactive
456
days old
9 comments
5 participants
participants (5)
-
Karsten Horsmann -
kdrewicz+kamailio＠cludo.pl -
Krzysztof Drewicz
-
Ovidiu Sas -
Richard Fuchs