I have an Asterisk server in AWS and a softphone client connected over OpenVPN. The call is established, but the SDP in the connection info is the client’s OpenVPN local IP. This causes the RTP to try to route to that rather than the OpenVPN address in AWS which fails. This isn’t necessarily an Asterisk issue, just wondering if anyone has any ideas as I am not having any luck.
Is the softphone populating the SDP from ICE/TURN/STUN lookups? You might be able to limit the subnets.
I tried ICE/STUN and it used the public address of our network instead of its local VPN IP address.
And it fails with STUN disabled ?
You might want to post the raw SIP packets to get further assistance, along with a block diagram:
PBX ↔ VPN ↔ client
^^^ this is failing ?
Asterisk<->AWS network<->OpenVPN<->Client
Client has established a TCP session for SIP communications over open VPN. Asterisk sends the invite to the client:
Frame 851: 564 bytes on wire (4512 bits), 564 bytes captured (4512 bits) on interface eth0, id 0
Ethernet II, Src: ip-172-31-77-206.ec2.internal (16:c2:26:91:63:71), Dst: 16:2e:83:4e:92:03 (16:2e:83:4e:92:03)
Internet Protocol Version 4, Src: ip-172-31-77-206.ec2.internal (172.31.77.206), Dst: 172.31.76.239 (172.31.76.239)
Transmission Control Protocol, Src Port: 5060, Dst Port: 5061, Seq: 1360, Ack: 1, Len: 510
[3 Reassembled TCP Segments (1869 bytes): #850(1359), #851(510), #862(510)]
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:11010200101@192.168.1.34:5061;rinstance=215db1a5f26b02fa;transport=tcp SIP/2.0
Message Header
Via: SIP/2.0/TCP 172.31.77.206:5060;branch=z9hG4bK6b44324c;rport
Max-Forwards: 70
From: “Tom’s Video” sip:7034243153@172.31.77.206;tag=as3b790154
To: sip:11010200101@192.168.1.34:5061;rinstance=215db1a5f26b02fa;transport=tcp
Contact: sip:7034243153@172.31.77.206:5060;transport=tcp
Call-ID: 4cffe637447a79ce3bea7d045bc2566a@172.31.77.206:5060
[Generated Call-ID: 4cffe637447a79ce3bea7d045bc2566a@172.31.77.206:5060]
CSeq: 102 INVITE
User-Agent: FPBX-16.0.40.7(18.5.1)
Date: Mon, 08 Jan 2024 14:21:24 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
X-OMNI-ANI: 7034243153
X-NENA-INCIDENTID: urn:emergency:uid:incidentid:7BB689F4L18C8E145CD3LH7F79:PSAP.psap1.microautomation.com
X-NENA-CALLID: urn:emergency:uid:callid:7BB689F4L18C8E145CD3LH7F7A:PSAP.psap1.microautomation.com
X-OMNI-CALLID: 8a4bef20-0929-4fc2-817e-8b5e4c5b16ce
X-OMNI-TO: sip:11019070100@172.31.77.206;tag=as6070c9c9
X-OMNI-ORIGINALDNIS: 11010200100
X-OMNI-FOCUS: false
X-OMNI-DNIS: 11010200100
X-OMNI-ORIGINAL-TRUNK: 27034243153
X-AST-CHANNEL: SIP/27034243153-00000095
X-AST-CALLID: 1704723681.217
P-Asserted-Identity: “Tom’s Video” sip:7034243153@172.31.77.206
Content-Type: application/sdp
Content-Length: 561
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): root 892226375 892226375 IN IP4 172.31.77.206
Session Name (s): Asterisk PBX 18.5.1
Connection Information (c): IN IP4 172.31.77.206
Bandwidth Information (b): CT:384
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 11598 RTP/AVP 0 8 3 111 9 101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:3 GSM/8000
Media Attribute (a): rtpmap:111 G726-32/8000
Media Attribute (a): rtpmap:9 G722/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-16
Media Attribute (a): maxptime:150
Media Attribute (a): sendrecv
Media Description, name and address (m): video 11088 RTP/AVP 99
Media Attribute (a): rtpmap:99 H264/90000
Media Attribute (a): fmtp:99 profile-level-id=42C014
Media Attribute (a): sendrecv
Media Description, name and address (m): text 18442 RTP/AVP 106 105
Media Attribute (a): rtpmap:106 T140/1000
Media Attribute (a): rtpmap:105 RED/1000
Media Attribute (a): fmtp:105 106/106/106
Media Attribute (a): sendrecv
[Generated Call-ID: 4cffe637447a79ce3bea7d045bc2566a@172.31.77.206:5060]
Client (which is using a VPN to connect) responds with OK. Note it sent its client address in the SDP:
Frame 1851: 1035 bytes on wire (8280 bits), 1035 bytes captured (8280 bits) on interface eth0, id 0
Ethernet II, Src: 16:bf:28:9e:65:ab (16:bf:28:9e:65:ab), Dst: ip-172-31-77-206.ec2.internal (16:c2:26:91:63:71)
Internet Protocol Version 4, Src: 172.31.76.239 (172.31.76.239), Dst: ip-172-31-77-206.ec2.internal (172.31.77.206)
Transmission Control Protocol, Src Port: 5061, Dst Port: 5060, Seq: 442, Ack: 1870, Len: 981
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/TCP 172.31.77.206:5060;branch=z9hG4bK6b44324c;rport=5060
Contact: sip:11010200101@192.168.1.34:5061;transport=tcp
To: sip:11010200101@192.168.1.34:5061;rinstance=215db1a5f26b02fa;transport=tcp;tag=e5209866
From: “Tom’s Video” sip:7034243153@172.31.77.206;tag=as3b790154
Call-ID: 4cffe637447a79ce3bea7d045bc2566a@172.31.77.206:5060
[Generated Call-ID: 4cffe637447a79ce3bea7d045bc2566a@172.31.77.206:5060]
CSeq: 102 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, UPDATE, INFO, MESSAGE
Content-Type: application/sdp
Supported: replaces, norefersub, answermode, tdialog
User-Agent: ABTO SIP SDK
Content-Length: 367
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 13349197288542251 13349197288542251 IN IP4 192.168.1.34
Session Name (s): -
Connection Information (c): IN IP4 192.168.1.34
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 17768 RTP/AVP 0 8 101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): ptime:20
Media Attribute (a): sendrecv
Media Description, name and address (m): video 17770 RTP/AVP 99
Media Attribute (a): rtpmap:99 H264/90000
Media Attribute (a): fmtp:99 profile-level-id=42e01e
Media Attribute (a): sendrecv
Media Description, name and address (m): text 0 RTP/AVP
[Generated Call-ID: 4cffe637447a79ce3bea7d045bc2566a@172.31.77.206:5060]
Asterisk then sends RTP to the client’s local IP rather than the VPN address:
Frame 1879: 228 bytes on wire (1824 bits), 228 bytes captured (1824 bits) on interface eth0, id 0
Ethernet II, Src: ip-172-31-77-206.ec2.internal (16:c2:26:91:63:71), Dst: 16:bf:28:9e:65:ab (16:bf:28:9e:65:ab)
Internet Protocol Version 4, Src: ip-172-31-77-206.ec2.internal (172.31.77.206), Dst: 192.168.1.34 (192.168.1.34)
User Datagram Protocol, Src Port: 11088, Dst Port: 17770
Real-Time Transport Protocol
H.264
So Asterisk is sending RTP to 192.168.1.34 and you think it should be sending to 172.31.76.239 instead ?
This is a closed-source soft phone that is sending incorrect SDP ?
Have you tried a full tunnel VPN ?
Are you able to change the network interface in the soft phone settings ?
Yes, it should be 172.31.76.239. I was fairly certain in was the VPN. We managed to get around the issue by installing a stun server on the server side of the VPN and the client would talk to that to get the IP address for the SDP.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.