Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ISDN data and video call bearer type not preserved between ISUP and Q931 #12

Open
laf0rge opened this issue Dec 3, 2023 · 0 comments
Open

Comments

@laf0rge
Copy link

laf0rge commented Dec 3, 2023

When routing q Q.931 call with bearer-cap=udi to ISUP, the bearer capability information is lost and the ISUP IAM is sent with "Information Transfer Capability: Speech" instead.

Oddly enough, yate does seam to notice a difference, as an actual speec call SETUP -> IAM looks like this:

SETUP
  [From initiator=true CallRef=34]   08 02 00 22 05
  Bearer capability (codeset=0 type=4)   04 03 90 90 a3
    transfer-cap=3.1khz-audio
    transfer-mode=circuit
    transfer-rate=64kbit
    layer1-protocol=alaw
  Channel identification (codeset=0 type=24)   18 03 a1 83 81
    interface-bri=false
    channel-exclusive=false
    d-channel=false
    channel-select=present
    channel-by-number=true
    type=B
    channels=1
  Calling number (codeset=0 type=108)   6c 0d 41 80 30 33 30 31 32 33 34 32 31 31 31
    type=subscriber
    plan=isdn
    presentation=allowed
    screening=user-provided
    number=03012342111
...
IAM [cic=15 label=0-0-1:2-229-5:15]  00 00 00 0a 00 02 0b 09 84 90 24 50 54 12 03 20 0f 0a 08 04 11 94 03 21 43 12 11 1d 03 80 90 a3 00^M
  CalledPartyNumber='420545213002.'
  CalledPartyNumber.inn='false'
  CalledPartyNumber.nature='international'
  CalledPartyNumber.plan='isdn'
  CallingPartyCategory='ordinary'
  CallingPartyNumber='493012342111'
  CallingPartyNumber.nature='international'
  CallingPartyNumber.plan='isdn'
  CallingPartyNumber.restrict='allowed'
  CallingPartyNumber.screened='user-provided-passed'
  CallingPartyNumber.complete='true'
  UserServiceInformation='alaw'

While the SETUP + IAM for te data call (actually an ISDN video phone) looks like this:

SETUP
  [From initiator=true CallRef=33]   08 02 00 21 05
  Bearer capability (codeset=0 type=4)   04 02 88 90
    transfer-cap=udi
    transfer-mode=circuit
    transfer-rate=64kbit
  Channel identification (codeset=0 type=24)   18 03 a1 83 81
    interface-bri=false
    channel-exclusive=false
    d-channel=false
    channel-select=present
    channel-by-number=true
    type=B
    channels=1
  Calling number (codeset=0 type=108)   6c 0d 41 80 30 33 30 31 32 33 34 32 31 32 31
    type=subscriber
    plan=isdn
    presentation=allowed
    screening=user-provided
    number=03012342121
...
IAM [cic=26 label=0-0-1:0-8-0:26]  00 00 00 0a 00 02 09 07 03 90 64 44 77 03 30 0a 07 03 10 03 21 43 12 12 1d 02 80 90 00
  CalledPartyNumber='4644773003'
  CalledPartyNumber.inn='false'
  CalledPartyNumber.nature='national'
  CalledPartyNumber.plan='isdn'
  CallingPartyCategory='ordinary'
  CallingPartyNumber='3012342121'
  CallingPartyNumber.nature='national'
  CallingPartyNumber.plan='isdn'
  CallingPartyNumber.restrict='allowed'
  CallingPartyNumber.screened='user-provided'
  CallingPartyNumber.complete='true'
  UserServiceInformation=''

Note that the UserServiceInformation is empty in the latter call, while it is "alaw" in the voice call. However, it seems that the empty UserServiceInformation is then encoded as voice, as the pcap file clearly indicates voice.

laf0rge added a commit to osmocom/yate that referenced this issue Dec 3, 2023
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 yatevoip#12
sur5r pushed a commit to eventphone/yate that referenced this issue Jan 16, 2024
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 yatevoip#12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant