I am using Telephone softphone on macOS. When making a call, it sends the following INVITE request:
INVITE sip:login#sip.antisip.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.13:63980;rport;branch=z9hG4bKPj1J2vaemfz28guXCjwsCNuCM4K7AGksTF
Max-Forwards: 70
From: "Andriy Makukha" <sip:nickname#sip.linphone.org>;tag=CK3y0yotv2v1AclTF2sBahkYcA721X7t
To: <sip:login#sip.antisip.com>
Contact: "Andriy Makukha" <sip:nickname#192.168.1.13:63980;ob>
Call-ID: Tu2FDGIveVVM1BZFKY1IUYFxkxuBWZU5
CSeq: 18057 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, norefersub
User-Agent: Telephone 1.4
Content-Type: application/sdp
Content-Length: 541
...
As you can see, the request doesn't have neither Proxy-Authorization nor Authorization header. However, the server never challenges this request with a 407 Proxy Authentication Required response. The call always goes through directly.
On the other hand, when I use another SIP client, the server always sends Proxy Authentication Required response.
What does Telephone do that allows it to avoid authentication while making a call?
Additional information:
after launch, the softphone sends a REGISTER request and receives a 401 Unathorized response and then resends the REGISTER with the Authorization header
the REGISTER request is sent to 91.121.209.194, which is the A-record for the domain sip.linphone.org (domain of the caller)
however, the INVITE request is being sent directly to 91.121.30.149 which is the A-record for the domain sip.antisip.com (domain of the callee).
Here are the headers in the incoming INVITE:
From: "Andriy Makukha" <sip:nickname#sip.linphone.org>;tag=...
To: <sip:login#sip.antisip.com>
In theory, the above INVITE should be:
sent to sip.linphone.org first
challenged with a 407 by sip.linphone.org
sent to sip.linphone.org with credential
forwarded from sip.linphone.org to sip.antisip.com
NOT challenged by sip.antisip.com
Reading your description of your issue, it is possible that you have misconfigured your application and your SIP identity (in From header) is wrong? If Telephone is configured to send directly to sip.antisip.com then, the call will be forwarded by sip.antisip.com without 407.
As the owner of sip.antisip.com, I could (should?) reject incoming call to my users if they appear to not come from the service of the From header. But I have not implemented such anti-spam policy. I would love to add some restrictions in my policy to prevent unwanted configuration, but my users will complain... Even if they are wrong!
Some reading:
rfc5039 - The Session Initiation Protocol (SIP) and Spam
rfc8197 - A SIP Response Code for Unwanted Calls
Related
I have a question about SIP, when read RFC [3311] UPDATE request, it doesn't mention that it's not invalid behavior in SIP. Here is the call flow:
UAC sends INVITE request
UAS sends 1xx INVITE to UAC
UAC sends UPDATE request
UAS send 2xx INV
UAS send 2xx UPDATE
I supposes some reasons that made the 200OK for INVITE come first then 2xx response for UPDATE request coming after. Is this case a pass case in SIP call follow ?
Thank you guys.
Yes, that's perfectly OK.
This can happen when the UPDATE request and the 2xx INVITE response are sent 'simultaneously' and thus cross each other.
After the UAS has sent the 2xx INVITE response it will receive the UPDATE request and immediately send the 2xx UPDATE response. This means the session that was established due to the INVITE request/response will have a short lifespan since its session parameters will be updated according to the UPDATE session parameters.
I am testing the integration of a SIP Server(just a PBX) with another PBX.
The incoming call comes into the PBX and is sent to my SIP Server.
Once the call arrives on my SIP Server, it is then again sent back to a user who is registered to my PBX. Here we have 2 call legs – one from the caller to PBX and another from Sip Server to called party.
The call is set up correctly and there is no issue with audio as well.
When the called party releases the call, my SIP Server sends a BYE message to called party and caller in the same TCP packet.
Upon running a Wireshark trace I found that BYE message from my SIP Server reaches the called party but never reaches the caller.
I know there is a firewall between my SIP Server and PBX.
Question:
Is there an option for how to prevent multiple SIP messages in a single TCP packet? Other than using UDP or fight against FW?
>> BYE from SIP Server to called party and it gets a 200 OK:
11:39:03.163: Sending [31,TCP] 462 bytes to 10.cc.dd.ddf:5060 >>>>>
BYE sip:+xxxxxxxxx#10.xx.cc.vv:1122;transport=tcp SIP/2.0
Call-ID: 003BA5CE-58A9-1D9C-ACEB-886231C0AA77-57379#1xx.vv.vv.vvv
<................>
>> BYE from SIP Server to the caller and it never makes it to the PBX:
11:39:03.163: Sending [31,TCP] 448 bytes to 10.cc.dd.ddf:5060 >>>>>
BYE sip:+420702252645#10.cc.cc.bb:5060;transport=tcp SIP/2.0
Call-ID: acda8080-da917a0e-5a26b-8a61610a#10.xx.cc.vvb
Is there an option for how to prevent multiple SIP messages in a single TCP packet?
While the setup your describe is confusing (images with setup and message flow might make it more clear) and the question by itself is likely off-topic (unrelated to programming), this specific part of the question can be answered:
There is no option like this in SIP. While your specific but unknown endpoint or PBX might have such an option it is unlikely. The sender is fully within the specification if it packs multiple SIP messages to the same hop (i.e. SIP endpoint or SIP proxy) into the same TCP connection where they also can end up in the same packet because this is how TCP works. If the recipient has problems with this then it is a bug in the recipient and should be fixed there instead of working around it in every possible peer.
I'm using Java wrapper for pjsip. I noticed strange behavior, consider following flow ->
PJSIP sends first invite which looks completely fine. First INVITE does not contain TO tag as expected.
To: sip:11643139125#81.243.146.151;
Server sends back Trying, Ringing, Session In Progress, and finally compltely valid OK messag, which contains TO tag.
OK message sent by server has not been acked by client. Instead PJSIP sends seconds INVITE wich contains TO tag sent by server
To: sip:11643139125#81.243.146.151;tag=4NLnv0RNr8qvK2MY
I suspect that INVITE request should not contain TO tag. In responce Asterisk answers with SIP/2.0 491 Request Pending.
Why PJSIP sends second INVITE, why seconds INVITE contains TO tag ?
Sounds like re-INVITE, perhaps related to lock_codec account configuration option (2nd party did not reply with single codec answer) - you can try disabling it for test purposes. Would you get same result with original user agent (pjsua)?
According to sip protocol when first invite send, sip returns proxy authentication required message (if there are any proxy server available), then client send an acknowledge message. But what happen if the acknowledge message failed to reach the sip server? Server returns forbidden after sometimes and ignore all new invite with authentication header. Also when sip gets multiple acknowledge message it's immediately send forbidden.
If your question is what would the correct behaviour be for a SIP server that has issued a 407 and not received an ACK for it, please see RFC 3261 17.2.1 for the description of the INVITE server transaction.
Sending the 407 moves the state machine into the "Completed" state, at which point the G and H timers have to be be set. When G fires, the 407 response needs to be retransmitted. And if all the ACK messages get lost, then timer H will make the server transaction give up eventually. But if the second ACK reaches the server then that's it. You will have seen two 407 responses, one with a lost ACK, the second one with a successful ACK.
The handling of the subsequent INVITE with the credentials should be entirely independent with the previously described process. The INVITE message with the credentials will constitute a separate dialogue forming transaction.
Usually, the Contact header field in the Invite request is useless. For example, the UAC and the UAS are in different LANs. The Contact field may be:
INVITE sip:bob#sipprovider SIP/2.0
Contact: Alice<alice#192.168.1.10>
.....
There is no use of the Contact field while we can still build a dialog. Then, why the Contact header field is mandatory？
The Contact header says where you are (or rather, where your User Agent is), while the From header says who you are.
You might have several SIP devices all registered to the same Address of Record (the URI you put in the From header).
Further, REGISTER requests use Contact headers to maintain SIP's location service: they let a user agent update a registrar's location information.
(As an aside, if Alice calls Bob, the Contact header needs to be in a 2xx response so that Alice can route the 2xx's ACK to Bob. This points to DarkDust's comment about some SIP proxies mangling Contact headers: if it doesn't, you find yourself in the uncomfortable position of having a call that's only half established: Alice thinks the call's set up because she sent her ACK, but Bob never receives it. An alternative to a Contact-mangling Proxy is using a B2BUA as a network gateway; it wouldn't need to mangle the Contact header because the header would point to the B2BUA itself.)
In response to Phoenix Luo's comments, because of the shortcomings of using LAN IPs in a Contact header, RFC 5627 describes a solution - using globally routable user agent URIs
(GRUUs) in the Contact header/s.
The contact field contains the address at which the callee can reach the caller for future requests. For example, it's necessary so that the callee can send a BYE or a re-INVITE to the caller.