Messages

16

Yate bugs / Re: No Prgress Indicator in q931 PROGRESS

« on: September 21, 2015, 02:08:42 AM »

Hello, something is missing in libs/ysig/q931.cpp ---> bool ISDNQ931Call::sendProgress(SignallingMessage* sigMsg), I have modified this function to Alerting Message, so Now I am able to place a call, but still get "(96): Mandatory information element is missing" after PROGRESS:

L3->L2 : 21.09.2015 09:57:30
  ETSI Message Type DCHAN: x07 CALLREF: x0062 MSG = SETUP
  ETSI Information Element Identifier
Bearer Capability  Len: x03, Data: x9090A3    3.1 kHz audio
Channel Ident.     Len: x03, Data: xA18381
Progress Indicator Len: x02, Data: x8183
CallingPartyNumber Len: x0B, Data: x2180333234323838353032  'xxxxxxxxx'
                    Type Of Number: National number
                    Numbering Plan: ISDN/telephony numbering plan
                    Presentation Indicator: Presentation allowed
                    Screening Indicator: User-provided, not screened
CalledPartyNumber  Len: x0A, Data: x81363031313030363031  'yyyyyyyyy'
                    Type Of Number: Unknown
                    Numbering Plan: ISDN/telephony numbering plan

L2->L3 : 21.09.2015 09:57:30 08 02 80 62 02 18 03 A1 83 81
  ETSI Message Type DCHAN: x07 CALLREF: x8062 MSG = CALL PROCEEDING
  ETSI Information Element Identifier
Channel Ident.     Len: x03, Data: xA18381

L2->L3 : 21.09.2015 09:57:32 08 02 80 62 03
  ETSI Message Type DCHAN: x07 CALLREF: x8062 MSG = PROGRESS

L3->L2 : 21.09.2015 09:57:32 08 02 00 62 7D 08 03 81 E0 1E 14 01 03
  ETSI Message Type DCHAN: x07 CALLREF: x0062 MSG = STATUS
  ETSI Information Element Identifier
Cause              Len: x03, Data: x81E01E  (96): Mandatory information element is missing
x14                Len: x01, Data: x03

L2->L3 : 21.09.2015 09:57:32 08 02 80 62 01
  ETSI Message Type DCHAN: x07 CALLREF: x8062 MSG = ALERTING

L2->L3 : 21.09.2015 09:57:33 08 02 80 62 07
  ETSI Message Type DCHAN: x07 CALLREF: x8062 MSG = CONNECT

L3->L2 : 21.09.2015 09:57:33 08 02 00 62 0F
  ETSI Message Type DCHAN: x07 CALLREF: x0062 MSG = CONNECT ACK

L3->L2 : 21.09.2015 09:57:38 08 02 00 62 45 08 02 80 90
  ETSI Message Type DCHAN: x07 CALLREF: x0062 MSG = DISCONNECT
  ETSI Information Element Identifier
Cause              Len: x02, Data: x8090   (16): Normal call clearing

L2->L3 : 21.09.2015 09:57:38 08 02 80 62 4D 08 03 0A 80 90
  ETSI Message Type DCHAN: x07 CALLREF: x8062 MSG = RELEASE
  ETSI Information Element Identifier
Cause              Len: x03, Data: x0A8090


This is My modification, but I know it isin't good, but Now I am able to place a call, is there a way that someone could fix it ? To add ProgressIndicator only to PROGRESS message?

bool ISDNQ931Call::sendProgress(SignallingMessage* sigMsg)
{
    MSG_CHECK_SEND(ISDNQ931Message::Progress)
    const char* format = 0;
    if (sigMsg) {
        format = sigMsg->params().getValue(YSTRING("format"));
        m_inbandAvailable = m_inbandAvailable ||
            sigMsg->params().getBoolValue(YSTRING("earlymedia"),false);
        if (m_inbandAvailable)
            SignallingUtils::appendFlag(m_data.m_progress,"in-band-info");
    }
    if (format)
        m_data.m_format = format;
    // Change state, send message
    changeState(CallReceived);
    ISDNQ931Message* msg = new ISDNQ931Message(ISDNQ931Message::Progress,this);
    if (m_rspBearerCaps) {
        m_data.processBearerCaps(msg,true);
        m_rspBearerCaps = false;
    }
    if (!m_channelIDSent) {
        if (!q931()->primaryRate()) {
            m_data.m_channelType = "B";
            if (m_circuit)
                m_data.m_channelSelect = lookup(m_circuit->code(),Q931Parser::s_dict_channelIDSelect_BRI);
            if (!m_data.m_channelSelect) {
                TelEngine::destruct(msg);
                return sendReleaseComplete("congestion");
            }
        }
        m_data.processChannelID(msg,true,&q931()->parserData());
        m_channelIDSent = true;
    }
    m_data.processProgress(msg,true);
    return q931()->sendMessage(msg,callTei());
}

