[SUrov_IBM]

Уважаемые гуру телефонии, как всегда приветствую Вас!

 

 

Имеется схема: ТфОП <=> УПАТС <=E1 QSIG=> CISCO 1760

 

CISCO от УПАТС по стыковке E1 QSIG получает вызов (вызывающий ТА УПАТС или DISA) на номер 2921:

Успешно проходит:

 

dial-peer voice 200 pots

destination-pattern 2921

translate-outgoing called 200

port 0/0:15

!

translation-rule 200

Rule 0 2921 0334xxxx

 

И поступает в ТфОП на номер 0334xxxx:

        Bearer Capability i = 0x8090A3

                Standard = CCITT

                Transfer Capability = Speech

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0xA98381

                Exclusive, Channel 1

        Calling Party Number i = 0x0183, '812318xxxx'

                Plan:ISDN, Type:Unknown

        Called Party Number i = 0x89, '0334xxxx'

                Plan:Private, Type:Unknown

        Channel ID i = 0xA98381

                Exclusive, Channel 1

 

В данном случае, вызов проходит нормально.

 

 

Но если, звонок от УПАТС поступил через переадресацию, например 2205 -> 2201 (безусловная переадресация УПАТС на 2921) ->2921 происходит следующая ситуация - CISCO игнорирует translation-rule 200 и отвечает в голосовом канале «длинный зуммер» (готовность набора для вызова), после чего можно набрать любой номер (DTMF) и согласно плану нумерации CISCO осуществить вызов абонента:

        Bearer Capability i = 0x8090A3

                Standard = CCITT

                Transfer Capability = Speech

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0xA1838A

                Preferred, Channel 10

        Calling Party Number i = 0x0980, '2205'

                Plan:Private, Type:Unknown

        Called Party Number i = 0x89, '2921'

                Plan:Private, Type:Unknown

        Channel ID i = 0xA9838A

                Exclusive, Channel 10

 

УПАТС и CISCO с обеих сторон используют «overlap» для передачи номера вызываемого абонента.
Если со стороны УПАТС установить «in block», то вызов успешно пройдёт переадресацию, так-же как и «прямой» вызов (вызывающий ТА УПАТС или DISA).
Но при использовании «in block», возникают очень большие задержки набора номера УПАТС => CISCO (возможно данная ситуация регулируется таймером).

 

Хотелось бы понять, что можно скорректировать со стороны CISCO, для корректной переадресации вызова 2921 -> 0334xxxx, не зависимо от типа набора номера в потоке («overlap» или «in block»).

 

 

 

 

Configuration TDM.txt

Edited March 2, 2019 by SUrov_IBM

[Sergey Taskin]

День добрый

 

Переадресованный вызов через какие dialpeer-ы идет?

можно вывод команды сразу после завершенного переадресованного вызова:

 

sh call hist voi br

 

и для сравнения её же только после нормального вызова

[SUrov_IBM]

13 часов назад, Sergey Taskin сказал:

День добрый

 

Переадресованный вызов через какие dialpeer-ы идет?

можно вывод команды сразу после завершенного переадресованного вызова:

 

sh call hist voi br

 

и для сравнения её же только после нормального вызова

Sergey Taskin, здравствуйте.

Спасибо, что ответили в столь не интересной в данное время теме. :)

Нормальное прохождение вызова номера 2921 (терминируется на CISCO).
Абонент УПАТС номер А 2206 вызывает номер Б 2921 (CISCO):

dial-peer voice 200 pots
 destination-pattern 2921
 translate-outgoing called 200
 clid network-number 81231831xx
 port 0/0:15
!
! Проходит преобразование номера 2921 в для вызова номера ТфОП 33416xx (0 подставляется для выхода в ТфОП).
!
translation-rule 200
 Rule 0 2921 033416xx

========== debug isdn q931 ==========

*Dec 12 06:55:32.713: ISDN Se0/0:15 Q931: RX <- SETUP pd = 8  callref = 0x006F
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA1838A
                Preferred, Channel 10
        Facility i = 0x91AA068001008201008B0100A11402014006042B0C09008009DEE4E8ED20CA2EDE2E
        Calling Party Number i = 0x0980, '2206'
                Plan:Private, Type:Unknown
        Called Party Number i = 0x89, '2921'
                Plan:Private, Type:Unknown
*Dec 12 06:55:32.733: ISDN Se0/0:15 Q931: TX -> SETUP_ACK pd = 8  callref = 0x806F
        Channel ID i = 0xA9838A
                Exclusive, Channel 10
*Dec 12 06:55:42.617: ISDN Se0/0:15 Q931: RX <- INFORMATION pd = 8  callref = 0x006F
        Sending Complete
