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
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).
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
Use pointer hashing function in accessing list that tracks JS objects.
git-svn-id: http://voip.null.ro/svn/yate@6448 acf43c95-373e-0410-b603-e72c3f656dc1
Add command that reports how many objects are still alive that have been created at the reported code line.
Fix constructor for ConfigFile.
git-svn-id: http://voip.null.ro/svn/yate@6442 acf43c95-373e-0410-b603-e72c3f656dc1