How can I rewrite SDP with switch_r_sdp in freeswitch? - freeswitch

v=0
o=- 1358463684 1358463684 IN IP4 xxx.xxx.xxx.xxx
s=Opal SIP Session
c=IN IP4 xxx.xxx.xxx.xxx
t=0 0
m=audio 3144 RTP/AVP 19 3 101 120
c=IN IP4 xxx.xxx.xxx.xxx
a=rtpmap:18 G729/8000/1
a=fmtp:18 annexb=no
a=rtpmap:3 gsm/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32,36
a=rtpmap:120 NSE/8000
a=fmtp:120 192-193
In the above SDP, I would like to change the IP address xxx.xxx.xxx.xxx
to different yyy.yyy.yyy.yyy. I searched in the internet and found that I need to use "action application="set"![CDATA[(sdp here)]] /action"
But I am not sure what is the exact changes I need to make. Please help me.

If you're behind NAT, you can configure the external RTP in your Sofia SIP Profile:
<param name="ext-rtp-ip" value="yyy.yyy.yyy.yyy"/>
FreeSwitch will then present this IP in outgoing SDP.
https://freeswitch.org/confluence/display/FREESWITCH/Sofia+SIP+Stack

Related

Cannot determine ethernet address for proxy ARP (Cent OS PPTP VPN)