*Dec 12 06:55:42.645: ISDN Se0/0:15 Q931: Applying typeplan for sw-type 0x16 is 0x0 0x1, Calling num 81231831xx
*Dec 12 06:55:42.653: ISDN Se0/0:15 Q931: Applying typeplan for sw-type 0x16 is 0x0 0x9, Called num 033416xx
*Dec 12 06:55:42.657: ISDN Se0/0:15 Q931: TX -> CALL_PROC pd = 8  callref = 0x806F
*Dec 12 06:55:42.657: ISDN Se0/0:15 Q931: TX -> SETUP pd = 8  callref = 0x00D8
        Sending Complete
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98381
                Exclusive, Channel 1
        Facility i = 0x91AA068001008201008B0100A11402014006042B0C09008009DEE4E8ED20CA2EDE2E
        Calling Party Number i = 0x0183, '81231831xx'
                Plan:ISDN, Type:Unknown
        Called Party Number i = 0x89, '033416xx'
                Plan:Private, Type:Unknown
*Dec 12 06:55:42.713: ISDN Se0/0:15 Q931: RX <- CALL_PROC pd = 8  callref = 0x80D8
        Channel ID i = 0xA98381
                Exclusive, Channel 1
*Dec 12 06:55:43.322: ISDN Se0/0:15 Q931: RX <- ALERTING pd = 8  callref = 0x80D8
        Progress Ind i = 0x8188 - In-band info or appropriate now available
*Dec 12 06:55:43.351: ISDN Se0/0:15 Q931: TX -> ALERTING pd = 8  callref = 0x806F
        Progress Ind i = 0x8188 - In-band info or appropriate now available
*Dec 12 06:55:44.328: ISDN Se0/0:15 Q931: RX <- CONNECT pd = 8  callref = 0x80D8
*Dec 12 06:55:44.336: ISDN Se0/0:15 Q931: TX -> CONNECT_ACK pd = 8  callref = 0x00D8
*Dec 12 06:55:44.352: ISDN Se0/0:15 Q931: TX -> CONNECT pd = 8  callref = 0x806F
*Dec 12 06:55:44.372: ISDN Se0/0:15 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x006F
*Dec 12 06:56:02.674: ISDN Se0/0:15 Q931: RX <- DISCONNECT pd = 8  callref = 0x006F
        Cause i = 0x8190 - Normal call clearing
*Dec 12 06:56:02.682: ISDN Se0/0:15 Q931: TX -> RELEASE pd = 8  callref = 0x806F
*Dec 12 06:56:02.706: ISDN Se0/0:15 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x006F
*Dec 12 06:56:02.730: ISDN Se0/0:15 Q931: TX -> DISCONNECT pd = 8  callref = 0x00D8
        Cause i = 0x8290 - Normal call clearing
*Dec 12 06:56:02.754: ISDN Se0/0:15 Q931: RX <- RELEASE pd = 8  callref = 0x80D8
        Cause i = 0x8190 - Normal call clearing
*Dec 12 06:56:02.766: ISDN Se0/0:15 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x00D8

========== show call history voice brief ==========

Telephony call-legs: 2
SIP call-legs: 0
H323 call-legs: 0
Call agent controlled call-legs: 0
Media call-legs: 0
Total call-legs: 2

1234 : 222 1391916950ms.222 +11600 +29950 pid:100 Answer 81231831xx
 dur 00:00:18 tx:824/138114 rx:339/53126 10  (normal call clearing (16))
 Telephony 0/0:15 (222) [0/0.10] tx:19360/6710/0ms g711ulaw noise:-71dBm acom:39dBm
 long duration call detected:n long dur callduration :n/a timestamp:n/a

1234 : 223 1391926930ms.223 +1620 +20050 pid:200 Originate 033416xx
 dur 00:00:18 tx:339/55838 rx:824/131522 10  (normal call clearing (16))
 Telephony 0/0:15 (223) [0/0.1] tx:19360/16460/0ms g711ulaw noise:-73dBm acom:14dBm
 long duration call detected:n long dur callduration :n/a timestamp:n/a

 

 

 

Если на УПАТС, установлена безусловная переадресация с номера 2201 на номер 2921 и номер УПАТС 2206 вызывает номер 2201, то ситуация выглядит следующим образом:

 

========== debug isdn q931 ==========

*Dec 12 07:22:23.862: ISDN Se0/0:15 Q931: RX <- SETUP pd = 8  callref = 0x0075
        Sending Complete
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA1838A
                Preferred, Channel 10
        Facility i = 0x91AA068001008201008B0100A11402014006042B0C09008009DEE4E8ED20CA2EDE2E
        Calling Party Number i = 0x0980, '2206'
                Plan:Private, Type:Unknown
        Called Party Number i = 0x89, '2921'
                Plan:Private, Type:Unknown
*Dec 12 07:22:23.910: ISDN Se0/0:15 Q931: TX -> CALL_PROC pd = 8  callref = 0x8075
        Channel ID i = 0xA9838A
                Exclusive, Channel 10
