Don't go the ringing state until we really get the 180 response.
Log potetial re-INVITEs.
Simpler version of SIPEngine::sameINVITE just checks CSeq, on the assumption that CallID already matched when we searched the transaction table.
Faster and does not rely on string conversion.
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@4347 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Changes in SIP logging.
* Change "cannot parse" message to "out of place" and downgrade it.
* When we get a re-INVITE, log at the CRIT level.
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@4346 19bc5d8c-e614-43d4-8b26-e1612bc8e597
UHD accepts optional 'args' that can be used for device descriptions
such as IP address, device type, etc. Allow these to be passed in on
the transceiver command line as the third argument (number of supported
carriers is the second argument). This option benefits those who may
have multiple UHD devices attached to a single system.
This option is not yet supported by GSM core and requires starting the
transceiver independently on the command line. This option has no
effect when USRP1 is used.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@4315 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Make gTransactionTable.clearDeadEntries() much less agressive. See ticket #1128 for an example of the problem that can cause.
Also includes commented-out code for a method on TransactionTable to detect busy users, but we didn't need it.
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@4175 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Detect busy users and respond with 486 Busy Here.
This fixes one complaint, but is a stop-gap until we implement a proper multi-transaction state machine in GSM L3.
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@4174 19bc5d8c-e614-43d4-8b26-e1612bc8e597
SIPEngine::instigator now based on a flag instead of a string comparison.
For some reason that we need to understand, string comparisons on oSIP messages are really not reliable.
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@4173 19bc5d8c-e614-43d4-8b26-e1612bc8e597
The appearance of underruns on B100 due to the latency transmit
window scares people. These should not be logged at ERROR level
because the events are generally not real errors. So use the same
behaviour of USRP1 of not logging these events. The presence of
underrun events can be determined by changes in the latency window
that is shown with log level set at INFO.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@3988 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Allowing the underrun flag to reset will prevent a single event from
causing large jumps in the transmit latency threshold. This should
keep unreasonable timing latencies from occurring (e.g. latencies of
20+ frames).
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@3981 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Put a floor on the transmit latency of the B100 in order to suppress
underruns in typical conditions. Empirical data from a handful of
relatively recent machines shows that the B100 will underrun when
the transmit threshold is reduced to a time of 6 and a half frames,
so we set a minimum 7 frame threshold.
The overall benefit should be marginal and may increase the
possibility of bursts arriving stale (after the trasmit deadline),
but will reduce the number of alarming UHD related messages that
appear in the log file.
This patch is UHD and B100 specific - USRP1 is unaffected.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@3980 19bc5d8c-e614-43d4-8b26-e1612bc8e597
re-invites, though the specific effect of this depends on the client
sending the re-invite. In the case of FS, it causes the RTP stream to
break. We also now complain when invites time out, sending an alert to the
user about the proxy status.
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@3810 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Transmit gain setting would deceptively set the receive
gain instead. Since transmit attenuation is a combination
of RF gain and digital scaling, this major copy/paste bug
may have gone unnoticed by many users.
Reported-by: Robin Coxe <coxe@close-haul.com>
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@3309 19bc5d8c-e614-43d4-8b26-e1612bc8e597
The "Loss of monotonic time" error occurs when a timestamp
arrives from the device that is earlier in time than the
previous timestamp. The output is an ALERT level message
generally accompanied by a transmit side timeout from the
device.
UHD: Loss of monotonic time
UHD: Loss of monotonic time
UHD: Device send timed out
Add to the error description the timestamp values that
generated the error and output with ALERT rather than
ERR log.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@3307 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Basically the unpack method and fillField method assume MSB-first bit packing. The unpack method calls fillField for each byte that needs to be unpacked. The problem occurs on its final call to fillField when it has a partial byte to unpack; it uses the LSB bits instead of the MSB bits.
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@3288 19bc5d8c-e614-43d4-8b26-e1612bc8e597
control flows. Basically, there was a small bug where I forgot to listen
for an OK, which caused transactions to stick around too long and fuck
everything up. That was quickly fixed, but my compulsion required me to
reorganize the code to avoid such errors in the future. I implemented
another new feature as well, we now respond with a 480 Temporarily
Unavailable message (rather than cancel) when canceling an INCOMING call.
The prior behavior was incorrect.
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@3264 19bc5d8c-e614-43d4-8b26-e1612bc8e597
