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,
On 20/01/2023 01.19, kdrewicz+kamailio@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
Hi,
pt., 20 sty 2023 o 14:46 Richard Fuchs rfuchs@sipwise.com napisał(a):
O
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).
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.
(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.
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
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
pt., 20 sty 2023 o 18:13 Richard Fuchs rfuchs@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,
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@cludo.pl schrieb am Mi., 25. Jan. 2023, 16:33:
pt., 20 sty 2023 o 18:13 Richard Fuchs rfuchs@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@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
śr., 25 sty 2023 o 19:22 Karsten Horsmann khorsmann@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
Here's a quick guide on how to capture and decrypt encrypted traffic: https://voipembedded.wordpress.com/2021/03/22/troubleshooting-kamailio-encry...
-ovidiu
On Thu, Jan 26, 2023 at 9:46 AM Krzysztof Drewicz kdrewicz+kamailio@cludo.pl wrote:
śr., 25 sty 2023 o 19:22 Karsten Horsmann khorsmann@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 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Thanks !
czw., 26 sty 2023 o 16:01 Ovidiu Sas osas@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-encry...
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
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@cludo.pl napisał(a):
Thanks !
czw., 26 sty 2023 o 16:01 Ovidiu Sas osas@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-encry...
Now i see my mistake -
│SIP/2.0 200 OK 172.23.210.210:5060 172.23.9.70:50601.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
-
Karsten Horsmann -
kdrewicz+kamailio＠cludo.pl -
Krzysztof Drewicz
-
Ovidiu Sas -
Richard Fuchs