Update the documentation in sip.conf.sample in order to make it more clear
that directmedia/canreinvite do not cause Asterisk to ignore reINVITEs. It
is only used to stop Asterisk from generating a reINVITE, but does not stop
it from accepting them if necessary.
(closes issue #15644)
Reported by: lmadsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@226382 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The shrinking of caller id removes '(', ' ', ')', non-trailing '.',
and '-' from the string. This means values such as 555.5555 and
test-test result in 555555 and testtest. There are instances,
such as Skype integration, where a specific value is passed via
caller id that must be preserved unmodified. This patch makes
the shrinking of caller id optional in chan_sip and chan_iax in
order to support such cases. By default this option is on to
preserve previous expected behavior.
(closes issue #15940)
Reported by: dimas
Patches:
v2-15940.patch uploaded by dimas (license 88)
15940_shrinkcallerid_trunk.c uploaded by dvossel (license 671)
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/408/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@225032 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new field "portinuri" to the sip dialog struct and the sip peer struct. That field is used during RURI generation to determine if the port should be included in the RURI. It is also used in some places to determine if an SRV lookup should occur.
(closes issue #14418)
Reported by: klaus3000
Tested by: klaus3000, mnicholson
Review: https://reviewboard.asterisk.org/r/369/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@221360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Be default, change SSRC when doing an audio stream changes Asterisk doesn't
honor marker bit when reinvited to already-bridged RTP streams,resulting in
far-end stack discarding packets with "old" timestamps that areactually part of
a new stream. This patch sends AST_CONTROL_SRCUPDATE whenever there is a
reinvite, unless the 'constantssrc' is set to true in sip.conf.
The original issue reported to Digium support detailed the following situation:
ITSP <-> Asterisk 1.4.26.2 <-> SIP-based Application Server Call comes in
fromITSP, Asterisk dials the app server which sends a re-invite back
toAsterisk--not to negotiate to send media directly to the ITSP, but to
indicatethat it's changing the stream it's sending to Asterisk. The app
servergenerates a new SSRC, sequence numbers, timestamps, and sets the marker
bit on the new stream. Asterisk passes through the teimstamp of the new stream,
butdoes not reset the SSRC, sequence numbers, or set the marker bit.
When the timestamp on the new stream is older than the timestamp on the
originalstream, the ITSP (which doesn't know there has been any change) discards
the newframes because it thinks they are too old. This patch addresses this by
changing the SSRC on a stream update unless constantssrc=true is set in
sip.conf.
Review: https://reviewboard.asterisk.org/r/374/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@221086 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
improve the security of various installations. As this does not change
any default behavior, it is not classified as a direct security fix for
anything within Asterisk, but may help PBX admins better secure their
SIP servers.
(closes issue #11776)
Reported by: ibc
Patches:
20080829__bug11776.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76, blitzrage
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@142865 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Normally we try not to change our software for bugs in other devices. But in
this case, the Cisco phones are so widespread so we try to implement a fix while
waiting for a bugfix from Cisco.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@48982 65c4cc65-6c06-0410-ace0-fbb531ad65f3
when chan_local or chan_agent is involved in the call.
I don't know how big a fix that would be to solve, but this is
the current state of affairs.
(Chan_sip currently checks if the other side of the bridge
has a SIP tech. We could/should implement another check,
possibly for udptl_write or some flag in the ast_channel
structure).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@48264 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Encapsulate RTP timers in the rtp structure so we have one for video and one for audio
The video one is not used in 1.4, really. Will be used for RTP keepalives when we can send
something that video phones support in the RTP stream.
I now this is a big architectual change at this stage for 1.4, but decided it was needed
to avoid future bug reports.
- Document the RTP NAT keepalive option in sip.conf.sample
Issue 7679 in the bug tracker. Please test.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@48199 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Remove support for T.38 early media, since it's impossible.
(Two patches in one - extra friday evening offer due to being off line from svn today... :-)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@48177 65c4cc65-6c06-0410-ace0-fbb531ad65f3
queues and manager a bit better.
Like in 1.2, you will get more detailed information if you set a call
limit for a device. When the call limit is reached, the status system will
report a device as busy.
For queues, setting a call limit per SIP device is propably a requirement.
In most cases, it will work much better if you only use type=peer and not
type=friend. We might decide to backport the new setting from trunk to
apply all call limits to the peer part of a friend only.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@48113 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Technically, ooh323 doesn't support it yet, but there is a patch that should be committed very soon.
Issue #7989, patch by DEA, slightly modified.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@43344 65c4cc65-6c06-0410-ace0-fbb531ad65f3
be seen in the code. Did it exist, was it planned to exist
or was it documentationware only? Ask Dr Asterisk.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@37324 65c4cc65-6c06-0410-ace0-fbb531ad65f3
