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
This commit fixes the scenario where an incoming call is authenticated
using a peer entry. Previously the channel name was created using either
the username setting from the sip.conf entry or the IP address that the
call came from. Now the channel name will be created using the peer name
itself. This commit will not change the way the channel name is generated
for users or friends.
(closes issue #14256)
Reported by: Nick_Lewis
Patches:
chan_sip.c-chname.patch uploaded by Nick (license 657)
Tested by: Nick_Lewis, file
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@188946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC 5047 explains the proper course of action to take if a
reINVITE is received before the ACK from a previous invite
transaction. What we are to do is to treat the reINVITE as
if it were both an ACK and a reINVITE and process it normally.
Later, when we receive the ACK we had been expecting, we will
ignore it since its CSeq is less than the current iseqno of
the sip_pvt representing this dialog.
(closes issue #13849)
Reported by: klaus3000
Patches:
13849_v2.patch uploaded by mmichelson (license 60)
Tested by: mmichelson, klaus3000
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@187484 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Acknowledgement for 491 responses were never being processed because it didn't match our pending invite's seqno. Since the ACK was never processed, the 491 frame would continue to be retransmitted until eventually the call was dropped due to max retries. Now during a pending invite, if we receive another invite, we send an 491 and hold on to that glare invite's seqno in the "glareinvite" variable for that sip_pvt struct. When ACK's are received, we first check to see if it is in response to our pending invite, if not we check to see if it is in response to a glare invite. In this case, it is in response to the glare invite and must be dealt with or the call is dropped. I've changed the wait time for resending the re-Invite after receving a 491 response to comply with RFC 3261. Before this patch the scheduled re-Invite would only change a flag indicating that the re-Invite should be sent out, now it actually sends it out as well.
(closes issue #12013)
Reported by: alx
Review: http://reviewboard.digium.com/r/213/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@185845 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We now answer with matching media streams to what is requested. If an INVITE
is received with both a T38 and RTP media stream this means we answer with both.
For any outgoing calls created as a result of this inbound one no T38 is requested
in the initial INVITE. Instead if we start receiving udptl packets we trigger a
reinvite on the outbound side.
(closes issue #12437)
Reported by: marsosa
Tested by: pinga-fogo, okrief, file, afu
Review: http://reviewboard.digium.com/r/208/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@184947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If calls were placed using an IP address or hostname the global nat setting was copied over
but was not set on the RTP session itself. This caused the RTP stack to not perform symmetric RTP
actions.
(closes issue #14546)
Reported by: acunningham
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@184565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A user was having an issue where if an outgoing SIP call was canceled, the SIP device
would remain in use if we had not received any response to the initial INVITE we sent out.
The SIP device would remain in use until the autocongestion timer was exhausted.
I tracked down the cause of this to be the section of code I am removing here. I asked several
people what the purpose of this code was meant to be, but no one could give me any sort of
answer as to why this was here. The person who was having this issue has been using this patch
for several months and it has stopped the problems they have had.
AST-196
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@183115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If we receive an INVITE from an endpoint and then later receive a BYE from that
same endpoint before we have sent a final response for the INVITE, then we need
to respond to the INVITE with a 487.
There was logic in the code prior to this commit which seemed to exist solely to
handle this situation, but there was one condition in an if statement which
was incorrect. The only way we would send a 487 was if the sip_pvt had no owner
channel. This made no sense since we created the owner channel when we received
the INVITE, meaning that the majority of the time we would never send the 487.
The 487 being sent should not rely on whether we have created a channel. Its
delivery should be dependent on the current state of the initial INVITE transaction.
With this commit, that logic is now correctly in place.
(closes issue #14149)
Reported by: legranjl
Patches:
14149.patch uploaded by mmichelson (license 60)
Tested by: legranjl
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@181768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When completing an attended transfer chan_sip does a check to make sure the extension
in the URI portion of the Refer-To header is a local valid extension. We don't actually
need to check this since we know for sure the other channel is already up and talking to
the extension. Some devices do not put the extension in the Refer-To header either, which
can cause the extension check to fail. We now no longer do this check if it is an attended
transfer.
(closes issue #14628)
Reported by: sverre
Patches:
14628.diff uploaded by file (license 11)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@181328 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When dtmfmode was set to auto the inband DTMF detector was not setup
on outgoing SIP calls. This caused inband DTMF detection to fail.
The inband DTMF detector is now setup for both dtmfmode inband and auto.
(closes issue #13713)
Reported by: makoto
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@181295 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The main problem here was that cstdlib was undefining free thereby causing the
proper debug macros to not be used. ast_h323.cxx has been changed to call
ast_free instead to avoid the issue. Because using the ast prefix calls are
a better choice, ast_free_ptr is the new wrapper for free to pass to functions.
Also, a little bit of clean up was done to avoid the debug macros intentionally
being redefined.
(closes issue #13593)
Reported by: pj
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@181133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since the remote side is not actually subscribing to a specific extension when
subscribing for MWI just skip the check to see if the extension exists. They can't use it
to specify the mailbox either since we require configuration of that in sip.conf
(closes issue #14531)
Reported by: festr
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@178205 65c4cc65-6c06-0410-ace0-fbb531ad65f3
restarted, instead waiting until the next registration. We're now
caching the qualify across a reload/restart and starting the qualify
immediately upon loading the peer.
(closes issue #14196)
Reported by: pdf
Patches:
20090120__bug14196_1.4.diff.txt uploaded by pdf (license 663)
Tested by: pdf
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@176426 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This issue crept up with subscriptions on the AA50. When an outgoing NOTIFY is sent a new branch value
is created and the Via header is changed to reflect it. Since this was a stringfield a new spot in the
pool was used for the value while the old was left untouched/unused. If the current pool was full a new
pool was created. This would cause memory usage to increase steadily.
(issue #AA50-2332)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@176029 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC 3263 says to do A record lookups on a hostname
if a port has been specified, so that's what we're
going to do. See section 4.2.
(closes issue #14419)
Reported by: klaus3000
Patches:
patch_chan_sip_nosrvifport_1.4.23.txt uploaded by klaus3000 (license 65)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@174282 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and sip_uri_params_cmp()
The reporter didn't actually upload a properly-formed patch, instead a
modified chan_sip.c file was uploaded. I created a patch to determine the
changes, then modified the suggested changes to create a proper fix. The
summary above is a complete description of the changes.
(closes issue #13547)
Reported by: tecnoxarxa
Patches:
chan_sip.c.gz uploaded by tecnoxarxa (license 258)
Tested by: tecnoxarxa
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@174082 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With this fix, we only will perform an SRV lookup at the following times:
* The first time we register with a remote registrar
* If we send a REGISTER but do not receive a response
* If the sendto() function returns an error
While I wrote the patch that fixes this issue, a huge amount of credit is due
to Brett Bryant, who wrote the initial patch on which I based this one.
(closes issue #12312)
Reported by: jrast
Patches:
12312.patch uploaded by putnopvut (license 60)
Tested by: blitzrage
Review: http://reviewboard.digium.com/r/132/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@173770 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch implements a temporary storage in the pvt and use that instead.
The code is based on ideas from code from Adomjan in issue #13385 (Add support for Reason: header)
Thanks to Klaus Darillion for testing!
(closes issue #14294)
related to issue #13385
Reported by: klaus3000 and adomjan
Patches:
bug14294b.diff uploaded by oej (license 306)
Based on 20080829_chan_sip.c-q850reason_header.patch uploaded by adomjan (license 487)
Tested by: oej, klaus3000
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@172169 65c4cc65-6c06-0410-ace0-fbb531ad65f3
