Various Q931 correctness fixes - #5
Open
laf0rge wants to merge 5 commits into
Open
Conversation
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 05b717e0b94ca682a40c7685ef9b9442a6c1820a 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
This is important so udi/rdi doesn't get converted to speech.
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)
…s mandatory 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.
Author
|
Dear yate team, it has been multiple months without any feedback here. Do you have any change requests? We're more than haappy to adjust our patches if you have any. I believe all of those fixes address real bugs in yate's Q.931 code! |
Surely, the treatment of the *called* party type/plan should not depend on the *calling* party type/plan.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sicne we started to use yate in the Osmocom OCTOI (Osmocom Community TDM over IP) network, we encountered a number of problems in the Q.931 implementation while interoperating with a variety of EuroISDN equipment.
This pull request fixes those Q.931 bugs.