- Перенаправление звонков Cisco -> SIP-шлюз,
 mdenisov, 17:33 , 14-Окт-13 (1) +1 Все просто - вы не попадаете во входящий пир 8045000 т. к. 80456701 не попадает в incoming called-number (семерка запрещена перед T). Вызов попадает в пир 80456700 и отбивается т. к. permission term.
- Перенаправление звонков Cisco -> SIP-шлюз, vigogne, 20:05 , 14-Окт-13 (2)
> Все просто - вы не попадаете во входящий пир 8045000 т. к.
> 80456701 не попадает в incoming called-number (семерка запрещена перед T). Вызов
> попадает в пир 80456700 и отбивается т. к. permission term.Так, т.о. term - только для входящих звонков, а orig для исходящих?
Поэтому если изменить в пире 80456700 значение permission на orig или на both то должно заработать? Я правильно это понял? Тогда непонятно, почему проходят звонки именно на этот пир со стороны абонентов Е1?
- Перенаправление звонков Cisco -> SIP-шлюз, mdenisov, 13:39 , 15-Окт-13 (3) +1
> Так, т.о. term - только для входящих звонков, а orig для исходящих? Да, но нет. В смысле наоборот.
> Поэтому если изменить в пире 80456700 значение permission на orig или на
> both то должно заработать? Я правильно это понял? По идее должно, только мне кажется в первом воипном пире 7 как-то не логично закрыто. Зачем это сделано? > Тогда непонятно, почему проходят звонки именно на этот пир со стороны абонентов
> Е1? В вашем случае вызовы с VoIP отбиваются т. к. запрещен входящий пир. При звонках с потока используется входящий pots пир.
- Перенаправление звонков Cisco -> SIP-шлюз, vigogne, 20:07 , 15-Окт-13 (4)
>> Так, т.о. term - только для входящих звонков, а orig для исходящих?
> Да, но нет. В смысле наоборот.Понятно. >> Поэтому если изменить в пире 80456700 значение permission на orig или на
>> both то должно заработать? Я правильно это понял?
> По идее должно, только мне кажется в первом воипном пире 7 как-то
> не логично закрыто. Зачем это сделано? Это сделано, потому что, если выбирается именно этот пир, то звонок проходит, но проходит через ЦАТС. Т.е. практически, звонки проходили через раз, пока я в первом пире не убрал 7.
Я же ставил данный эксперимент ради перенаправления звонка на другой шлюз, не включая в процесс АТС. >> Тогда непонятно, почему проходят звонки именно на этот пир со стороны абонентов
>> Е1?
> В вашем случае вызовы с VoIP отбиваются т. к. запрещен входящий пир.
> При звонках с потока используется входящий pots пир. Да, поменял в пире 80456700 значение permission на both, звонки стали проходить, но пока только сигнализация, когда абонент 6701 берет трубку, связь отбивается, и пока только посредством протокола H323, на SIP почему-то совсем тишина. К сожалению, сегодня весь день был в другом подразделении, и успел только сменить значение а пире и сделать пару звонков... Завтра продолжу. Спасибо Вам огромное, Ваши советы всегда "в кассу"!
- Перенаправление звонков Cisco -> SIP-шлюз, mdenisov, 18:22 , 16-Окт-13 (5) +1
> Это сделано, потому что, если выбирается именно этот пир, то звонок проходит,
> но проходит через ЦАТС. Т.е. практически, звонки проходили через раз, пока
> я в первом пире не убрал 7.
> Я же ставил данный эксперимент ради перенаправления звонка на другой шлюз, не
> включая в процесс АТС.За то как уйдет вызов отвечает исходящий пир, зачем же на входящем ограничивать? > Да, поменял в пире 80456700 значение permission на both, звонки стали проходить,
> но пока только сигнализация, когда абонент 6701 берет трубку, связь отбивается,
> и пока только посредством протокола H323, на SIP почему-то совсем тишина. А вот тут все зависит от конечных устройств. CUBE конечно штука мощная в плане исправления косяков сигнализации, но не всемогущая. Странно что работает H.323 а не SIP, т. к. SIP более стандартизирован.
Кстати, проверьте allow connection в voice service voip.
- Перенаправление звонков Cisco -> SIP-шлюз, vigogne, 07:03 , 17-Окт-13 (6)
>> Это сделано, потому что, если выбирается именно этот пир, то звонок проходит,
>> но проходит через ЦАТС. Т.е. практически, звонки проходили через раз, пока
>> я в первом пире не убрал 7.
>> Я же ставил данный эксперимент ради перенаправления звонка на другой шлюз, не
>> включая в процесс АТС.
> За то как уйдет вызов отвечает исходящий пир, зачем же на входящем
> ограничивать?Так, я видимо совсем запутался...
Если не сложно, укажите пожалуйста, как поправить мои диалпиры, для данной задачи? dial-peer voice 8045 pots
voice cut-through alert
destination-pattern ^8045[0,2,3,5-6,9][^7]T
progress_ind setup enable 3
progress_ind progress enable 8
progress_ind connect enable 8
progress_ind disconnect enable 8
fax rate voice
direct-inward-dial
port 0/0/0:15
supported-language ru
!
dial-peer voice 8045000 voip !Основной входящий
permission orig
huntstop
voice-class codec 1
incoming called-number ^8045..T
!
dial-peer voice 8045200 voip !Пир для пока еще тестового астериска. Работать должен по той же схеме, с передачей звонка. Нумерация 2хх
voice cut-through alert
description POS
huntstop
destination-pattern 80452..
translate-outgoing called 8045
voice-class codec 1
session protocol sipv2
session target ipv4:10.45.5.254
!
dial-peer voice 80456700 voip
description DGW
huntstop
destination-pattern ^804567..
voice-class codec 1
session target ipv4:10.45.129.254
incoming called-number ^804567..
dtmf-relay h245-alphanumeric
fax rate 14400
fax protocol t38 ls-redundancy 5 hs-redundancy 2 fallback pass-through g711alaw
ip qos dscp cs5 media
ip qos dscp cs5 signaling >> Да, поменял в пире 80456700 значение permission на both, звонки стали проходить,
>> но пока только сигнализация, когда абонент 6701 берет трубку, связь отбивается,
>> и пока только посредством протокола H323, на SIP почему-то совсем тишина.
> А вот тут все зависит от конечных устройств. CUBE конечно штука мощная
> в плане исправления косяков сигнализации, но не всемогущая. Странно что работает
> H.323 а не SIP, т. к. SIP более стандартизирован.
> Кстати, проверьте allow connection в voice service voip. Вот моя секция voice service voip
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
redirect ip2ip
fax protocol t38 ls-redundancy 5 hs-redundancy 2 fallback pass-through g711alaw
h323
no call service stop
call start slow
modem passthrough nse codec g711ulaw
sip
bind control source-interface FastEthernet0/0
bind media source-interface FastEthernet0/0
registrar server expires max 3600 min 3600
no call service stop
- Перенаправление звонков Cisco -> SIP-шлюз, vigogne, 11:07 , 23-Окт-13 (7)
Уважаемый Максим Денисов!Понимаю, что наглею, но у меня самого видимо не хватает знаний для этого.
Если не затруднит, не могли бы Вы ответить, как, все-таки, правильно нужно создать эти диалпиры? И правильно ли сделаны настройки в voice service voip?
- Перенаправление звонков Cisco -> SIP-шлюз, mdenisov, 16:04 , 23-Окт-13 (8)
Так у вас же вызовы начали ходить, осталась проблема с односторонним RTP и отсутствием SIP.
Это другая проблема, пиры тут врятли виноваты. Нужно смотреть трейсы, попробуйте поднять SIP как более простой для человеческого понимания и снимите debug ccsip messages для одного проблемного вызова.
- Перенаправление звонков Cisco -> SIP-шлюз, vigogne, 10:01 , 24-Окт-13 (9)
> Так у вас же вызовы начали ходить, осталась проблема с односторонним RTP
> и отсутствием SIP.
> Это другая проблема, пиры тут врятли виноваты. Нужно смотреть трейсы, попробуйте поднять
> SIP как более простой для человеческого понимания и снимите debug ccsip
> messages для одного проблемного вызова.Вот дебаг звонка с астериска по SIP:
Oct 24 11:46:07.712: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:80456701@10.45.15.205 SIP/2.0
Via: SIP/2.0/UDP 10.169.2.222:5060;branch=z9hG4bK7b450b98;rport
Max-Forwards: 70
From: <sip:81691690@10.169.2.222>;tag=as47c1192d
To: <sip:80456701@10.45.15.205>
Contact: <sip:81691690@10.169.2.222:5060>
Call-ID: 19b3352f3ba363557f4f6fde368e18ba@10.169.2.222:5060
CSeq: 102 INVITE
User-Agent: -2.11.0beta2(11.5.1)
Date: Thu, 24 Oct 2013 05:45:18 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 745 v=0
o=root 1129937424 1129937424 IN IP4 10.169.2.222
s=Asterisk PBX 11.5.1
c=IN IP4 10.169.2.222
b=CT:384
t=0 0
m=audio 15516 RTP/AVP 18 4 9 8 0 10 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:10 L16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
m=video 17050 RTP/AVP 34 98 99 31
a=rtpmap:34 H263/90000
a=fmtp:34 F=0;I=0;J=0;T=0;K=0;N=0;BPP=0;HRD=0
a=rtpmap:98 h263-1998/90000
a=fmtp:98 F=0;I=0;J=0;T=0;K=0;N=0;BPP=0;HRD=0
a=rtpmap:99 H264/90000
a=fmtp:99 redundant-pic-cap=0;parameter-add=0;packetization-mode=0;level-asymmetry-allowed=0
a=rtpmap:31 H261/90000
a=sendrecv Oct 24 11:46:07.752: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.169.2.222:5060;branch=z9hG4bK7b450b98;rport
From: <sip:81691690@10.169.2.222>;tag=as47c1192d
To: <sip:80456701@10.45.15.205>
Date: Thu, 24 Oct 2013 05:46:07 GMT
Call-ID: 19b3352f3ba363557f4f6fde368e18ba@10.169.2.222:5060
CSeq: 102 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
Oct 24 11:46:07.756: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:80456701@10.45.129.254:5060 SIP/2.0
Via: SIP/2.0/UDP 10.45.15.205:5060;branch=z9hG4bK34317E1
Remote-Party-ID: <sip:81691690@10.45.15.205>;party=calling;screen=no;privacy=off
From: <sip:81691690@10.45.15.205>;tag=8EE35584-13CB
To: <sip:80456701@10.45.129.254>
Date: Thu, 24 Oct 2013 05:46:07 GMT
Call-ID: 69D5F764-3BA611E3-846CECB2-B4A0A393@10.45.15.205
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1775310219-1000739299-2221337778-3030426515
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1382593567
Contact: <sip:81691690@10.45.15.205:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 574
v=0
o=CiscoSystemsSIP-GW-UserAgent 15 2066 IN IP4 10.45.15.205
s=SIP Call
c=IN IP4 10.45.15.205
t=0 0
m=audio 17950 RTP/AVP 18 4 8 0 100 19
c=IN IP4 10.45.15.205
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000
a=fmtp:4 bitrate=6.3;annexa=no
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:19 CN/8000
m=video 17528 RTP/AVP 34 99
c=IN IP4 10.45.15.205
b=TIAS:85000
a=rtpmap:34 H263/90000
a=fmtp:34 CIF=1;MAXBR=850
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=000000;packetization-mode=0 Oct 24 11:46:07.780: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.45.15.205:5060;branch=z9hG4bK34317E1;received=10.45.15.205
From: <sip:81691690@10.45.15.205>;tag=8EE35584-13CB
To: <sip:80456701@10.45.129.254>
Call-ID: 69D5F764-3BA611E3-846CECB2-B4A0A393@10.45.15.205
CSeq: 101 INVITE
Content-Length: 0
Oct 24 11:46:07.792: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 10.45.15.205:5060;branch=z9hG4bK34317E1;received=10.45.15.205
From: <sip:81691690@10.45.15.205>;tag=8EE35584-13CB
To: <sip:80456701@10.45.129.254>;tag=58f7391a
Call-ID: 69D5F764-3BA611E3-846CECB2-B4A0A393@10.45.15.205
CSeq: 101 INVITE
Contact: <sip:80456701@10.45.129.254:5060>
Content-Type: application/sdp
Content-Length: 152
v=0
o=proton 1382593564 1382593564 IN IP4 10.45.129.254
s=SDP session
c=IN IP4 10.45.129.254
t=0 0
m=audio 7570 RTP/AVP 18
a=rtpmap:18 G729/8000 Oct 24 11:46:07.796: %VOICE_IEC-3-GW: SIP: Internal Error (183, codec mismatch): IEC=1.1.278.7.105.0 on callID 123685 GUID=69D1158B3BA611E38466ECB2B4A0A393
c2811-45-voip#
c2811-45-voip#
c2811-45-voip#
c2811-45-voip#
Oct 24 11:46:07.800: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
CANCEL sip:80456701@10.45.129.254:5060 SIP/2.0
Via: SIP/2.0/UDP 10.45.15.205:5060;branch=z9hG4bK34317E1
From: <sip:81691690@10.45.15.205>;tag=8EE35584-13CB
To: <sip:80456701@10.45.129.254>
Date: Thu, 24 Oct 2013 05:46:07 GMT
Call-ID: 69D5F764-3BA611E3-846CECB2-B4A0A393@10.45.15.205
CSeq: 101 CANCEL
Max-Forwards: 70
Timestamp: 1382593567
Reason: Q.850;cause=65
Content-Length: 0
Oct 24 11:46:07.812: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 408 Request Timeout
Via: SIP/2.0/UDP 10.45.15.205:5060;branch=z9hG4bK34317E1;received=10.45.15.205
From: <sip:81691690@10.45.15.205>;tag=8EE35584-13CB
To: <sip:80456701@10.45.129.254>;tag=58f7391a;tag=30c59eb7
Call-ID: 69D5F764-3BA611E3-846CECB2-B4A0A393@10.45.15.205
CSeq: 101 INVITE
Contact: <sip:80456701@10.45.129.254:5060>
Content-Length: 0
Oct 24 11:46:07.824: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:80456701@10.45.129.254:5060 SIP/2.0
Via: SIP/2.0/UDP 10.45.15.205:5060;branch=z9hG4bK34317E1
From: <sip:81691690@10.45.15.205>;tag=8EE35584-13CB
To: <sip:80456701@10.45.129.254>;tag=58f7391a;tag=30c59eb7
Date: Thu, 24 Oct 2013 05:46:07 GMT
Call-ID: 69D5F764-3BA611E3-846CECB2-B4A0A393@10.45.15.205
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Reason: Q.850;cause=65
Content-Length: 0
Oct 24 11:46:07.824: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 501 Not Implemented
Via: SIP/2.0/UDP 10.169.2.222:5060;branch=z9hG4bK7b450b98;rport
From: <sip:81691690@10.169.2.222>;tag=as47c1192d
To: <sip:80456701@10.45.15.205>;tag=8EE355CC-1586
Date: Thu, 24 Oct 2013 05:46:07 GMT
Call-ID: 19b3352f3ba363557f4f6fde368e18ba@10.169.2.222:5060
CSeq: 102 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Reason: Q.850;cause=65
Content-Length: 0
Oct 24 11:46:07.828: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.45.15.205:5060;branch=z9hG4bK34317E1;received=10.45.15.205
From: <sip:81691690@10.45.15.205>;tag=8EE35584-13CB
To: <sip:80456701@10.45.129.254>
Call-ID: 69D5F764-3BA611E3-846CECB2-B4A0A393@10.45.15.205
CSeq: 101 CANCEL
Content-Length: 0
Oct 24 11:46:07.876: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
c2811-45-voip#ACK sip:80456701@10.45.15.205 SIP/2.0
Via: SIP/2.0/UDP 10.169.2.222:5060;branch=z9hG4bK7b450b98;rport
Max-Forwards: 70
From: <sip:81691690@10.169.2.222>;tag=as47c1192d
To: <sip:80456701@10.45.15.205>;tag=8EE355CC-1586
Contact: <sip:81691690@10.169.2.222:5060>
Call-ID: 19b3352f3ba363557f4f6fde368e18ba@10.169.2.222:5060
CSeq: 102 ACK
User-Agent: -2.11.0beta2(11.5.1)
Content-Length: 0
Oct 24 11:46:09.556: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
OPTIONS sip:10.45.15.205 SIP/2.0
Via: SIP/2.0/UDP 10.169.2.222:5060;branch=z9hG4bK6659352e;rport
Max-Forwards: 70
From: "Unknown" <sip:Unknown@10.169.2.222>;tag=as0644d677
To: <sip:10.45.15.205>
Contact: <sip:Unknown@10.169.2.222:5060>
Call-ID: 0dab5dac266072254980629f521c4fa2@10.169.2.222:5060
CSeq: 102 OPTIONS
User-Agent: -2.11.0beta2(11.5.1)
Date: Thu, 24 Oct 2013 05:45:20 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0
Oct 24 11:46:09.564: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.169.2.222:5060;branch=z9hG4bK6659352e;rport
From: "Unknown" <sip:Unknown@10.169.2.222>;tag=as0644d677
To: <sip:10.45.15.205>;tag=8EE35C94-7D
Date: Thu, 24 Oct 2013 05:46:09 GMT
Call-ID: 0dab5dac266072254980629f521c4fa2@10.169.2.222:5060
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 102 OPTIONS
Supported: 100rel,resource-priority,replaces,sdp-anat
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-ev
c2811-45-voip#ent
Accept: application/sdp
Content-Type: application/sdp
Content-Length: 452
v=0
o=CiscoSystemsSIP-GW-UserAgent 6266 9402 IN IP4 10.45.15.205
s=SIP Call
c=IN IP4 10.45.15.205
t=0 0
m=audio 0 RTP/AVP 18 0 8 9 4 2 15 3
c=IN IP4 10.45.15.205
m=image 0 udptl t38
c=IN IP4 10.45.15.205
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:180
a=T38FaxUdpEC:t38UDPRedundancy Какой-то непонятный набор ошибок. Как я понял, астериск с циской договорились нормально, а вот циска с DGW уже не может ни о чем договориться?
Причем видно, что сама сигнализация прошла и один звонок на телефоне был, абонент же сразу получил отбой.
Вот в истории звонков:
123701 ORG T0 g729r8 VOIP P80456701 0.0.0.0:0 D41
123700 ANS T0 g729r8 VOIP P81691690 10.169.2.222:11738 D41
- Перенаправление звонков Cisco -> SIP-шлюз, vigogne, 11:08 , 24-Окт-13 (10)
Так, кажется начинает вырисовываться картина. При жестком указании кодека G711Alaw в диалпире 80456700 звонки начинают нормально осуществляться. И даже если я создаю voice class codec с кодеками по-порядку g711alaw, g729r8, g723ar53, в общем с теми, которые указаны в DGW, все равно сразу картина меняется на ту, что в дебаге. Самое плохое, что почти в каждом регионе на наше (да и на другие) направления жестко указан g729br8. Как быть с ними, не представляю. Вроде в этом должен помочь транскодинг, но, насколько я понял, он осуществим только на модуле NM-HDV2, у меня же голые PVDM2-32. В некоторых регионах создан voice class codec с набором кодеков, в которых есть и g711alaw, так те нормально дозваниваются (во всяком случае один дозвонился, потом остальные проверим).
- Перенаправление звонков Cisco -> SIP-шлюз, crash, 06:57 , 25-Окт-13 (11)
> Вроде в этом должен помочь транскодинг, но, насколько я понял, он
> осуществим только на модуле NM-HDV2, у меня же голые PVDM2-32.настраивал на простом pvdm, транскодинг работает.
- Перенаправление звонков Cisco -> SIP-шлюз, vigogne, 07:26 , 25-Окт-13 (12)
>> Вроде в этом должен помочь транскодинг, но, насколько я понял, он
>> осуществим только на модуле NM-HDV2, у меня же голые PVDM2-32.
> настраивал на простом pvdm, транскодинг работает.А не могли бы Вы привести пример Ваших настроек транскодинга?
|
Версия для распечатки
Перенаправление звонков Cisco -> SIP-шлюз, 
