[SUrov_IBM]

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

 

Как всегда, не обойтись без Вашего совета.

 

 

Собственно существует следующая схема:

(ТА) <-[Аналоговая линия]-> (АТС) <=[ISDN PRI QSIG]=> (CISCO 2851) <=[VoIP SIP]=> (ТЕЛЕФОННАЯ СЕТЬ)

 

Вызовы в оба направления проходят успешно, за исключением очень досадной проблемы:

Если (ТА) осуществляет вызов в сторону [VoIP SIP] и вызываемый абонент «занят» (486 Busy Here) или «недосягаем» (502 Bad Gateway и подобные «отбойники»), CISCO не генерирует Cause «отбоя» в сторону ISDN PRI QSIG, в результате вместо сигнала «занято» в трубке ТА «тишина», пока ISDN PRI соединение не разъединится по времени.

 

 

Если в качестве VoIP сигнализации используется H.323, то в аналогичной ситуации вызова, Cause «отбоя» передаётся в ISDN PRI и со стороны ТА слышен сигнал «отбой».

 

Задача состоит в том, что бы данная схема работал при использовании SIP сигнализации.

 

 

Данная проблема была замечена, к сожалению, без решения - https://community.cisco.com/t5/telepresence-and-video/sip-isdn-disconnect-problem/td-p/1245732

 

 

Дополнительные эксперименты:

Если вместо ISDN сигнализации использовать CAS, то при получении «отбоя» по сигнализации SIP, CISCO генерирует зуммер «занято» в голосовой канал (собственным DSP(?)), потом разрывает соединение, сигнал «занято» продолжает генерировать уже АТС.

 

Если вместо ISDN сигнализации использовать CAS, то при получении «отбоя» по сигнализации H.323, CISCO разрывает соединение, сигнал «занято» генерирует сама АТС.

 

 

Возможно, кто-то сталкивался с подобной ситуацией, при использовании CISCO. Заранее благодарю за Ваши ответы!

 

P.S. Всем хорошего настроения!

 

=====> Набираем номер абонента:

*Feb 28 04:24:35.226: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8  callref = 0x0032
        Bearer Capability i = 0x9090A3
                Standard = CCITT
                Transfer Capability = 3.1kHz Audio
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA1838F
                Preferred, Channel 15
        Calling Party Number i = 0x0980, '35701'
                Plan:Private, Type:Unknown
        Called Party Number i = 0x89, '16'
                Plan:Private, Type:Unknown
*Feb 28 04:24:35.230: ISDN Se0/0/0:15 Q931: TX -> SETUP_ACK pd = 8  callref = 0x8032
        Channel ID i = 0xA9838F
                Exclusive, Channel 15
*Feb 28 04:24:35.386: ISDN Se0/0/0:15 Q931: RX <- INFORMATION pd = 8  callref = 0x0032
        Called Party Number i = 0x89, '5'
                Plan:Private, Type:Unknown
*Feb 28 04:24:35.562: ISDN Se0/0/0:15 Q931: RX <- INFORMATION pd = 8  callref = 0x0032
        Called Party Number i = 0x89, '0'
                Plan:Private, Type:Unknown
*Feb 28 04:24:35.730: ISDN Se0/0/0:15 Q931: RX <- INFORMATION pd = 8  callref = 0x0032
        Called Party Number i = 0x89, '5'
                Plan:Private, Type:Unknown

*Feb 28 04:24:35.738: //5147/B2635FDE85AA/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:16505@10.1.6.8:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.51.1:5060;branch=z9hG4bKCA11BDB
Remote-Party-ID: <sip:35701@192.168.51.1>;party=calling;screen=no;privacy=off
From: <sip:35701@192.168.51.1>;tag=924CA560-A51
To: <sip:16505@10.1.6.8>
Date: Sun, 28 Feb 2021 04:24:35 GMT
Call-ID: B2B17E93-78B311EB-AD6DC900-8672016E@192.168.51.1
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2992857054-2025001451-2242510873-0102959888
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1614486275
Contact: <sip:35701@192.168.51.1:5060>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 247

