- Remove unused string in sip_registry -- "random"
- Someone added a function in the middle of all forward declarations... Weird. Moved it out of that
section.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Add variable for number of known media streams instead of hardcoding in definition of sip_pvt
- Rename "text" to "codecs" - beacuse it's what it is
- Add documentation for future developers so that we make sure that we define new sdp media types
for SRTP-variants
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r216430 | oej | 2009-09-04 15:45:48 +0200 (Fre, 04 Sep 2009) | 27 lines
Make apps send PROGRESS control frame for early media and fix too early media issue in SIP
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/trunk@216438 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was a problem in the function responsible for doing peer matching by
IP address and port number such that during the second pass for checking for
a peer configured with insecure=port, it would end up treating every peer as
if it had been configured that way. These changes fix the logic in the peer
IP and port comparison callback to handle insecure=port checking properly.
This problem was introduced when SIP peers were converted to astobj2. Many
thanks to dvossel for noticing this while working on another peer matching
issue.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216368 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added detection of DTMF tone energy levels on FXO channels in chan_dahdi
monitoring loop so DTMF CID can be detected without the need of a polarity
change precursor.
(closes issue #9096)
Reported by: fleed
Patches:
9096-chan_dahdi-trunk.diff uploaded by dbailey (license 819)
Tested by: cyberplant, sum, maturs
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216094 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r215682 | twilson | 2009-09-02 16:41:22 -0500 (Wed, 02 Sep 2009) | 18 lines
Re-send non-100 provisional responses to prevent cancellation
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/trunk@215758 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are several instances where a port is parsed
from a uri or some other source and converted to
an int value using atoi(), if for some reason the
port string is empty, then a standard port is used.
This logic is used over and over, so I created a function
to handle it in a safer way using sscanf().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215681 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If we had this from the start, debugging the 'parking not using configured parkinglot'
bug would have been easier.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
made analog_set_linear_mode return back the mode that was being overwritten
so it could be restored later.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215608 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now, the scheme passed to parse_uri can either be a
single scheme, or a list of schemes ',' delimited.
This gets rid of the whole problem of having to create
two buffers and calling parse_uri twice to check for
separate schemes.
Review: https://reviewboard.asterisk.org/r/343/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215522 65c4cc65-6c06-0410-ace0-fbb531ad65f3
keep-alive events are used by Sipura/Linksys for NAT keepalive.
There currently don't appear to be any problems with NAT, but
everytime a keep-alive event is received, Asterisk responds with a
"489 Bad event". This error may indicate to a user that NAT
problems exist just because this even is not supported. Now,
rather than respond with an error, the packet is consumed and
a "200 ok" is sent just to indicate we received the packet.
(issue #15084)
Patches:
chan_sip.keepalive.v1.diff uploaded by IgorG (license 20)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215466 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Thank oej for pointing out the fact that sip_new did not copy parkinglot from the peer
into the newly created channel.
(closes issue #15538)
Reported by: gracedman
Patches:
2009090100_sipnewparkinglot-161.diff.txt uploaded by mvanbaak (license 7)
With mod by me to also fix callparking as well (this uploaded patch only fixed retrieving a parked call)
Tested by: gracedman, mvanbaak
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215462 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Allows characters that are otherwise used as delimiters to be used within
certain fields (like the secret).
(closes issue #15008, closes issue #15672)
Reported by: tilghman
Patches:
20090818__issue15008.diff.txt uploaded by tilghman (license 14)
Tested by: lmadsen, tilghman
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@213098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add Connected Line Presentation (COLP) support to chan_dahdi/libpri as an
addition to issue 8824. This is the chan_dahdi/sig_pri portion. COLP
support is now available for any switch for which libpri supports COLP
(currently ETSI PTP, ETSI PTMP, and Q.SIG) with this patch.
(closes issue #14068)
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/340/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@213007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