*Dec 12 07:22:23.910: ISDN Se0/0:15 Q931: TX -> CONNECT pd = 8  callref = 0x8075
*Dec 12 07:22:23.934: ISDN Se0/0:15 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x0075
*Dec 12 07:22:33.955: ISDN Se0/0:15 Q931: RX <- DISCONNECT pd = 8  callref = 0x0075
        Cause i = 0x8190 - Normal call clearing
*Dec 12 07:22:33.963: ISDN Se0/0:15 Q931: TX -> RELEASE pd = 8  callref = 0x8075
*Dec 12 07:22:33.983: ISDN Se0/0:15 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x0075

========== show call history voice brief ==========

Telephony call-legs: 2
SIP call-legs: 0
H323 call-legs: 0
Call agent controlled call-legs: 0
Media call-legs: 0
Total call-legs: 2

1235 : 224 1393504510ms.224 +-1 +7560 pid:100 Answer 81231831xx
 dur 00:00:00 tx:0/0 rx:0/0 10  (normal call clearing (16))
 Telephony 0/0:15 (224) [0/0.10] tx:0/0/0ms None noise:0dBm acom:0dBm
 long duration call detected:n long dur callduration :n/a timestamp:n/a

1236 : 225 1393528100ms.225 +-1 +10080 pid:100 Answer 81231831xx
 dur 00:00:00 tx:0/0 rx:0/0 10  (normal call clearing (16))
 Telephony 0/0:15 (225) [0/0.10] tx:0/0/0ms None noise:0dBm acom:0dBm
 long duration call detected:n long dur callduration :n/a timestamp:n/a
 

Edited March 4, 2019 by SUrov_IBM

[SUrov_IBM]

На самом деле, создаётся ощущение, что при переадресации вызова в режиме «overlap»,

УПАТС открывает свободный канал (TS) и CISCO ожидает передачи цифр номера

(для этого и генерируется «длинный зуммер» (готовность набора номера)), но УПАТС

либо передаёт цифры слишком рано/поздно, либо не передаёт вообще (возможно,

проблема кроется в таймерах обеих сторон).

 

В режиме «in block», вызовы проходят корректно (возможно, это связано с передачей номера «блоком»

и сигналом завершения набора в сигнализации PRI(?)), но с достаточно большой задержкой!

Из-за чего, это режим в данной схеме хотелось избежать.

 

P.S. Постараюсь запросить трассировку вызова у телефонистов ведомственной АТС в разные моменты

и сравнить с трассировкой CISCO.
 

Но что-то мне подсказывает, что обработка вызова не корректно происходит с моей стороны (CISCO).

Edited March 4, 2019 by SUrov_IBM

[alexgreat]

Наверное, таки en-block. Когда в режиме en-block ставите и в конце набора нажимаете # всё нормально становится?

[SUrov_IBM]

В 05.03.2019 в 19:04, alexgreat сказал:

Наверное, таки en-block. Когда в режиме en-block ставите и в конце набора нажимаете # всё нормально становится?

Alexgreat, здравствуйте.