v=0
o=CiscoSystemsSIP-GW-UserAgent 9817 9553 IN IP4 192.168.51.1
s=SIP Call
c=IN IP4 192.168.51.1
t=0 0
m=audio 16992 RTP/AVP 8 101
c=IN IP4 192.168.51.1
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

*Feb 28 04:24:35.742: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8  callref = 0x8032
*Feb 28 04:24:35.754: //5147/B2635FDE85AA/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.51.1:5060;branch=z9hG4bKCA11BDB;received=192.168.51.1
Call-ID: B2B17E93-78B311EB-AD6DC900-8672016E@192.168.51.1
From: <sip:35701@192.168.51.1>;tag=924CA560-A51
To: <sip:16505@10.1.6.8>
CSeq: 101 INVITE
Timestamp: 1614486275
Content-Length: 0

*Feb 28 04:24:35.786: //5147/B2635FDE85AA/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 486 Busy Here
Via: SIP/2.0/UDP 192.168.51.1:5060;branch=z9hG4bKCA11BDB;received=192.168.51.1
Call-ID: B2B17E93-78B311EB-AD6DC900-8672016E@192.168.51.1
From: <sip:35701@192.168.51.1>;tag=924CA560-A51
To: <sip:16505@10.1.6.8>;tag=2071970834
CSeq: 101 INVITE
Allow: INVITE,ACK,CANCEL,BYE,PRACK,INFO,UPDATE,OPTIONS,REGISTER,NOTIFY
Server: Panasonic-MPR12-V006.01089/VSIPGW-V3.0000
Content-Length: 0

*Feb 28 04:24:35.790: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:

ACK sip:16505@10.1.6.8:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.51.1:5060;branch=z9hG4bKCA11BDB
From: <sip:35701@192.168.51.1>;tag=924CA560-A51
To: <sip:16505@10.1.6.8>;tag=2071970834
Date: Sun, 28 Feb 2021 04:24:35 GMT
Call-ID: B2B17E93-78B311EB-AD6DC900-8672016E@192.168.51.1
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0

=====> Послушав «тишину» и не получив «отбой», кладём трубку на телефонный аппарат.

*Feb 28 04:24:53.174: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8  callref = 0x0032
        Cause i = 0x8190 - Normal call clearing
*Feb 28 04:24:53.174: ISDN Se0/0/0:15 Q931: TX -> RELEASE pd = 8  callref = 0x8032
*Feb 28 04:24:53.194: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x0032
 

Изменено 2 марта, 2021 пользователем SUrov_IBM
Решение проблемы найдено, тема закрыта.

[SUrov_IBM]

В 28.02.2021 в 14:49, SUrov_IBM сказал:

Дополнительные эксперименты:

Если вместо ISDN сигнализации использовать CAS, то при получении «отбоя» по сигнализации SIP, CISCO генерирует зуммер «занято» в голосовой канал (собственным DSP(?)), потом разрывает соединение, сигнал «занято» продолжает генерировать уже АТС.

 

Если вместо ISDN сигнализации использовать CAS, то при получении «отбоя» по сигнализации H.323, CISCO разрывает соединение, сигнал «занято» генерирует сама АТС.

Просто «мысли в слух» - возможно в ситуации, когда по SIP поступает «486 Busy Here» или подобный код, CISCO не пересылает Cause «отбой» по  сигнализации ISDN, а пытается генерировать акустический сигнал «отбой» в  голосовой канал (B),  который в данный момент вызова не «открыт», как следствие в трубке «тишина».

 

Вот почему голосовой канал (B) не «открыт», это уже другая история. Попробую разобраться в ближайшее время, при доступе к АТС.

P.S. Уметь бы ещё понять что-то на АТС без помощи телефонистов, будучи документоведом, а не телефонистом…, но это тоже, уже другая история.  

[SUrov_IBM]

Получилось разобраться:

Если вызов совершается со стороны АТС (сторона [А]) при использовании сигнализации ISDN, а в ответ со стороны VoIP сети с сигнализацией SIP  (сторона [Б]) поступает cause "486 Busy Here", CISCO преобразует его в ISDN cause "17 User busy" (что логично), при этом АТС игнорирует данный cause, ожидая завершения вызова по тайм-аут.

 

