I am using PJSIP for a SIP application and have the following problem. When I register via UDP with register URI "sip:test#172.31.5.153:5060" the register works fine. When a SipPhone calls via UDP it works fine but when the SoftPhone calls via TCP the application answers with a SIP OK where the "transport=tcp" param is missing in the contact of the SIP OK and so the Softphone declines the call. Does anybody knwos this problem and knows a easy solution? Thanks
The behaviour you described sounds like it could be perfectly "valid" sip proxy behaviour as defined in the SIP RFC depending on what the proxy supports against what you have setup in pjsip.
My guess is that you didn't setup the UDP transport correctly in pjsip setup?
What you have to remember is that the proxy is perfectly valid to send NEW dialog messages to the "contact" address.
Normally you have to setup both a UDP and TCP transport for pjsip even with using UDP by default because the SIP message size can get too big for UDP and have to use a TCP connection.
If you want to always connect via TCP you must add ";tansport=tcp" in the account pjsua_acc_config::id field where you setup the sip address for the account.
I would also recommend that if the pjsip client is connect via the internet via a NAT that you also turn on rport support (and hope that the proxy server support rport correctly) as it may be impossible for the sip server to create a TCP/UDP connection back to you when you are behind a NAT.
Related
I have configured a coturn server which I need to use with DataChannel for a chat app.
I am trying to reach a point where I can get the coturn server provide me with a tcp allocation.
I am using the standard call of RTCPeerConnection in JS client, providing the turn URI, username and credentials.
The transport I am providing in the URI params is TCP ?transport=tcp.
With all this, I am always receiving a UDP allocation and the server logs ChannelBind requests (UDP based)
Question:
How can I achieve TCP allocations throught webRTC client, to guarantee proper data delivery of the chat app in case of using my relay server?
RFC 6062, opening a TCP port on the TURN server is not supported by WebRTC. It is optional in the spec and nobody needs it since reliability is provided by SCTP.
TCP in the turn uri refers to the protocol between the client and the TURN server
Let's assume that I start a server at one of the computers in my private network (192.168.10.10:9900).
Now when making a request from some other computer in the same network, how does the client computer (OS?) knows which protocol to use / which protocol the server follows ? [TCP or UDP]
EDIT: As mentioned in the answers, I was basically looking for a default protocol which will be used by the client in the absence of any transport protocol information.
TCP / UDP protocols work at the transport layer level (TCP / IP MODEL) and its main difference is that TCP has a method to ensure the arrival of messages while UDP is lighter because of its virtue is to be faster in Information delivery. The use of one protocol or another is always defined by the application that will use it.
So the reference you put on the private server with ip: port 192.168.10.10:9900 is very vague to be more precise we could say that we have an Apache web server running on the ip: port 192.168.10.10:9900 (the port for default is 80 when installing the server, but it can be changed in the configuration).
Now the web servers (apache, IIS, etc.) work using the TCP protocol because when a client (computer, cell phone, etc.) consults a page through a browser (Chrome, Firefox, etc.), the ideal thing is that all the website and not just some pieces. This is why this type of servers chose and use this protocol in the first instance since they seek that in the end the result is that the user obtains the complete page regardless of whether a few more milliseconds are sacrificed in the validations involved in using TPC.
Now going to the client side. The user when visiting a web page from any browser (Chrome, Firefox, etc.) will use TCP since this protocol is already configured in the browser to send the query messages and subsequently receive the messages with the same form Website information.
Now this behavior is going to be repeated for any client / server application. For example, to change the type of application on the UDP side, we can observe the operation of DHCP services which are used to receive an IP when connecting any device to a Wi-Fi network. In this case, this service seeks to be as fast as possible (instead of the most reliable) since you want the device to connect as quickly as possible to the network, so use the UDP protocol and in this case any equipment when connecting To a WIFI network you will send your messages using this protocol.
Finally, if you want to know promptly about the type of TCP / UDP protocol used by a specific application, you can search on the Wireshark application which allows you to scan the messages that leave the device or show the protocol used in the different layers of the application.
There is no reason any client would make a request to your server, so why would it care what protocol it follows? Clients don't just randomly connect to things to see if there's a server there. So it doesn't make any difference to any client.
Normally, the client computer will use the TCP protocol as default. If you start the server using UDP protocol mode, then when you use curl -XGET 192.168.10.10:9900/test-page, it will give you back an curl: (7) Failed to connect to 192.168.10.10 port 9900: Connection refused error. You can try it, use the nc -lvp 9900 -u, it will give you that result.
The answers here are pointing to some default protocol. Its' not that, Whenever you start an application let say HTTP server, the server's internal has code to open a socket(which can be TCP or UDP), since HTTP:80 is a TCP protocol the code creates a TCP socket. Similarly for other network application it depends on their requirement what kind of transport layer protocol to use (TCP Or UDP). Like a DNS client will create a UDP socket to connect to DNS server, since DNS:53 is mostly over UDP. Both TCP and UDP have different use cases, advantages and disadvantages. Depending on there uses cases / advantages / disadvantages of UDP/TCP decision is taken to implement server using either of them.
Long time Asterisk user but fairly new to OpenSIPs. I have a SIP phone working with audio both directions when registering to and receiving calls directly from Asterisk. The same phone works with 2 way audio if I register to OpenSIPs and receive a call from OpenSIPs but only IF the call originated from somewhere OTHER than our Asterisk server.
Example that works:
Call from PSTN > OpenSIPs > SIP Phone (registered to OpenSIPs)
Call from PSTN > Asterisk > SIP Phone (registered to Asterisk)
Example that does NOT work, one way audio issues:
Call from PSTN > Asterisk > OpenSIPs > SIP Phone (registered to OpenSIPs)
I am trying to offload all our registrations from Asterisk to OpenSIPs but when we pass the call from Asterisk to OpenSIPs the call goes to the phone registered to OpenSIPs but has one way audio.
Don't believe it to be a firewall issue because we have tested while firewalls on both Asterisk and OpenSIPs are off.
Have tested many theories but, I'm at a loss at this point, out of ideas. I thought I would ask the smart folks here.
Thanks in advance for any help.
I fixed this by setting nat=yes in the sip.conf on Asterisk server under the configuration for the OpenSIPs server.
I noticed that when I tested on a newer version of Asterisk I got better errors in the Asterisk console. I noticed Asterisk was trying to send the RTP to the private LAN IP of the endpoint (my sip phone) instead of the public IP of my internet connection where the phone is located. Not sure why it was trying to do that. I am wondering if OpenSIPs needs to be modified. Was puzzles me is that I have NEVER had to set nat=yes on Asterisk when sending calls to servers with static public IP. In this case I am sending calls to an extension like 456#xxx.xxx.xxx.xxx where xxx is the public static IP of my OpenSIPs server so, no NAT involved there. The NAT comes into play when the call is sent to the endpoint which is behind a NAT. Makes no sense to me why I should have to set nat=yes to make this work but, this was an immediate fix. Will research more later, might need a change on the OpenSIPs side instead of nat=yes on the Asterisk side.
I am using my device as an Access Point and I need to display a deafault web page once somebody is connected.
Right now I have to connect to a specific IP (socket parameters: IP 192.168.0.1 , PORT 80) to show the page.
The page doesn't need to open automatically, it just has to show up no matter what URL gets inserted in the browser.
I've read the RFC7710 but I'm not able to implement "low level" solutions such as modify the option 160 of the DHCP.
The best thing for me would be to work at the HTTP level.
Any ideas?
HTTP works on the top of the TCP/IP infrastructure, it requires an established TCP connection first. As long as there is no TCP connection from the client to the HTTP server, the server has no way to tell, force, or trick a client to connect to its IP address and TCP port. No connection, no HTTP.
I want to know how two computers with VoIP software can be connected to each other and exchange voice data without having an external IP address.
You would need an static IP address only if you were trying to connect the two to each other directly. The VOIP server acts as a go-between.
Example:
Person 1 and Person 2 are trying to get into a VOIP call
They both register with the VOIP server with their IDs.
When one ID places a call to another, the there is a connection between the two, with the server in between, but not directly with each other.
SIP (Session Initiation Protocol) is usually the Protocol used for VOIP. There is a SIP registrar, which is the server. You can establish your own SIP server using Asterisk's free solution. SIP actually makes it possible to directly connect peers. However, this isnt possible over the internet where people dont have static IPS
Software like skype use a similar workflow. The skype client tries to connect the peers. When it cant, it uses something like UDP Hole Punching.
Every computer in the internet has an external IP.
The internet works that way.
There are numerous pages on the internet, where you can see your 'external IP'.
Regarding the voice exchange: They connect to a server and that server either does the relaying himself, or exchanges the IP information between the clients, who are then left to create a connection among themselves.
The actual data of a VoIP call is carried over RTP, which really only takes 24-64Kbps (depending upon codec) and requires UDP addresses going each way. Occasional RTCP packets are sent to report status, metrics, etc, but are not really needed.
SIP is used for call setup and teardown.
There is always a network address between two VoIP endpoints, comprised of the IP address and the VoIP socket.
And yes, you could proxy RTP over some other transport protocol, or tunnel (through http?), etc.