A Q.931 call has the 'transfer-cap' attribute set to 'udi' for data
calls. The ISUP module must pick this up and encode it in the
UseServiceInformation IE to preserve this vital information. Inversely,
a call arriving via ISUP must put its transfer-capability into the
'transfer-cap' attribute, so that when it's routed to Q.931 it is
preserved.
Without this transfer-capability transparency, no UDI/RDI data calls
or ISDN video calls can transition on the Q931/ISUP boundary
See also https://github.com/yatevoip/yate/issues/12
Patch written by mtelegin, rebased onto modern yate
Bug report:
https://web.archive.org/web/20220819114119/http://yate.null.ro/mantis/view.php?id=143
During the call between SIP phone and phone connected to FXS port on Digium TDM400P has been occured a lot of clicks on FXS port. Log files contains messages like "Buffer overrun ... Resource temporarily unavailable" and "Consumer errors: 29. Lost: 13920/262320". The fix is applied in patch. Tested only on Digium analog card TDM400P
while the smaller buffer length had a positive impact on
ISDN data calls, it breaks yate's handling of SIP/RTP to TDM calls.
Yate will start to emit 16ms packets with a buffer length of 128,
which will lead to broken call audio with many SIP providers.
Callforks support three types of call legs:
- regular
- auxiliar
- persistent
These different types change the behavior of how groups progress.
If no regular calls are left in a group, the fork progresses
immediately to the next group, drops all auxiliar children and keeps
the persistent ones. However, there is inconsistent behavior depending
on whether the creation of a call leg is successful or not.
Currently, the check if there are regular calls left in the current
group is only implemented in lostSlave(). So, if you have a group
with one persistent member (ringback) and one regular member, you can
observe different behavior in the case that routing for the member fails
and in the situation that the call is started but then rejected on a remote
end.
If the regular member is remote, forkSlave() will succeed and initiate a sip
call. The callContinue() function will return. Then, the sip call might fail
because the remote member is offline. Now lostSlave() is called, the module
detects that this was the last regular member and immediately progresses
to the next group.
If the regular member, however, is local, the routing knows that the member
is offline and fails. In this case forkSlave() will fail. Nonetheless, forks = 1
because creation of the persistent slave (ringback) was succesful. Consequently,
the call continues but it is ringing nowhere. In case that the next group is timed,
the caller will just hear the ringback for a while. If the next group isn't timed
but expected to progress if all calls in the current group have failed, the call
is actually stuck and the caller will hear the ringback indefinately while it is
nowhere ringing.
This patch fixes this behavior by checking if regular call legs are active before
returning from callContinue(). If this isn't the case, it will trigger progression
to the next group immediately.
If all fork children fail before any channel can
be created, the fork will always fail with error code
500. However, we can have such a situation because
all participants are offline and the routing returns
the respective error code.
In order to mitigate this, we update the error code
of the call.execute message of the fork. So, in the case
that all children fail before any channel can be established,
the caller will see the error code of the last child.
In an all-offline scenario this would be 404.
This new codec will get handled like RFC4040 in yrtpchan, ysipchan
and will just be handled as alaw audio in zapcard/DAHDI.
The zapcard code will set the udi bearer cap to any calls with the
clearmode format (which would get sent via SIP/SDP).
DAHDI has nice readable names for each span, there's no need to do any channel
calculations by hand. This change searches for a span with the specified name
and will use it's offset as the channel offset.
[octoi]
type=E1
offset=279
[auerswald]
type=E1
offset=31
becomes:
[octoi]
type=E1
span=trunkdev/octoi/0
[auerswald]
type=E1
span=TE8/0/2
which should be more reliable and less error-prone in the long run.
The user may suggest a given channel in the SETUP, but it's not legal
for the network to return a non-mandatory ChannelID.
See Q.931 Section 5.1.2 (B-channel selection - Originating):
The selected B-channel is indicated in the Channel identification information
element coded as "channel is indicated, no acceptable alternative" in the first
message returned by the network in response to the SETUP message (i.e. a SETUP
ACKNOWLEDGE or CALL PROCEEDING message)
In an earlier commit I had only fixed SETUP ACK, but missed that this is
a more general problem that needs addressing in whatever is the first
message containing a channelID yate sends in response to the SETUP.
yiax wrongly assumed that the ENCRYPTION IE is a single byte,
while in reality it is 16bit / 2 bytes.
It has been two bytes ever since it was introduced in Asterisk in 2004.
This misunderstanding probably arose from RFC5456 which erroneosly
states that the length of this IE is 0x01 while its body is 2 bytes
long (See Section 8.6.34 at https://datatracker.ietf.org/doc/html/rfc5456)
The user may suggest a given channel in the SETUP, but it's not legal
for the network to return a non-mandatory ChannelID.
See Q.931 Section 5.1.2 (B-channel selection - Originating):
The selected B-channel is indicated in the Channel identification information
element coded as "channel is indicated, no acceptable alternative" in the first
message returned by the network in response to the SETUP message (i.e. a SETUP
ACKNOWLEDGE or CALL PROCEEDING message)
If yate is operating in the 'network' role of a PRI interface,
it must send a valid ChannelID InformationElement in the SETUP ACK.
However, current yate code is encoding the channel selection field
of said information element wrong, as it unconditionally looks up
the s_dict_channelIDSelect_BRI (instead of _PRI).
This fixes a regression introduced in 2009 in the following commit:
commit 05b717e0b9
Author: paulc <paulc@acf43c95-373e-0410-b603-e72c3f656dc1>
Date: Mon Mar 2 18:51:30 2009 +0000
ISDN BRI support, most Andrei's (andrei@null.ro) work.
Fixes and new features throughout the signalling engine.
it-svn-id: http://yate.null.ro/svn/yate/trunk@2505 acf43c95-373e-0410-b603-e72c3f656dc1
Wait for whole SIP packet to be received/sent before sending it to the capture.
Capturing at socket level would send HEP packets containing SIP fragments.
Added atomic number class(es).
Pass atomic operation availability to everybody in configure script.
Use atomic number in NamedCounter.
Use atomic number for MessageHandler unsafe. Fixes concurrent increment introduced by RLock usage in dispatcher.
Added static String methods to be used with plain C strings: starts/end check, skip string or characters in given set.
Added support to build an AutoGenObject not owning the pointer.
MatchingItem: added dump support, added matching parameters, added random matching.