I'm trying write softphone app with pjsua. Everything works well, sound is transmitted bidirectional, when I use Asterisk and softphones in the same local network - 192.168.10.XXX, but when I hide my softphone behind NAT, I can't hear any incoming sound, outcoming sound works OK.
Endpoint with my app has ip: 192.168.12.233, routers public address is 192.168.10.216, and Asterisk - 192.168.10.15. Port translation on router is configured to forward 5060 port for SIP and 4000-5000 for RTP. I tried to set ip public addres in pjsua configuration but with no effect.
Here is INVITE SIP message from my app, I think the problem is witch the SDP 'c' field which contains wrong ip addres. Do you know how to change it in pjsua or how to fix that sound problem? Maybe I should change something in Asterisk config?
INVITE sip:112#192.168.10.15 SIP/2.0
Via: SIP/2.0/UDP 192.168.10.216:40173;rport;branch=z9hG4bKPj1cb51c72-d924-4f3e-9075-6fa17e39b3be
Max-Forwards: 70
From: sip:500#192.168.10.15;tag=c80893bb-4b11-4def-b0e9-59bb82b88630
To: sip:112#192.168.10.15
Contact: <sip:500#192.168.10.216:40173;ob>
Call-ID: cc07dcae-1f51-4fd9-b3b0-508da40b2752
CSeq: 11230 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: GMIDFOO00
Content-Type: application/sdp
Content-Length: 350
v=0
o=- 3787399917 3787399917 IN IP4 192.168.12.233
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0 Unknown
m=audio 4000 RTP/AVP 9 8 96
c=IN IP4 192.168.12.233
b=TIAS:64000
a=rtcp:4001 IN IP4 192.168.12.233
a=sendrecv
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ssrc:938347045 cname:56c230b34489dbbe
Usually in Asterisk PJSIP it can happen due to two things.
Codec Support
One is codecs support, make sure you have specified codecs to be used and both sides can communicate on at least on available codec. you can check this issue by running following command, I don't see any error but you can try following command to check RTP communication
rtp set debug on
Now you will big list of information, check both side being communicating or only one side is moving packets. If there is issue than it is due to firewall. make sure you have allowed following ports in your firewall
TCP/UDP 5060 and UDP 10000-25000
You are sending private IP in SDP pay load to resolve this you need to use either STUN or ICE server please enable ICE or stun server on pjsip App side
192.168.12.233 public IP usually done by ICE or STUN server.it must be publicly accessible IP address
Setting allow_sdp_nat_rewrite of pjsua_acc_config structure should be enough here (link).
Related
I want to use netsed to alter the incoming SIP traffic (UDP port 5060) on a PBX server which is running on a linux system (debian 10 stretch).
In the first step I simply tried to set up the phone to connect to UDP/5061 and started netsed with that command:
./netsed udp 5061 127.0.0.1 5060 s/profile-level-id=4280D/profile-level-id=42800D
The traffic was intercepted, changed and forwarded to port 5060 of the PBX software.
Unfortunately, the SIP protocol "notices" that the port used by the phone does not match the PBX (the pbx is using 5060 and the phone is using 5061 because of the port forwarding). Now the question is how to do this with netsed.
So the question is how to create a transparent proxy on the same system as the pbx.
Or is there a way to listen with netsed already on port 5060, but then pass it on to the pbx software on port 5060?
The deeper background is the Mobotix door phones for outgoing calls that do not correctly encode the profile-level-id field (it should be six base16 characters long but is five characters long). My idea was to simply change the profile-level-id as soon as the SIP-Invite enters the PBX.
Same question at StackExchange.
If I do not misinterpret your idea ; and I thing a quite interesting one ; you are trying to set up an transparent application IP proxy using netsed. From that experiment, the straightforward solution does not fit because SIP protocol "notices" that 'netsed' is altering the data-path.
Some points to be aware of :
By itself, SIP does not work via NAPT as the transferred data
contains IP addresses and port numbers.
Moreover taking aside TLS, SIP is transport protocol agnostic which
mean that a SIP session is authorized to use both UDP and TCP at the
same time.
I suggest you to have a look to SIP proxy, SBC B2BUA and STUN in order to build a correct understanding of all these issues, seem to be a hard path but valuable.
Or you can take inspiration of SIP proxy and implement minimun SIP proxying functionality into netsed. It is interesting but not so easy.
But if you abandon your initial idea of 'basic' proxy then you could use a SIP toolbox like [kamalio][1]. It is a known way of doing SIP related plumbing but obviously very far your initial goal.
Hope this help.
It seems that packets sent through using gopacket/gopcap are somehow 'sent' as they are visible in a tshark trace:
444 143.613451037 127.0.0.1 → 127.0.0.1 UDP 66 6000 → 8888 Len=22
but these packets never arrive on a process on the same machine listening on 127.0.0.1:8888 (for example netcat -ul 8888).
Does anybody have any hints on why this is or things to try? As mentioned, the packets are in fact visible in a tshark trace... they just seem to completely vanish after that.
... irrelevant
out , err := pcap.OpenLive(*iface, 65535, true, -1 * time.Second)
out.WritePacketData(buf.Bytes())
... irrevelant
The idea is to construct packets and send them on lo so that a process listening on 127.0.0.1:<some port> can actually see those packets.
IP src/dst are both 127.0.0.1 and ethernet src/dst are both 00:00:00:00:00:00.
Edit:
As far as some more research goes it seems to be the case that sending packets with pcap bypasses IP network stacks in such a way that the packets can't be seen by processes. A workaround is to strip the lower levels of the packets in the trace and open a regular udp/tcp socket and send the payload through that socket.
As far as some more research goes it seems to be the case that sending packets with pcap bypasses IP network stacks in such a way that the packets can't be seen by processes. A workaround is to strip the lower levels of the packets in the trace and open a regular udp/tcp socket and send the payload through that socket.
I want to remote dial from my pc using a simple non SIP client program which I wrote and wchich sends commands to a proprietary SIP client that accepts remote commands via a TCP connection. The proprietary SIP client will then dial the remote party using my PC's IP and port number in SDP for RTP. Is this possible in principle? Are there any opensource clients available that use this concept? Is there any documentation (IETF RFCs, blogs etc) that is available.
Appreciate any help in this matter.
Check out pjsip, it's an open-source cross-platform SIP client for all major platforms and with API in C and an API wrapper for python, whichever you prefer. There are also examples on their site. Link your TCP parsing code to pjsip and call its functions to initiate a call, you can find how to do it on their site
If I understand correctly, here is what you want to do:
TCP SIP/SDP/RTP
PC <===> SIP client <===========> softswitch
Actually, TCP between PC and SIP client will probably be accurate for signalling but not for media as RTP media stream is often sent over UDP.
In my opinion, the first step is to make sure that your softswitch will accept sending RTP packets to an IP address which is not the same as SIP client (I think most of them refuse for security reasons). If it accepts and if you have no NAT between your SIP client and your PC, you should be able to send RTP stream directly to your PC. In this case, you have to retrieve RTP packets, eventually rearrange them, decompress their payload and feed them to your speakers.
If your softswitch does not want to send RTP packets to an IP address different from SIP IP address, then you have to forward your RTP packets from your SIP client to your PC. But if you can't modify your SIP client to do this (and it's probably the case as it's a proprietary software), you're probably stuck.
To test whether your softswitch accepts sending RTP packets to an unintended IP address, you can use sipp and specify a remote media ip address different from SIP signalling IP address.
Such as Skype/Team viewer/Logmein etc application, which send audio/video behind NAT (behind firewall). But when i make a small tiny application which send text to another NAT location it failed to do the same.
Example:
Sender:
-> Public ip: 91.1.2.3 My lan ip is: 192.168.1.2 with port 14446 udp
-------> Data format: RTP packets
Receiver:
<------- Data received: 0 packets
-> Public ip: 92.1.2.3 Friend lan ip is: 10.0.0.2 with port 14446 udp
* same in both way
How others does this? What is the way of doing peer 2 peer application development to overcome NAT issues? Always we have public ip's and mostly it has NAT issues.
But how does then Skype works in such cases too? Do we have a audio/video port range for UDP or always UDP is open from anything? But mine does not work above range ports for UDP i also tried. What is the secret? that is making me curious!!.
Note:
My goal is audio packets handling where i believe too much filtering or firewall cause latency and delay and other issues gets involved relatively too. So i would like to know very clearly for my application that some of the ports (which port ranges?) can be used for such purposes, where it really not blocking development stress.
There are a number of types of NATs, which vary in what traffic they'll allow in.
See the Wikipedia article on NATs
For most NATs, STUN will let you open ports AND find out what port you opened (may be different than the port you sent from). In SIP and RTSP you'd typically provide the external IP and port determined by STUN to the other end.
A fully-symmetric NAT means that STUN won't let you use a 3rd-party server to prop ports via STUN, so you'll have to use UPnP (if enabled) or map ports in the router (or set up triggers), or you'll have to play evil games to make both sides think they initiated the connection. (Not easy and not guaranteed.)
See the ICE & TURN specs (RFCs) from the IETF for detailed mechanisms to traverse NATs - though note that in some cases you must use an external proxy to forward packets.
One common solution is that the client program connects outward to the server and thus establishes a connection. Most firewalls allow outward connections - the assumption being that you are trusted and can always connect to the outside. When the server then wishes to send a message to you, it responds on the open connection.
I believe the port that you use is what is usually used to determine if it should be allowed or not. Certain ports are always let through. I'm not sure of the exact ports, but that will be different for all NATs and firewalls.
Suppose I have static ip in a subnet that has DHCP server. If i gonna send DHCPINFORM
message to the server, what will happen ?
amit
As per RFC-2131 tropic 4.3.5 for DHCPINFORM message:
"The DHCP server responds to a DHCPINFORM message by sending a DHCPACK message directly to the address given in the 'ciaddr' field of the DHCPINFORM message. The server MUST NOT send a lease expiration time to the client and SHOULD NOT fill in 'yiaddr'. The server includes
other parameters in the DHCPACK message as defined in section 4.3.1. "
1.
Since a "DHCPAck" message does not mandate to add all requested network configuration parameters, a DHCP server is free to respond to a "DHCPInform" message, with/without requested parameter responses (implementation dependent), provided the client's static ip settings are validated under dhcp server pools.
2.
Also, the dhcp-client may receive "DHCPAck" messages from many DHCP servers in response to its "DHCPInform" message. The client need to filters all of the "DHCPAck" messages received from DHCP servers to extract response parameters.
[ Example: The dhcp-client may searches each received "DHCPAck" message for a predetermined vendor-specific tag. If a "DHCPAck" message includes a predetermined vendor-specific tag, the dhcp-client extracts response parameters from this message. ]
The question:
If I send a DHCPINFORM message to the server, what will happen ?
Good question :) The answer is not quite so clear. There are variances in DHCP server implementations, and the RFCs are a bit ambiguous. Additionally, the DHCPINFORM message (always initiated by the client) has gone through some revisions - or revelations if you prefer, and so the answer may also depend on the vintage of your DHCP server software:
DHCPINFORM was initially defined in RFC2131 in March, 1997. RFC2131 has been updated 4 times by: 3396, 4361, 5494, 6842. Since RFC 2131's publication, DHCPINFORM itself has subsequently been "clarified" 7 times through 2011. A search will highlight some of the confusion sown in the wake of the creation of the DHCPINFORM message; for example.
A bit more recently, RFC 3203 created a FORCERENEW message which forces the client (incl. hosts using the DHCPINFORM message) to the RENEW state. RFC 6704 updates RFC 3203 with details on use of the Nonce Authentication protocol for security. These standards have made the answer to your question still more ambiguous.
Due to variances in DHCP server implementations, perhaps the best way to answer your question is to use nmap (or similar) to discover the contents of the ACK message issued by your server in response to a DHCPINFORM. I chose nmap to illustrate this because of the dhcp-discover script that is part of the nmap scripting engine sends a DHCPINFORM message. Here's how it worked on my system:
$ sudo nmap -sU -p 67 --script=dhcp-discover 192.168.1.1
Starting Nmap 7.70 ( https://nmap.org ) at 2022-05-30 18:37 CDT
Nmap scan report for myprivlan.com (192.168.1.1)
Host is up (0.0013s latency).
PORT STATE SERVICE
67/udp open dhcps
| dhcp-discover:
| DHCP Message Type: DHCPACK
| Server Identifier: 192.168.1.1
| Subnet Mask: 255.255.255.0
| Router: 192.168.1.1
| Domain Name Server: 192.168.1.1
|_ Domain Name: myprivlan.com
MAC Address: 00:25:B0:E0:A9:F5
Nmap done: 1 IP address (1 host up) scanned in 1.51 seconds
And so you can see what information was included in the server's ACK message. AIUI, this information may only be a subset of the complete set of information in the ACK message - a subset defined in the dhcp-discover script; you may analyze the script code to verify that.
As a further experiment, I made some changes to my DHCP server's configuration (the OPNsense firewall), and re-ran the same nmap command. In each case, the change I made on the server was accurately reflected in the nmap output.
Consequently, it seems that DHCPINFORM does meet the original objective - to update clients with static ip configurations. But it is the client's responsibility to request this update periodically.