Name display issue

[mamtsev]

Hello!

I've got Calling Name display issue on Avaya side of ISDN trunk connection via QSIG protocol, protocol type = ECMA1 from both side.
A half of the calls are okay, Calling name is on Avaya phone display, the other half are without one, no Calling name, only extension.

CallingName always presents in SETUP messages. The only difference is InvokeID value which is positive when CallingName is on display, and negative when there's no CallingName presented on Avaya phone display.

POSSITIVE (OKAY case):

InfoElem: Facility (H'1C)

HexData: 2B91AA068001008201008B0100A11D02027ADD06042B0C0900A111040C4D616D7473657620412E532E020101


Length: 43 (H'2B)

ProtocolProfile: ROSE

NwFacExt:

sourceEntity: endPTNX

destEntity: endPTNX

InterprApdu: discardAnyUnrecogInvokePdu

Components:

invokeComp:

invokeID: 31453 (H'7ADD)

operationValue:

globalValue: callingName { 1 3 12 9 0 }

argument: A111040C4D616D7473657620412E532E020101

NameArg:

name:

namePresAllowed:

namePresAllowedExtended:

nameData: 4D616D7473657620412E532E {Mamtsev A.S.}

characterSet: iso8859-1


NEGATIVE (NOT OKAY case):
InfoElem: Facility (H'1C)

HexData: 2B91AA068001008201008B0100A11D02028D3406042B0C0900A111040C4D616D7473657620412E532E020101


Length: 43 (H'2B)

ProtocolProfile: ROSE

NwFacExt:

sourceEntity: endPTNX

destEntity: endPTNX

InterprApdu: discardAnyUnrecogInvokePdu

Components:

invokeComp:

invokeID: -29388 (H'8D34)

operationValue:

globalValue: callingName { 1 3 12 9 0 }

argument: A111040C4D616D7473657620412E532E020101

NameArg:

name:

namePresAllowed:

namePresAllowedExtended:

nameData: 4D616D7473657620412E532E {Mamtsev A.S.}

characterSet: iso8859-1

Might it be the reason why Avaya doesn't show Calling Name? How to fix it?

Does anyone happen to meet this issue before? Please, advice.

Thanks

SETUPS are in attachment

 

[Moriendi]

You can't tell the 4K the range from which to choose invokeID. It is defined by spec. Whether you check ITU, ETS or ISO spec, they all have the same information, it's a value of type INTEGER(-32768..32767). So the 4K is operating correctly. If you are sure that your calling name disappears when invokeID becomes negative, then it looks like a problem with the Avaya.

You do get some strange problems with QSIG when there is a protocol mismatch, when the protocol profile is different either side. Your setup shows ROSE, which is ECMA1, so you also need to make a quick check of an incoming message from the Avaya and make sure that is also ROSE and not Networking Extensions. They need to be the same. ECMA2 and PSS1V2 decode as Networking Extensions. I don't expect this is the problem here but I would still check.

ETS spec for ECMA1 GF encoding,

https://www.etsi.org/deliver/etsi_i_ets/300200_300299/300239/01_60/ets_300239e01p.pdf

page 73 11.3.3.4 shows ROSE encoding.
ISO spec for PSS1 GF encoding

https://standards.iso.org/ittf/PubliclyAvailableStandards/c036049_ISO_IEC_11582_2002(E).zip

page 54, again 11.3.3.4.
ECMA2 uses the ISO spec as above but with mild amendments, ETS 300 329.
ITU Q.932

https://www.itu.int/rec/T-REC-Q.932-199805-I/en

You don't need any of those links above, I was just checking to see if any of them specified invokeID as positive only, but they are all the same, INTEGER(-32768..32767).
I would focus on the Avaya config.

 

[mamtsev]

Thank you, Moriendi!

Yes, it worked when we switched to PSS1V2 protocol on 4K side.

On Avaya side for anyone whom it may concern:
Supplementary Service Protocol - b
Signaling Mode - ISDN-PRI
Connect - pbx
peer-protocol - q-sig

Appreciate!

 

[Moriendi]

If you've changed from ECMA1 to PSS1V2, check you still have audio above channel 15.

ECMA1 references the physical B channel, 1-15, 17-31.
ECMA2/PSS1V2 references the logical B channel, 1-30.

If you have a mismatched protocol, then the signalling appears to be OK, but above channel 15 the audio transmit and receive are one channel apart, causing no speech.

Quick way to test, change the 4K searchmode from ASCending to DeSCending, if it is not already, and make a test call. If there is good audio, there is no problem.

DIS-BUEND:1;
H500:  AMO BUEND STARTED
                                                                                
+------------------------------- FORMAT = L -----------------------------------+
|  TGRP NUMBER :    1    TGRP NAME   : PSTN               MAXIMUM NO.   :   30 |
|                        CHARCON     : NEUTRAL                                 |
|  SUBGROUP NO.:    43   DEVICE TYPE : S2COD              TRACENO       :    0 |
|  SEARCH MODE : [b]ASCENDING[/b]                                ACD THRESHOLD :    * |



[b]CHA-TDCSU:PEN=1-1-1-0,SRCHMODE=DSC[/b];
H500:  AMO TDCSU STARTED
H22: SRCHMODE OF TGRP 1 CHANGED INTO DSC

AMO-TDCSU-111       DIGITAL TRUNKS                                              
CHANGE COMPLETED;

 

[thepfy]

On the Avaya status trunk xxxx (xxxx being the card) should give the channel statuses.
status signalling group xx may be useful as well.

 

[mamtsev]

Yeap! About no speech problem, met this many times, know where to fix. Thank you for hints, folks! Very productive!

By the way I would appreciate if you'd take a look at this one

https://www.tek-tips.com/viewthread.cfm?qid=1807181

Thank you!