Greetings

17

Yate bugs / No Prgress Indicator in q931 PROGRESS

« on: September 18, 2015, 05:33:30 AM »

Hello

Yate after ISUP :

CPR [cic=3 label=x-x-0:1-y-y:3]
  protocol-type='itu-t'
  message-type='CPR'
  EventInformation='progress'
  BackwardCallIndicators='charge,called-ordinary,e2e-none,isup-path,sccp-none'

Doesn't place Progress Indicator Len: x02, Data: x8188 in PROGRESS Message, here is Call Frow, so Site A release this call with "(96): Mandatory information element is missing":

L3->L2 : 18.09.2015 13:27:49
  ETSI Message Type DCHAN: x07 CALLREF: x0052 MSG = SETUP
  ETSI Information Element Identifier
Bearer Capability  Len: x03, Data: x9090A3    3.1 kHz audio
Channel Ident.     Len: x03, Data: xA183
Progress Indicator Len: x02, Data: x8183
CallingPartyNumber Len: x0B, Data: x2180  'xxxxx'
                    Type Of Number: National number
                    Numbering Plan: ISDN/telephony numbering plan
                    Presentation Indicator: Presentation allowed
                    Screening Indicator: User-provided, not screened
CalledPartyNumber  Len: x0A, Data: x8136  'yyyyyyy'
                    Type Of Number: Unknown
                    Numbering Plan: ISDN/telephony numbering plan

L2->L3 : 18.09.2015 13:27:49 08 02 80 52 02 18 03 A1 83 81
  ETSI Message Type DCHAN: x07 CALLREF: x8052 MSG = CALL PROCEEDING
  ETSI Information Element Identifier
Channel Ident.     Len: x03, Data: xA18381

L2->L3 : 18.09.2015 13:27:51 08 02 80 52 03
  ETSI Message Type DCHAN: x07 CALLREF: x8052 MSG = PROGRESS

L3->L2 : 18.09.2015 13:27:51 08 02 00 52 7D 08 03 81 E0 1E 14 01 03
  ETSI Message Type DCHAN: x07 CALLREF: x0052 MSG = STATUS
  ETSI Information Element Identifier
Cause              Len: x03, Data: x81E01E   (96): Mandatory information element is missing
x14                Len: x01, Data: x03

L2->L3 : 18.09.2015 13:27:51 08 02 80 52 5A 08 03 0A 80 E5
  ETSI Message Type DCHAN: x07 CALLREF: x8052 MSG = RELEASE COMPLETE
  ETSI Information Element Identifier
Cause              Len: x03, Data: x0A80E5

18

Yate based projects / Re: Setting CalledPartyNumber.nature in ISUP

« on: September 09, 2015, 06:26:53 AM »

Hello

OK, I have handeled it by, I didn't know that DSS1 has this kind of parameters:

sig.callernumtype=international;
sig.callerscreening=network-provided;
sig.callednumtype=international;
sig.callednumplan=international

so finally I have:


sig.CalledPartyNumber.nature=international;
sig.CallingPartyNumber.screened=network-provided;
sig.TransmissionMediumRequirement=3.1khz-audio;
sig.callerscreening=network-provided;
sig.ForwardCallIndicators=international,isdn-orig,isup-path;
sig.CallingPartyNumber.nature=international;
sig.callernumtype=international;
sig.callerscreening=network-provided;
sig.callednumtype=international;
sig.callednumplan=international

Greetings

19

Yate based projects / Setting CalledPartyNumber.nature in ISUP

« on: September 09, 2015, 01:42:49 AM »

Hello

I'am using Sangoma A104. First port is with SS7 and ISUP, 2nd, 3rd, 4th are configured as DSS1.
When I try to send call from DSS to SS7, and try to set CalledPartyNumber.nature and CallingPartyNumber.nature to international. It doesn't work. Nature is always set by Incomming ISDN setup "Calling Party Number".
I am only able to change this Value for SIP calls comming to SS7, here is my route:

.*=sig/${called}.;link=isup1;sig.CalledPartyNumber.nature=international;sig.CallingPartyNumber.screened=network-provided;sig.CallingPartyNumber.nature=international

I works only for SIP calls, when I try to send CALL from ISDN from 4th port, nature is always set by Incomming Setup from that port. Is there a way to force overwrite this Variable ?

20

Yate bugs / Re: Sangoma + ISUP + error in the calculation of floating point

« on: September 04, 2015, 07:25:31 AM »

It is working fine, when I have configured rest 3 ports as "isdn-pri-cpe".

