INVITE requests must always contain a new unique branch id. When
a new branch id is created for an INVITE, the dialog's invite_branch
variable must be updated so CANCEL requests use the correct branch id.
(closes issue #15262)
Reported by: maniax
Patches:
asterisk-1.6.1.0-sip-branch.patch uploaded by tweety (license 608)
invite_new_branch_trunk.diff uploaded by dvossel (license 671)
Tested by: maniax, dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@219450 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch cleans up the locking logic in chan_sip.c's
handle_invite_replaces() function as well as making use
of ast_do_masquerade() rather than forcing the masquerade
on an ast_read(). The code had several redundant unlocks
that would result in 'freed more times than we've locked!'
errors. I cleaned these up as well as moving all the unlock
logic to the end of the function. This patch should also
resolve the issue people were having with the replacecall
channel never being unlocked with one legged calls.
(closes issue #15151)
Reported by: irroot
Patches:
invite_w_replaces_1.4.diff uploaded by dvossel (license 671)
Tested by: irroot, dvossel
Review: https://reviewboard.asterisk.org/r/371/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@219303 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Remove code that causes loops in registrations.
We have agreed that the patch that this code was part of was bad. I am ripping out the code that causes
the issue. putnopvut needs to check the rest of the patch, if it needs to be changed as well.
This solves the issue reported in #15540, but needs more work before we close it (as described above).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@217668 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The issue at hand is that some legacy (dying) PBX systems send empty media frames on PRI
links *before* any call progress. The SIP channel receives these frames and by default
signals 183 Session progress and starts sending media. This will cause phones to
play silence and ignore the later 180 ringing message. A bad user experience.
The fix is twofold:
- We discovered that asterisk apps that support early media ("noanswer") did not send
any PROGRESS frame to indicate early media. Fixed.
- We introduce a setting in chan_sip so that users can disable any relay of media frames
before the outbound channel actually indicates any sort of call progress.
In 1.4, 1.6.0 and 1.6.1, this will be disabled for backward compatibility. In later versions
of Asterisk, this will be enabled. We don't assume that it will change your Asterisk
phone experience - only for the better.
We encourage third-party application developers to make sure that if they have applications
that wants to send early media, add a PROGRESS control frame transmission to make sure that
all channel drivers actually will start sending early media. This has not been the default
in Asterisk previous to this patch, so if you got inspiration from our code, you need to
update accordingly. Sorry for the trouble and thanks for your support.
This code has been running for a few months in a large scale installation (over 250
servers with PRI and/or BRI links to old PBX systems).
That's no proof that this is an excellent patch, but, well, it's tested :-)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@216430 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From section 13.3.1.1 of RFC 3261:
If the UAS desires an extended period of time to answer the INVITE,
it will need to ask for an "extension" in order to prevent proxies
from canceling the transaction. A proxy has the option of canceling
a transaction when there is a gap of 3 minutes between responses in a
transaction. To prevent cancellation, the UAS MUST send a non-100
provisional response at every minute, to handle the possibility of
lost provisional responses.
(closes issue #11157)
Reported by: rjain
Tested by: twilson
Review: https://reviewboard.asterisk.org/r/315/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@215682 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There already was code present to be sure that a CANCEL will contain the same branch-id
as the INVITE it is cancelling. However, for INVITES which are challenged downstream,
this mechanism did not work properly. Now this is taken care of.
This is a backport of a fix already present in all 1.6.X branches and in trunk. It also
fixes ABE-1907.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@211807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For cases where Asterisk sends an INVITE and receives a non 2XX final
response, Asterisk would follow the INVITE transaction by immediately
sending a BYE, which was unnecessary.
(closes issue #14575)
Reported by: chris-mac
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@208587 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This generalizes the fix for issue 13849. The initial fix corrected the
problem that Asterisk would reply with a 491 if a reinvite were received
from an endpoint and we had not yet received an ACK from that endpoint
for the initial INVITE it had sent us. This expansion also allows Asterisk
to appropriately handle an INVITE with authorization credentials if Asterisk
had not received an ACK from the previous transaction in which Asterisk had
responded to an unauthorized INVITE with a 407.
(closes issue #14239)
Reported by: klaus3000
Patches:
14239.patch uploaded by mmichelson (license 60)
Tested by: klaus3000
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@208386 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Copied from Review board:
In issue 12434, the reporter describes a situation in which audio and video
is offered on the call, but because videosupport is disabled in sip.conf,
Asterisk gives no response at all to the video offer. According to RFC 3264,
all media offers should have a corresponding answer. For offers we do not
intend to actually reply to with meaningful values, we should still reply
with the port for the media stream set to 0.
In this patch, we take note of what types of media have been offered and
save the information on the sip_pvt. The SDP in the response will take into
account whether media was offered. If we are not otherwise going to answer
a media offer, we will insert an appropriate m= line with the port set to 0.
It is important to note that this patch is pretty much a bandage being
applied to a broken bone. The patch *only* helps for situations where video
is offered but videosupport is disabled and when udptl_pt is disabled but
T.38 is offered. Asterisk is not guaranteed to respond to every media offer.
Notable cases are when multiple streams of the same type are offered.
The 2 media stream limit is still present with this patch, too.
In trunk and the 1.6.X branches, things will be a bit different since Asterisk
also supports text in SDPs as well.
(closes issue #12434)
Reported by: mnnojd
Review: https://reviewboard.asterisk.org/r/311
Review: https://reviewboard.asterisk.org/r/313
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@207423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some ITSP make use of the "Anonymous" display name to detect a
requirement to withhold caller id across the PSTN. This does
not work if the display name is "Unknown".
(closes issue #14465)
Reported by: Nick_Lewis
Patches:
chan_sip.c-callerpres.patch uploaded by Nick (license 657)
chan_sip.c-callerpres_trunk.patch uploaded by dvossel (license 671)
Tested by: Nick_Lewis, dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@206938 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From the review board request:
The fix from review 298 has exposed a new bug in chan_sip.
When we hang up an outgoing call, we first will dump all the outstanding
packets on the sip_pvt using __sip_pretend_ack. Then, if we can, we send
a CANCEL. The problem with this is that since destroyed all the outstanding
packets on the dialog, we cannot match the incoming 487 response to our
INVITE. Because we cannot match the response, we do not send an ACK.
To correct this, instead of using __sip_pretend_ack, I have changed the code
to loop through the list of packets and call __sip_semi_ack on each one
instead. This causes us to stop retransmitting the requests, but we still have
them around in case we get responses for them.
When discussing this earlier today with Josh Colp, we both agreed that in the
majority of cases, this would be enough of a fix. However, we also agreed that
we should have a safety net in place in case we never receive a response to
our initial INVITE. To handle this, I have modified __sip_autodestruct to
behave similar to the way it does in Asterisk 1.4. If there are outstanding
packets on the sip_pvt, the needdestroy flag is not set, and the last request
on the dialog was either a CANCEL or BYE, then we set the needdestroy flag and
reschedule destruction for 10 seconds in the future. If, though, the
needdestroy flag is set, then we use __sip_pretend_ack to kill the remaining
outstanding packets so that the monitor thread can destroy the sip_pvt.
I ran two separate tests. First, I placed a call from my Aastra phone to my
Polycom phone. I hung up the Aastra before the Polycom answered. I verified
through sip debug output that Asterisk properly ACKed the 487 received from the
Polycom.
For my second test, I set up a SIPp UAS scenario so that it would send a 200 OK
in response to a CANCEL but would not send a 487 for the original INVITE. I
verified that after about 40 seconds, Asterisk properly cleans up the outgoing
sip_pvt for the call.
Review: https://reviewboard.asterisk.org/r/308
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@205877 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If an endpoint sends two registration requests in a very short
period of time with the same nonce, both receive 401 responses
from Asterisk, each with a different nonce (the second 401
containing the current nonce and the first one being stale).
If the endpoint responds to the first 401, it does not match
the current nonce so Asterisk sends a third 401 with a newly
generated nonce (which updates the current nonce)... Now if
the endpoint responds to the second 401, it does not match the
current nonce either and Asterisk sends a fourth 401 with a
newly generated nonce... This loop goes on and on.
There appears to be a simple fix for this. If the nonce from
the request does not match our nonce, but is a good response
to a previous nonce, instead of sending a 401 with a newly
generated nonce, use the current one instead. This breaks
the loop as the nonce is not updated until a response is
received. Additional logic has been added to make sure no
nonce can be responded to twice though.
(closes issue #15102)
Reported by: Jamuel
Patches:
patch-bug_0015102 uploaded by Jamuel (license 809)
nonce_sip.diff uploaded by dvossel (license 671)
Tested by: Jamuel
Review: https://reviewboard.asterisk.org/r/289/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@205804 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With this change, we make note of Record-Route headers present in any SUBSCRIBE
request that we receive so that our outbound NOTIFY requests will have the proper
Route headers in them.
(closes issue #14725)
Reported by: ibc
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@205775 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a DNS lookup fails on a host or outboundproxy.
(closes issue #13432)
Reported by: p_lindheimer
Patches:
outboundproxy.patch uploaded by p (license 558)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@204300 65c4cc65-6c06-0410-ace0-fbb531ad65f3
chan_sip has had a problem for quite a long time that would manifest when
Asterisk would send multiple SIP responses on the same dialog before receiving
a response. The problem occurred because chan_sip only kept track of the highest
outgoing sequence number used on the dialog. If Asterisk sent two requests out,
and a response arrived for the first request sent, then Asterisk would ignore
the response. The result was that Asterisk would continue retransmitting the
requests and ignoring the responses until the maximum number of retransmissions
had been reached.
The fix here is to rearrange the code a bit so that instead of simply comparing
the sequence number of the response to our latest outgoing sequence number, we
walk our list of outstanding packets and determine if there is a match. If there is,
we continue. If not, then we ignore the response.
In doing this, I found a few completely useless variables that I have now removed.
(closes issue #11231)
Reported by: flefoll
Review: https://reviewboard.asterisk.org/r/298
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@204243 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change resolves a crash observed locally during some T.38 testing.
A call was set up using a call file, and when the T.38 reinvite came in,
the channel state was still AST_STATE_DOWN. The reason is explained by
a comment in the code that previously lived in the handling of
AST_STATE_RINGING. This change modifies the logic to handle the same
race condition for any channel state that is not UP.
(closes ABE-1895)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@203115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a CANCEL were received by Asterisk, we would send a 487 in response
to the original INVITE and a 200 OK for the CANCEL. If there were a network
hiccup which caused the 200 OK and the 487 to be lost, then the UA communicating
with Asterisk may try to retransmit its CANCEL. Asterisk's response to this used
to be to try sending another 487 to the canceled INVITE and another 200 OK to the
CANCEL.
The problem here is that the originally-sent 487 was sent "reliably" meaning that
it will be retransmitted until it is received properly. So when we receive the second
CANCEL it is likely that the first batch of 487s we sent is still going strong and
reaches the UA. The result was that the second set of 487s would be retransmitted
constantly until the maximum number of retries had been reached.
The fix for this is that if we receive a second CANCEL for an INVITE, then we cancel
the retransmission of the first set of 487s and start a second set. This causes the
dialog to be terminated reasonably.
(closes issue #14584)
Reported by: klaus3000
Patches:
14584_v2.patch uploaded by mmichelson (license 60)
Tested by: klaus3000
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@202341 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was a while loop in get_ip_and_port_from_sdp which was controlled
by a call to get_sdp_iterate. The loop would exit either if what we were
searching for was found or if the return was NULL. The problem is that
get_sdp_iterate never returns NULL. This means that if what we were searching
for was not present, the loop would run infinitely. This modification of the
loop fixes the problem.
(closes issue #15213)
Reported by: schmidts
(closes issue #15349)
Reported by: samy
(closes issue #14464)
Reported by: pj
(closes issue #15345)
Reported by: aragon
Patches:
sip_inf_loop.patch uploaded by mmichelson (license 60)
Tested by: aragon
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@202336 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Zombie channels could be passed, and chan_sip.c wasn't checking for it.
Could crash Asterisk. Now checking for NULL pointer.
(closes issue #15330)
Reported by: okrief
Tested by: dbrooks
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@201380 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When we receive a SIP reinvite, it is possible that we may not be able to process the
reinvite immediately since we have also sent a reinvite out ourselves. The problem is
that whoever sent us the reinvite may have also sent a reinvite out to another party,
and that reinvite may have succeeded.
As a result, even though we are not going to accept the reinvite we just received, it
is important for us to not have problems if we suddenly start receiving RTP from a new
source. The fix for this is to grab the media source information from the SDP of the
reinvite that we receive. This information is passed to the RTP layer so that it will
know about the alternate source for media.
Review: https://reviewboard.asterisk.org/r/252
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197588 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If we already have an address for a peer, and we are reloading the sip
configuration, try to use that address to contact the peer, instead of
getting it from the Contact.
(closes issue #15194)
Reported by: ibc
Patches:
sip.patch uploaded by eliel (license 64)
Tested by: manwe
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197562 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The presence of rport is now stored as a separate flag. Once the dialog is setup and authenticated
(or it passes through unauthenticated) the proper nat flag is set.
(closes issue #13823)
Reported by: dimas
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197466 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The loop detection/spiral detection code in chan_sip used the owner
channel's state as a criterion for determining if the incoming INVITE
is a looped request. The problem with this is that the INVITE-handling
code happens in a different thread than the thread that marks the owner
channel as being up. As a result, if a reinvite were to come in very quickly,
say from another Asterisk on the same LAN, it was possible for the reinvite
to arrive before the owner channel had been set to the up state.
This patch corrects the problem by using the invitestate of the sip_pvt
instead, since that can be guaranteed to be set correctly by the time
the reinvite arrives. Since there is a switch statement further in the
INVITE-handling code, the AST_STATE_RINGING state also checks the invitestate
of the sip_pvt in case we should actually be treating the channel as if it were
up already.
(closes issue #12215)
Reported by: jpyle
Patches:
12215_confirmed.patch uploaded by mmichelson (license 60)
Tested by: lmadsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@194484 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem was that the hangup code was setting the invitestate too early. The result of
this was that we would always send a CANCEL request, even if it was not an appropriate
time to do so (e.g. we have not yet received a provisional response for our INVITE).
Note that this same fix had been applied to trunk and the 1.6.X branches starting with
revision 155467. This is why you will see this revision being blocked from those places.
AST-216
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@193880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the fullcontact field appears in both the sippeers and the
sipregs table, then during reconstruction of the field, it will
otherwise be doubled.
(closes issue #14754)
Reported by: Alexei Gradinari
Patches:
20090506__bug14754.diff.txt uploaded by tilghman (license 14)
Tested by: lmadsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@192932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