Экспериментально выяснилось, что АТС генерирует акустический сигнал «отбой» при получении ISDN cause "16 Normal call clearing".

 

Поскольку доступа до АТС у меня нет, да и пользоваться ей я не умею, пришлось скорректировать настройки CISCO в виде «костыля» средствами sip-ua map sip-pstn:

!

sip-ua

! "486 Busy Here" -> "16 Normal call clearing"

 set sip-status 486 pstn-cause 16

! "502 Bad Gateway" -> "16 Normal call clearing"

 set sip-status 502 pstn-cause 16

 

Важное дополнение, для прохождения транзитных вызовов SIP to SIP через маршрутизатор, необходимо обратное преобразование - set pstn-cause 16 sip-status 486.

Без него транзитный вызов, получивший SIP 486 (Busy Here) «споткнётся» и выдаст SIP 500 (Internal Server Error), что тоже будет являться причиной «отбоя», но будет очень некорректным для некоторых схем.

Изменено 8 мая, 2021 пользователем SUrov_IBM

[SUrov_IBM]

23 часа назад, SUrov_IBM сказал:

Просто «мысли в слух» - возможно в ситуации, когда по SIP поступает «486 Busy Here» или подобный код, CISCO не пересылает Cause «отбой» по  сигнализации ISDN, а пытается генерировать акустический сигнал «отбой» в  голосовой канал (B),  который в данный момент вызова не «открыт», как следствие в трубке «тишина».

Отвечаю сам себе, для заметки, а возможно и кому-то будет интересным:

 

При использовании сигнализации ISDN, в отличие от сигнализации CAS, CISCO передаёт «отбой» по D-channel средствами cause code, без использования B-channel.

 

23 часа назад, SUrov_IBM сказал:

Если вместо ISDN сигнализации использовать CAS, то при получении «отбоя» по сигнализации H.323, CISCO разрывает соединение, сигнал «занято» генерирует сама АТС.

При использовании сигнализации CAS (в моём случае используется T1, простая сигнализация CAS без E&M) и получении SIP "502 Bad Gateway", CISCO не продолжительное время генерирует «отбой» в акустическом канале в виде зуммера «короткие гудки», после чего разрывает соединение. При получении SIP "486 Busy Here", мгновенно разрывает соединение.

 

Вероятнее всего, это связана с тем, что в США «короткие гудки» символизируют не готовность оборудования к набору номера или аварию во время соединения, а корректное завершение вызова слышно по короткому щелчку переполюсовки (в аналоговой линии) и последующей «тишиной».

 

У меня АТС - дама европейская, «короткие гудки» сгенерирует в любом случае, при разрыве соединения ("486 Busy Here"»), самостоятельно и сразу, а в случае "502 Bad Gateway", даст послушать CISCO ("Хьюстон, у нас проблемы" («короткие гудки» от CISCO)), а потом уже собственные «короткие гудки», после разрыва соединения.

 

В 28.02.2021 в 14:49, SUrov_IBM сказал:

Если в качестве VoIP сигнализации используется H.323, то в аналогичной ситуации вызова, Cause «отбоя» передаётся в ISDN PRI и со стороны ТА слышен сигнал «отбой».

При использовании в схеме H.323 сигнализации со стороны VoIP, на CISCO всегда прилетал cause code "16 Normal call clearing" от вышестоящего оборудования, и не важно, «занято» там или «Хьюстон, у нас проблемы», после чего cause успешно транслировался в ISDN попадал на АТС, а она в свою очередь всегда генерировала известные «короткие гудки», чем и сбивала с толку в понимании проблемы.

 

 

Поскольку будучи «канцелярской крысой», а не телефонистом и не умеючи настраивать АТС, а телефонистов в нашем офисе к сожалению нет, проблему понял не сразу. Возможно, мой опус кому-то поможет, хотя сейчас и ISDN сетей то наверное уже не осталось. =)

Изменено 2 марта, 2021 пользователем SUrov_IBM