While making a network app I met following problem.
In this scenario there are you and multiple servers in a local network to connect to, you can choose which one. Between you and the selected server there should be a TCP connection in the end.
I found UDP broadcast to be really convenient on one side but how do I answer the broadcast (I need to send some information back)? Basicly I see two possibilites.
to make a lot TCP connections
to add an UDP sender and listener.
How would you solve this?
Add a UDP listener to the server. When it receives a UDP request, send a reply back to the sender's IP/Port, and have that reply including the server's listening TCP IP/Port. The client can then send a broadcast, wait a few seconds to collect all of the replies, present them to the user, and then make a TCP connection to the selected server.
Related
Given a SIP dialog (INVITE, 200 OK, ACK) has been established via UDP; And a large message gets sent that requires TCP as transport.
What is the applied transport protocol after the large message has been sent for all other following (and normal sized) messages?
Does the protocol switch to TCP for all further request/responses or does it keep using the initially negotiated transport - UDP - for standard sized (NOT large) messages?
What I found (based on RFC 3261):
All SIP elements MUST implement UDP and TCP. SIP elements MAY
implement other protocols.
- from rfc3261#18
The ACK MUST be sent to the same address,
port, and transport to which the original request was sent.
- from rfc3261#18
Okay that says NOT all requests (especially ACK) are able to choose the transport independently.
Making TCP mandatory for the UA is a substantial change from RFC
2543. It has arisen out of the need to handle larger messages,
which MUST use TCP, as discussed below. Thus, even if an element
never sends large messages, it may receive one and needs to be
able to handle them.
- from rfc3261#18
During an established dialog a UAS/UAC never knows if the need for a large message arises - switching from UDP to TCP is just fine (without any RE-INVITE that changes the transport in advance to the actual request).
A 301 (Moved Permanently) or 302 (Moved Temporarily) response may
also give the same location and username that was targeted by the
initial request but specify additional transport parameters such as
a different server or multicast address to try, or a change of SIP
transport from UDP to TCP or vice versa.
- from rfc3261#8.3
not really relevant - the UAS may want to change the transport suggested by the UAC; but that is based on the reaction onto some INVITE (or RE-INVITE) only
The destination address,
port, and transport for the CANCEL MUST be identical to those used to
send the original request.
- from rfc3261#9.1
Okay CANCEL (like ACK) also must NOT independently choose the transport.
If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU is unknown, the request MUST be sent
using an RFC 2914 [43] congestion controlled transport protocol, such
as TCP. If this causes a change in the transport protocol from the one
indicated in the top Via, the value in the top Via MUST be changed.
That says if the SIP dialog was established via UDP, it has to be able to receive TCP requests also.
For any port and interface
that a server listens on for UDP, it MUST listen on that same port and
interface for TCP. This is because a message may need to be sent
using TCP, rather than UDP, if it is too large. As a result, the
converse is not true. A server need not listen for UDP on a
particular address and port just because it is listening on that same
address and port for TCP. There may, of course, be other reasons why
a server needs to listen for UDP on a particular address and port.
Okay that explains how switching from UDP to TCP works seamless. - And for the other direction it is just not required, but (I understand like: it still MAY work).
Both TCP and UDP are usable at that point and the transport layer is responsible for the choice.
SIP is transport independent, both are active at the same time.
Update Seems like this issue is not as close related to Indy as I thought and more a topic on multi threading. I'll keep the question open as I am not 100% convinced.
I have a working application which is exchanging ascii strings with communication partners using Indy TCP client.
The communication flow looks like this:
[Indy Level] Sender sends string
[TCP Level] Wireshark tells that this packet was delivered to the recipient
[TCP Level] The recipient sends a TCP ACK to confirm this packet
[Indy Level] The IOHandler.ReadLn method of recipient returns the data
[Indy Level] Via writeLn() a logical Acknowledgement is sent to the original sender
Recently I noticed that there a hickups in that communication, after fiddeling with wireshark I got the following picture:
[Indy Level] Sender sends string
[TCP Level] Wireshark tells that this packet was delivered to the recipient
[TCP Level] The recipient sends a TCP ACK to confirm this packet
[Indy Level] The IOHandler.ReadLn method of recipient does not return any data
Nothing to do as no data is available for recipient
After some timeout the sender send the orginal message again because there was no logical Acknowledgment from the recipient.
So my question is: If wireshark tells me that the underlying TCP mechanics did their work, how is it possible that the Indy Client has no data available?
Regards,
Attix
[SOLVED]
The hint Remy provided was correct.
I was calling Connected of the TCP Client outside its reading thread which messed up the input buffer and caused the non appearing message symptom.
Removing that (unnecessary) check solved this.
I have noticed that when I changed transport from UDP to TCP in Sofia SIP stack for some reason the SIP registration refreshes are not sent. Only the first REGISTER is sent properly and then nothing.
On the other hand, with the exact same setup if I use UDP as transport I properly get the REGISTER refreshes without issues.
Any ideas what might be the issue?
Best regards,
Antonis Tsakiridis
Suppose that I have to write a UDP server which should receive authentication token for each client in the first message and then receive different data after some period of time. This UDP server should obviously check whether certain client authenticated previously or not. How should I do it? Should I store "authenticated" flag for each (IP addr, port) pair? Is it ok? If so, what will happen if several clients will have the same IP address (for example, they share it from the same internet provider)?
I think you can't. You'll need to have the token in each message. Multiple requests can come from the same IP, such as a client connecting from behind a NAT.
This a rare case where you might want to use multiple UDP sockets at the server and connect() each of them to one authenticated client, so that you can only receive further messages on each one from each authenticated client. You'll have to send the first reply via hat socket,a denture client will have to be written to adjust its destination accordingly after receiving the first reply.
I'm using a PJSIP's pjsua dialer (based on pjsua_app.c, PJSIP 2.0.1) with TCP transport and a SIP trunk to make calls to a mobile phone. The dialer registers with a SIP Server over TCP and also sends out INVITES over TCP. UDP transport is not being used.
The environment is something like this -
PJSIP (behind NAT)<--- SIP over TCP ---> SIP Server <--- SIP trunk --> SIP trunk Provider <-- PSTN/Mobile Gateway-->Mobile phone
All calls are made from PJSIP over TCP to the mobile. To disable UDP transport creation I inserted a line "cfg->no_udp = true;" at the end of the function
"static void default_config(struct app_config *cfg)" in pjsua_app.c
I followed the instructions given here to make calls over TCP.
The problem is that we don't receive audio sent from the mobile end into the PJSIP dialer.
But RTP packets from the PJSIP dialer reach the mobile side just fine. We can hear audio in the mobile when the call is established.
We found from packet traces that the reason we dont receive media in the PJSIP dialer is that the SIP server is sending RTP packets received over the SIP trunk to a private IP address.
But when we switch to UDP for registration and send INVITES over TCP the call works fine (audio at both ends).
The wireshark packet capture shows the following -
1. PJSIP registers with server over TCP.
2. Server sends 401 with PJ's public IP and port in VIA
3. PJ registers again but inserts its public ip and port in the
contact header in the next REGISTER message sequence.
So far so good. Same sequence of messages seen when UDP is used to REGISTER.
4. INVITE sent over TCP. Dialog establishment works fine.
But in the record-route header nat=yes is missing.
5. Server sends media to private IP. No media received at PJSIP.
Is this a bug in PJSIP? If so how can this be fixed. Wireshark packet traces are available on request.
Your help and inputs are much appreciated.
Your question doesn't actually make sense as the transport of the signalling between the sip endpoint and the sip server (either UDP or TCP) has no bearing on the media transport between the two sip endpoints (most likely UDP). So there must be something else going on.
Since your talking about private IP addresses, I'm assuming you are coming from a behind a NAT over the internet to a "public" sip server.
In these types of environments I would recommend you setup STUN, TURN and ICE on the sip endpoint.
I would guess the UDP setup you where talking about has the STUN server setup and the TCP setup you where talking about doesn't.
Without further information I can't help much more.
Try to use port other than 5060 in both client and server, and/or reducing the SIP message size.
It seams this is a know issue for sending INVITE request over TCP in PJSIP.
Also you can find here some advices for reducing the SIP message size.
Please make sure that allow_contact_rewrite is set to true so that the media will be received to your end.
I think my answer is too late but this may help some other folks