21

Yate bugs / Re: Sangoma + ISUP + error in the calculation of floating point

« on: September 04, 2015, 04:44:57 AM »

There is no problem with configuration as 4 PRA definded as "euro-isdn-e1", the problem is when configuration use "ss7-isup".

22

Yate bugs / Sangoma + ISUP + error in the calculation of floating point

« on: September 04, 2015, 02:32:52 AM »

Hello

Has someone solved issue that was posted to mailing group 22 Aug 2013:

http://yate.null.ro/archive/?action=show_msg&actionargs[]=86&actionargs[]=4

I have the same problem with Yate (6967), and WANPIPE Release: 7.0.14. When I disable:

;voicegroup=w1g2

in wpcard.conf MTP3 goes Up and operational:

module=sig,component=linkset1,type=ss7-mtp3;status=operational

and receive:

2015-09-04_10:28:45.781650 <linkset1:MILD> Received SLTM ITU,0-13-7:0-27-6:0 (111:222:0) wrong National NI with 6 bytes
2015-09-04_10:28:45.781722 <linkset1:MILD> Sending SLTA ITU,0-27-6:0-13-7:0 (222:111:0) with 6 bytes

When I enable "voicegroup=w1g2" in wpcard.conf. I get error:

Sep  4 10:29:41 ss7 kernel: [74482.610146] YSIG Trunk[7207] trap divide error ip:7f504ac59ae0 sp:7f5047b46dc0 error:0 in ysigchan.yate[7f504ac46000+29000]
Sep  4 10:29:41 ss7 kernel: [74482.612867] af_wanpipe: MAJOR ERROR, Data lost on sock release !!!

Yate reports:

The error in the calculation of floating point.

23

Yate users hangout place / Re: SS7 LAB

« on: May 08, 2015, 06:46:42 AM »

Hello

What CPU specification have You tested, what was system load during 30 simultaneous CALLs. Have You tested it with full 4xE1 load ?

Greetings

24

Yate bugs / Re: CIC in changing state true

« on: September 29, 2014, 05:47:02 AM »

Hello

I had situation with CIC in Reserved state. Incomming calls ware droped because Operator had CIC in Idle state, but my Yate had Reserved state.
control commands with block, ublock, release, reset didn't help to change state to Idle.

I had to shutdown E1 controler, to change State to Missing, after no shutdown CIC gone to Idle state.

Is there a way to make it by terminal command ?

Greetings

25

Yate users hangout place / Re: SIP User-to-User field to ISUP sig.UserToUserInformation

« on: July 30, 2014, 06:13:58 AM »

I works.

26

Yate users hangout place / Re: SIP User-to-User field to ISUP sig.UserToUserInformation

« on: July 30, 2014, 05:50:20 AM »

Hello

OK, now I know that sip headers are in ${sip_lowcase-name}, so I have ${sip_user-to-user} in from SIP to SS7,
and something like this:

.*=sig/${called}.;link=link-1;sig.UserToUserInformation=${sip_user-to-user}

How to get from SS7 do SIP this value ?

osip_user-to-user=${isup.UserToUserInformation} ?

Greetings

27

Yate users hangout place / SIP User-to-User field to ISUP sig.UserToUserInformation

« on: July 30, 2014, 04:45:38 AM »

Hello

I will need to pass User-to-User data from SIP-T to SS7 network in both directions.
Is there a way to do it ?
I have INVITE from SIP-T to Yate with:

INVITE sip:123456789@192.168.1.2 SIP/2.0
User-to-User: 12345678999

But how to place it in regexroute dialplan ? Is there some sip variable that contain this value ?

I have tried tu put constant value like:

.*=sig/${called}.;link=link-1;sig.UserToUserInformation=12345

But there wasn't any trap of it in sigdump file.

28

Yate bugs / CIC in changing state true

« on: March 04, 2014, 06:58:43 AM »

Hello

Has someone solve this issue ?

http://yate.null.ro/archive/?action=show_msg&actionargs[]=77&actionargs[]=87

I am using YATE 5.0.0-1 r5675 now, but still has problem when some of CICs goes to changing state.
block/unblock/available, shuting down controller doesn't help.

The is no information about this CICs in ysigdata.conf, our remote PC send calls to Us on CICs that we see as changing. So after that Our PC response:

circuit=456,span=E1-15,status=Idle,lockedlocal=false,lockedremote=false,changing=true,flags=0x15

<link-1/ISUP:NOTE> 'IAM' with cic=456: can't reserve circuit

And call is dropped.

Only restarting of Yate help to clear changing state CICs. Is there a way to clear changing CICs to false by control command or some other way ? Without restarting ?

Greetings
Andrzej