I've installed pptpd on CentOS 7 with AWS EC2 and I can connect to vpn with windows client but I have no internet access while the server has full internet access. In pptpd log I noticed the error "Cannot determine ethernet address for proxy ARP".
I've changed the dns in /etc/ppp/options.pptpd as below:
ms-dns 8.8.8.8
ms-dns 8.8.4.4
I've also created users in /etc/ppp/chap-secrets and clients can connect without problem (but with no internet access.)
I've also enabled IP forwarding in /etc/sysctl.conf
net.ipv4.ip_forward = 1
and execute this command:
sudo sysctl -p
I changed local and remote IPs in /etc/pptpd.conf as below:
localip 192.168.10.1
remoteip 192.168.20.10-100
I configured firewall for IP masquerading:
sudo iptables -t nat -A POSTROUTING -o ens5 -j MASQUERADE
This is the ifconfig result:
ens5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9001
inet 172.31.28.246 netmask 255.255.240.0 broadcast 172.31.31.255
inet6 fe80::4e6:11ff:fed8:bb4a prefixlen 64 scopeid 0x20<link>
ether 06:e6:11:d8:bb:4a txqueuelen 1000 (Ethernet)
RX packets 3668 bytes 347939 (339.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3111 bytes 385009 (375.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 6 bytes 416 (416.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6 bytes 416 (416.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1396
inet 192.168.10.1 netmask 255.255.255.255 destination 192.168.20.10
ppp txqueuelen 3 (Point-to-Point Protocol)
RX packets 40 bytes 3158 (3.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8 bytes 104 (104.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
And this is the pptpd status (I could connect to the VPN successful but could not access the internet):
[root#ip-172-31-28-246 ~]# systemctl status pptpd
● pptpd.service - PoPToP Point to Point Tunneling Server
Loaded: loaded (/usr/lib/systemd/system/pptpd.service; enabled; vendor preset: disabled)
Active: active (running) since Sun 2021-08-22 09:24:41 UTC; 2min 9s ago
Main PID: 1476 (pptpd)
CGroup: /system.slice/pptpd.service
├─1476 /usr/sbin/pptpd -f
├─1505 pptpd [171.213.14.133:ED5A - 0000]
└─1506 /usr/sbin/pppd local file /etc/ppp/options.pptpd 115200 192.168.10.1:192.168.20.10 ipparam 171.213.14.133 plugin /usr/lib64/pptpd/pptpd-logwtmp.so pptpd-original-ip 171.213.14.133 remote...
Aug 22 09:25:28 ip-172-31-28-246.ap-east-1.compute.internal pptpd[1505]: CTRL: Starting call (launching pppd, opening GRE)
Aug 22 09:25:28 ip-172-31-28-246.ap-east-1.compute.internal pppd[1506]: Plugin /usr/lib64/pptpd/pptpd-logwtmp.so loaded.
Aug 22 09:25:28 ip-172-31-28-246.ap-east-1.compute.internal pppd[1506]: pppd 2.4.5 started by root, uid 0
Aug 22 09:25:28 ip-172-31-28-246.ap-east-1.compute.internal pppd[1506]: Using interface ppp0
Aug 22 09:25:28 ip-172-31-28-246.ap-east-1.compute.internal pppd[1506]: Connect: ppp0 <--> /dev/pts/1
Aug 22 09:25:32 ip-172-31-28-246.ap-east-1.compute.internal pppd[1506]: peer from calling number 171.213.14.133 authorized
Aug 22 09:25:32 ip-172-31-28-246.ap-east-1.compute.internal pppd[1506]: MPPE 128-bit stateless compression enabled
Aug 22 09:25:34 ip-172-31-28-246.ap-east-1.compute.internal pppd[1506]: Cannot determine ethernet address for proxy ARP
Aug 22 09:25:34 ip-172-31-28-246.ap-east-1.compute.internal pppd[1506]: local IP address 192.168.10.1
Aug 22 09:25:34 ip-172-31-28-246.ap-east-1.compute.internal pppd[1506]: remote IP address 192.168.20.10

MQTT java spring app accessing activemq on docker host fails to connect in brigde mode

I have a Spring java app with Paho MQTT v3 connecting ActiveMQ.
The app is working well out of eclipse and started via java -jar and also inside my docker container as long as the network is in host mode. I tried the host mode because the bridge mode is not working. (my issue: connection reset)
I want to use the bridge mode because host mode I see as security issue. The app runs inside the container with limited rights. For testing purposes I have deactivated this so that I tested with uid 0. But this is not the problem.
The issue is, when I am running in bridge mode I get:
2020-11-30 19:58:54.192 ERROR 13 [ main] n.w.s.s.s.MqttSender.startPublisher:53 : MqttException while starting mqtt message publisher. (resons code: 32103) : Unable to connect to server
org.eclipse.paho.client.mqttv3.MqttException: Unable to connect to server
at org.eclipse.paho.client.mqttv3.internal.TCPNetworkModule.start(TCPNetworkModule.java:80)
at org.eclipse.paho.client.mqttv3.internal.ClientComms$ConnectBG.run(ClientComms.java:722)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.ConnectException: Connection refused (Connection refused)
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at org.eclipse.paho.client.mqttv3.internal.TCPNetworkModule.start(TCPNetworkModule.java:74)
... 2 common frames omitted
As I wrote I tried this:
runing without docker => ok
running in docker container in host mode => ok
running in docker container in bridge mode => nok
I determined the mqqt host (docker host) by a script using "ip route" (alpine image)
I see in my log, that the default gateway ip is successfully determined and used.
I checked the firewalld setting and tested with netcat, if this could be the issue. But with nc I could not see an issue.
I checked with tcpdump and have seen that the connection is established. But then the mqtt client sends
unsubscribe request
disconnect request
I suppose that ActiveMQ says something like unauthorized because it is not connected of a private network (192...). Instead the network in docker is something with 172.17..*
Otherwise the activemq listens on 0.0.0.0:1883.
Even via ssh tunnel I could connect.
I added the paho reson code to log. I got 32103.
Has anybody an idea what could happen here?
This is the traffic grabbed by tcpdump
1 0.000000 172.17.0.2 172.17.0.1 TCP 74 43482 ? 1883 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=715574721 TSecr=0 WS=128
2 0.000112 172.17.0.1 172.17.0.2 TCP 74 1883 ? 43482 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=715574722 TSecr=715574721 WS=128
3 0.000148 172.17.0.2 172.17.0.1 TCP 66 43482 ? 1883 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=715574722 TSecr=715574722
4 0.328363 172.17.0.2 172.17.0.1 MQTT 100 Connect Command
5 0.328505 172.17.0.1 172.17.0.2 TCP 66 1883 ? 43482 [ACK] Seq=1 Ack=35 Win=29056 Len=0 TSval=715575050 TSecr=715575050
6 0.330538 172.17.0.1 172.17.0.2 MQTT 70 Connect Ack
7 0.330612 172.17.0.2 172.17.0.1 TCP 66 43482 ? 1883 [ACK] Seq=35 Ack=5 Win=29312 Len=0 TSval=715575052 TSecr=715575052
8 0.341795 172.17.0.2 172.17.0.1 MQTT 83 Subscribe Request (id=1) [sensordata]
9 0.343407 172.17.0.1 172.17.0.2 MQTT 71 Subscribe Ack (id=1)
10 0.383106 172.17.0.2 172.17.0.1 TCP 66 43482 ? 1883 [ACK] Seq=52 Ack=10 Win=29312 Len=0 TSval=715575105 TSecr=715575065
11 3.289301 172.17.0.2 172.17.0.1 MQTT 82 Unsubscribe Request (id=2)
12 3.290162 172.17.0.1 172.17.0.2 MQTT 70 Unsubscribe Ack (id=2)
13 3.290252 172.17.0.2 172.17.0.1 TCP 66 43482 ? 1883 [ACK] Seq=68 Ack=14 Win=29312 Len=0 TSval=715578012 TSecr=715578012
14 3.293894 172.17.0.2 172.17.0.1 MQTT 68 Disconnect Req
15 3.295862 172.17.0.1 172.17.0.2 TCP 66 1883 ? 43482 [FIN, ACK] Seq=14 Ack=70 Win=29056 Len=0 TSval=715578017 TSecr=715578015
16 3.335121 172.17.0.2 172.17.0.1 TCP 66 43482 ? 1883 [ACK] Seq=70 Ack=15 Win=29312 Len=0 TSval=715578057 TSecr=715578017
In ActiveMQ I have just enabled the MQTT transort connector. Security I don't enabled.
Do I have to configure something more in ActiveMQ?

Firefox generated offer isn't accepted by native WebRTC SDK

I'm trying to connect my iOS/Android app that uses native WebRTC framework to web
While Chrome works just fine, Firefox generates invalid offer
iOS responds with RTCPeerConnection::setRemoteDescription: Error Failed to set remote offer sdp: Failed to set remote data description send parameters. and android just crashes with signal 11
Here is SDP offer generated by Firefox
v=0
o=mozilla...THIS_IS_SDPARTA-69.0.2 1330778261957800593 0 IN IP4 127.0.0.1
s=-
t=0 0
a=fingerprint:sha-256 52:13:5A:F1:78:DA:88:9E:B5:F6:6D:A6:3B:E5:8C:6C:3A:0C:1C:BB:9F:8D:2D:FB:54:1E:DC:8F:2B:32:46:7E
a=group:BUNDLE 0 1 2
a=ice-options:trickle
a=msid-semantic:WMS *
m=video 9 UDP/TLS/RTP/SAVPF 120 121 126 97
c=IN IP4 127.0.0.1
a=sendrecv
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:121 max-fs=12288;max-fr=60
a=ice-pwd:0b05e736dc7b9b60e6045bb32ecf1a4a
a=ice-ufrag:2a06fb0e
a=mid:0
a=msid:- {2c03d601-9874-c541-88e5-fdf246db7ceb}
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 goog-remb
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 goog-remb
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 goog-remb
a=rtcp-mux
a=rtpmap:120 VP8/90000
a=rtpmap:121 VP9/90000
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000
a=setup:actpass
a=ssrc:89993993 cname:{4f658c59-75d0-c34f-b6f3-3abde4bd69f3}
m=audio 9 UDP/TLS/RTP/SAVPF 109 9 0 8 101
c=IN IP4 127.0.0.1
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=ice-pwd:0b05e736dc7b9b60e6045bb32ecf1a4a
a=ice-ufrag:2a06fb0e
a=mid:1
a=msid:- {9f4e7ccb-6c53-da4d-a1d2-6e8bfe79ed05}
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000/1
a=setup:actpass
a=ssrc:2126371479 cname:{4f658c59-75d0-c34f-b6f3-3abde4bd69f3}
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 127.0.0.1
a=sendrecv
a=ice-pwd:0b05e736dc7b9b60e6045bb32ecf1a4a
a=ice-ufrag:2a06fb0e
a=mid:2
a=setup:actpass
a=sctp-port:5000
a=max-message-size:1073741823
What's wrong with it?
I'm using Firefox Quantum 69.0.2
UPD: I've disabled data channels and now it's fine, so issue is somewhere in last 4 lines
The problem is you're using rtp datachannels, which are obsolete and non-standard.
To fix it, locate and remove any mention of DtlsSrtpKeyAgreement and RtpDataChannels.
These were old experiments that only work in Chrome. Chances are you copied them from an old book, and don't really need them. But they continue to create interop headaches, because people cut'n'paste and assume Chrome is correct in supporting them.
All browsers support standard datachannels these days, even Chrome, so there's really no reason to add these problem keywords.
Since disabling data channel solves the problem for now my guess is that the other endpoints can't handle Firefox spec compliant way of signaling data channels with webrtc-datachannel in the m=application line, but still expect a port number there instead.
What actually helped me is following settings in constraints:
{'DtlsSrtpKeyAgreement': isFirefox},
{"RtpDataChannels" : !isFirefox},

absolute_codec_string not working in dialplan

I got some trouble with using absolute_codec_string param.
My call scenario is pretty simple: caller <--> FS <--> callee.
My caller compose m=audio 7078 RTP/AVP 8 0 101 in its INVITE and I'm doing <action application="bridge" data="{absolute_codec_string=PCMU}sofia/gateway/callee/$1"/> in the dialplan.
I expected FS to use only PCMU m=audio 22952 RTP/AVP 0 101 talking to the callee
But FS still use m=audio 22952 RTP/AVP 8 0 101 in the INVITE to the callee.
Note that when I'm using originate application in fs_cli, things are good.
originate {absolute_codec_string=PCMU}sofia/gateway/caller/100 &bridge({absolute_codec_string=PCMA}sofia/gateway/callee/100
then I have FS with proper behavior in transcoding, caller has m=audio 31184 RTP/AVP 0 101 received, and callee has m=audio 21922 RTP/AVP 8 101 received.
Not sure what I'm missing, any help would be appreciated.
Edit
I was using FS media_proxy, so absolute_codec_string won't work, any another way to limit codecs used for callee to fulfill my purpose?
e.g: caller use PCMA,PCMU, I want to cut PCMA out of SDP and offer PCMU only to callee
rgds,
Loi Dang
Guess I have the answer for my own question
Briefly, I modify the whole remote sdp with variable switch_r_sdp instead of dealing with absolute_codec_string
<condition field="${switch_r_sdp}" expression="/(.*)(m=audio \d+ RTP\/AVP)([ \d]+)(.*)/s" break="never">
<action application="set" data="switch_r_sdp=$1$2$ 8 101$4"/>
<!-- Then just call bridge normally -->
</condition>
More info: https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation#CodecNegotiation-Modifyingthecodecwhenusingproxymediamode
rgds,
Loi Dang

ElasticSearch java.net.NoRouteToHostException in docker

[2015-10-11 13:08:26,587][WARN ][transport.netty ] [Joseph] exception caught on transport layer [[id: 0x7e9f652b]], closing connection
java.net.NoRouteToHostException: No route to host
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(Unknown Source)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
at org.elasticsearch.common.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
I get this exception when launching the elasticsearch in docker (Actually I only have this problem in CentOS7 docker host)
First, my dockefile exposes the UDP ports.
EXPOSE 9200 9300/udp 9301/udp 9302/udp 9303/udp 9304/udp 9305/udp
When I start the docker container, I opened these ports via -p 9200:9200 -p 9300:9300/udp -p 9301:9301/udp -p 9302:9302/udp -p 9303:9303/udp -p 9304:9304/udp -p 9305:9305/udp
Within docker ps, I do see these ports are opened as 0.0.0.0:9300-9305->9300-9305/udp
And here is some lines of my elasticsearch.yml
cluster.name: changsha
discovery.zen.ping.unicast.hosts: [ "10.0.5.241" ]
network.publish_host: 10.0.5.241
10.0.5.241 is my docker host's IP address. Please what is wrong here? it succeeded in CentOS6 host, but failes on this CentOS7 host.
UPDATE
Following this answer, I get the following result from tcpdump -p -nn icmp.
09:26:53.277117 IP 10.0.5.241 > 172.17.0.8: ICMP host 10.0.5.241 unreachable - admin prohibited, length 68
09:26:53.277494 IP 10.0.5.241 > 172.17.0.8: ICMP host 10.0.5.241 unreachable - admin prohibited, length 68
09:26:53.277822 IP 10.0.5.241 > 172.17.0.8: ICMP host 10.0.5.241 unreachable - admin prohibited, length 68
09:26:53.278043 IP 10.0.5.241 > 172.17.0.8: ICMP host 10.0.5.241 unreachable - admin prohibited, length 68
09:26:54.277753 IP 10.0.5.241 > 172.17.0.8: ICMP host 10.0.5.241 unreachable - admin prohibited, length 68
09:27:04.280703 IP 10.0.5.241 > 172.17.0.8: ICMP host 10.0.5.241 unreachable - admin prohibited, length 68
First, find out the docker interface ip address
# ifconfig
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.42.1 netmask 255.255.0.0 broadcast 0.0.0.0
ether 56:84:7a:fe:97:99 txqueuelen 0 (Ethernet)
RX packets 115761 bytes 12605533 (12.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 55687 bytes 22647938 (21.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Then add all of the docker IP addresses into whitelist
firewall-cmd --permanent --zone=trusted --add-source=172.17.0.0/16
firewall-cmd --reload
Problem solved
If someone come across the issue in centos 7.4, it`s because of the conflict between docker service and firewalld service.
you can solve by disable firewalld and then restart docker service.
please refer https://sanenthusiast.com/docker-and-firewalld-mess-in-centos-7/

Resources