Использовании символа «завершения набора» (#), в моём случае никак не влияет на вызов УПАТС в сторону CISCO

(режим «in block»), функция (#) – «завершить набор номера» включена на УПАТС.

 

Возможно, sending-complete не передаётся в поток от УПАТС, при нажатии (#).

Edited March 6, 2019 by SUrov_IBM

[SUrov_IBM]

Данную проблему удалось разрешить!

К сожалению, я не профессионал в ISDN телефонии, но пытаюсь разобраться (для меня это увлекательное хобби).

 

При трассировке dial-peer (debug voice dialpeer) было выяснено, что вызываемый номер 2921 указывается  в сигнализации QSIG,

но в отличие от "прямого вызова" остальная информация в сигнализации отсутствует.

Помогла модернизация dial-peer voice 200 pots:

 

dial-peer voice 200 pots
 destination-pattern 2921
 translate-outgoing called 200
 incoming called-number .
 clid network-number 812318xxxx
 direct-inward-dial
 port 0/0:15
 

Добавлены строки – "incoming called-number ." (для прохождения любого номера через dial-peer) и "direct-inward-dial" (последующего направления обратно в поток).

 

Как и предполагалось, проблема крылась в некорректной настройки CISCO (сам виноват).

 

Вызов успешно проходит в режиме «overlap».

 

Трассировка успешного вызова (используется переадресация 2921 на мобильный телефон 921981xxxx):

 

========== debug isdn q931 ==========

*Dec 13 07:37:16.231: ISDN Se0/0:15 Q931: RX <- SETUP pd = 8  callref = 0x007E
        Sending Complete
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA1838A
                Preferred, Channel 10
        Facility i = 0x91AA068001008201008B0100A11D02014006042B0C090080125375726F7620442E20412E20CCD7D120D0D4
        Calling Party Number i = 0x0980, '727'
                Plan:Private, Type:Unknown
        Called Party Number i = 0x89, '2921'
                Plan:Private, Type:Unknown
*Dec 13 07:37:16.287: ISDN Se0/0:15 Q931: Applying typeplan for sw-type 0x16 is 0x0 0x1, Calling num 81231831xx
*Dec 13 07:37:16.295: ISDN Se0/0:15 Q931: Applying typeplan for sw-type 0x16 is 0x0 0x9, Called num 089219818xxxx
*Dec 13 07:37:16.295: ISDN Se0/0:15 Q931: TX -> CALL_PROC pd = 8  callref = 0x807E
        Channel ID i = 0xA9838A
                Exclusive, Channel 10
*Dec 13 07:37:16.299: ISDN Se0/0:15 Q931: TX -> SETUP pd = 8  callref = 0x0103
        Sending Complete
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98381
                Exclusive, Channel 1
        Facility i = 0x91AA068001008201008B0100A11D02014006042B0C090080125375726F7620442E20412E20CCD7D120D0D4
        Calling Party Number i = 0x0183, '81231831xx'
                Plan:ISDN, Type:Unknown
        Called Party Number i = 0x89, '08921981xxxx'
                Plan:Private, Type:Unknown
*Dec 13 07:37:16.359: ISDN Se0/0:15 Q931: RX <- CALL_PROC pd = 8  callref = 0x8103
        Channel ID i = 0xA98381
                Exclusive, Channel 1
*Dec 13 07:37:19.897: ISDN Se0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0x8103
        Progress Ind i = 0x8A88 - In-band info or appropriate now available
*Dec 13 07:37:19.921: ISDN Se0/0:15 Q931: TX -> ALERTING pd = 8  callref = 0x807E
        Progress Ind i = 0x8A88 - In-band info or appropriate now available
*Dec 13 07:37:20.065: ISDN Se0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0x8103
        Progress Ind i = 0x8A88 - In-band info or appropriate now available
*Dec 13 07:37:20.081: ISDN Se0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0x807E
        Progress Ind i = 0x8A88 - In-band info or appropriate now available
*Dec 13 07:37:26.864: ISDN Se0/0:15 Q931: RX <- CONNECT pd = 8  callref = 0x8103
*Dec 13 07:37:26.876: ISDN Se0/0:15 Q931: TX -> CONNECT_ACK pd = 8  callref = 0x0103
*Dec 13 07:37:26.888: ISDN Se0/0:15 Q931: TX -> CONNECT pd = 8  callref = 0x807E
*Dec 13 07:37:26.908: ISDN Se0/0:15 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x007E
*Dec 13 07:37:30.566: ISDN Se0/0:15 Q931: RX <- DISCONNECT pd = 8  callref = 0x8103
        Cause i = 0x8190 - Normal call clearing
*Dec 13 07:37:30.574: ISDN Se0/0:15 Q931: TX -> RELEASE pd = 8  callref = 0x0103
*Dec 13 07:37:30.594: ISDN Se0/0:15 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x8103
*Dec 13 07:37:30.614: ISDN Se0/0:15 Q931: TX -> DISCONNECT pd = 8  callref = 0x807E
        Cause i = 0x8290 - Normal call clearing
*Dec 13 07:37:33.567: ISDN Se0/0:15 Q931: RX <- RELEASE pd = 8  callref = 0x007E
        Cause i = 0x8190 - Normal call clearing
*Dec 13 07:37:33.575: ISDN Se0/0:15 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x807E

 

========== show call history voice brief ==========
Telephony call-legs: 2
SIP call-legs: 0
H323 call-legs: 0
Call agent controlled call-legs: 0
Media call-legs: 0
Total call-legs: 2

1279 : 340 1480820580ms.339 +10510 +14210 pid:200 Originate 08921981xxxx
 dur 00:00:03 tx:417/69658 rx:297/47202 10  (normal call clearing (16))
 Telephony 0/0:15 (340) [0/0.1] tx:10670/5930/0ms g711ulaw noise:-71dBm acom:36dBm
 long duration call detected:n long dur callduration :n/a timestamp:n/a

1279 : 339 1480820470ms.340 +10620 +17320 pid:200 Answer 812318xxxx
 dur 00:00:06 tx:297/49578 rx:417/66322 10  (normal call clearing (16))
 Telephony 0/0:15 (339) [0/0.10] tx:10660/8310/0ms g711ulaw noise:-72dBm acom:45dBm
 long duration call detected:n long dur callduration :n/a timestamp:n/a

 

 

Всем, кто откликнулся или проявил интерес к данной теме – большое Вам Спасибо! :)

Edited March 27, 2019 by SUrov_IBM