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
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.
I am trying to build pjsip VoIP app for android.This is the following description given for property used in account configuration.
/**
* This option is used to update the transport address and the Contact
* header of REGISTER request. When this option is enabled, the library
* will keep track of the public IP address from the response of REGISTER
* request. Once it detects that the address has changed, it will
* unregister current Contact, update the Contact with transport address
* learned from Via header, and register a new Contact to the registrar.
* This will also update the public name of UDP transport if STUN is
* configured.
*
* See also contact_rewrite_method field.
*
* Default: 1 (yes)
*/
pj_bool_t allow_contact_rewrite;
Until now via address is only changed by pjsip.how exactly does this property work??i can see no differences??
This option only kick in once the pjsip client is behind some sort of NAT.
i.e.
[pjsip client / e.g. 10.0.100] -> [NAT / e.g. 1.2.3.4] -> [SIP Server / e.g. 2.3.4.5]
When PJSIP registers with the sip server with the "contact" address of 10.0.100:5060 the SIP Server will send back a response saying that it came from 1.2.3.4: (because of the NAT).
This is when the allow_contact_rewrite kicks in and unregisters the registration and re-registers it with the 1.2.3.4: contact address.
Why it does this is so that if the sip proxy server needs to contact/send request to the SIP UAS it uses the contact header address.
This feature is "assuming" many that the NAT support hole punching to keep the contact address valid over a range of time.
Another option is to setup STUN so that PJSIP can figure out this information ahead of time so that it "knows" the external ip address before it registers (although there is symmetric NAT which can make STUN useless).
All of these options are to try get a setup so that the client can be contacted through the internet from the SIP Proxy server to the pjsip client when a "event" happens (e.g. phone call).
Personally I've found none of these setups to get a contact address that is connectable by the SIP Porxy server to work at all.
The best setup when coming from the internet client that I use is to always use TCP only (no UDP). Enable rport and TCP keep-alive in pjsip. As long as the sip server respects rport and the tcp/ip connection stays alive then everything works fine (i.e. the sip proxy can send requests down the existing open TCP socket).
That just leaves the problem of media connections between the two endpoints, which you have to rely of ICE/STUN/TURN/NAT hole punching to get that going.
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
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.
I don't know enough about SIP. As far as I know SIP can not be used in LAN. But it's features are very good. I want to use it for a LAN messenger (with video conference facilities).
Is there any way of using SIP in LAN network ?
The SIP protocol can be used over any reliable transport (TCP, XMPP, instant messaging channel, etc...) to a service (e.g. a server such as a SIP proxy) that knows how to route the SIP INVITE message from the caller to the callee. e.g. If you send an INVITE to bob#foobar.com, there's needs to be a service that knows how to find "bob" and deliver the message. Likewise, when Bob sends back his response messages back, the messages need to route back to the caller who sent the original INVITE.
And you can do SIP without a server - provided the computer already have a connection (direct or indirect) to the other computer intended for the call.
But SIP isn't anything special. If you were to invent your own video conferencing protocol, it would probably look a lot like SIP. SIP's primary job is for both sides of a call to exchange IP/port candidates for connecting directly in addition to codec and bandwidth negotiation data.
After the SIP messages are exchanged, ICE/STUN/TURN take over and RTP packets typically flow. SIP isn't used in the call except to end the call.
What are you really trying to do anyway?
Thread is Old but still I would like to contribute to this. There are various SIP server like http://www.officesip.com/index.html which works in LAN and can be connected to hardware phone too and soft client also.
Jitsi is open source cross platform SIP/xmpp client:https://jitsi.org/
And if you want to XMPP server Openfire is the best:http://www.igniterealtime.org/projects/openfire/
I hope this will definitely help someone..!