search

yatevoip / yate

Yate - Yet Another Telephony Engine
GNU General Public License v2.0
45 stars 14 forks source link

Q.931 PROGRESS created from ISUP CPR is broken #14

Open laf0rge opened 9 months ago

laf0rge commented 9 months ago

Situation: Q.931 subscriber calls another subscriber that is reached via ISUP.

SETUP gets translated to IAM just fine. Then, a CPR is sent from the ISUP switch (EWSD) which yate translates to a truncated PROGRESS:

2023-12-04_18:57:29.006885 <jpesak_ss7_isup/ISUP:INFO> Received message (0x7fe57c003870)
-----
CPR [cic=4 label=2-229-5:0-0-1:4]  02 01 03 04 1e 02 81 88 00
  protocol-type='itu-t'
  message-type='CPR'
  EventInformation='progress'
  AccessTransport='1e 02 81 88'
-----
2023-12-04_18:57:29.009521 <sig/4:CALL> Call progressing [0x7fe560018ad0]
2023-12-04_18:57:29.010649 <sig/3:CALL> Call progressing [0x7fe56c001b50]
2023-12-04_18:57:29.010700 <nt2mku/Q931:NOTE> sigMsg=0x7fe5ac029c80
2023-12-04_18:57:29.010995 <nt2mku/Q931:NOTE> inbandAvail=0
2023-12-04_18:57:29.011128 <nt2mku/Q931:INFO> Sending message (0x7fe56800afe0)
-----
PROGRESS
  [From initiator=false CallRef=8]   08 02 80 08 03
-----

That PROGRESS is in violation of Q.931 as it misses the mandatory Progress IE, see Q.931 section 3.2.6.

laf0rge commented 9 months ago

So it seems that ISUP is encapsulating Q.931 information elements using the AccessTransport IE (see Q.763 Section 3.3). yate is apparently only parsing the outer layer resultign in an opaque AccessTransport parameter wit h value `1e 02 81 88'.

So IMHO, either the ISUP side needs to parse the contents and pass it along in a way that the Q.931 module can understand it - or the Q.931 module must be able to take a raw/encoded/opaque IE from ISUP and put that in the Q.931 message.