Sopho si ptrunk & extension

SOPHO iS3000 & 2000IPS Conexões em Rede
1. SIP Trunk
1. Introdução
O protocolo usado para sinalização é o SIP (Session Initiation Protocol).
Este tipo de entroncamento usa como plataforma uma rede iP, sendo aplicável a:
- Conexão entre sistemas iS3000;
- Conexão de um sistema iS3000 com um provedor externo baseados no protocolo SIP.
Nota: O protocolo IP usado para interconectar os sistemas SOPHO iS3000 e SOPHO 2000IPS é “CCIS
(Common Channel Inter-office Signalling) over IP”
1. REQUISITOS
- O SOPHO iS3000 deve estar na plataforma de software Call@Net 3.5 / SIP@Net 4.0;
- iS3010, 3030 or 3050 : a CPU3000 deve estar equipada com o módulo acelerador (AM) e uma
placa de memória 32 MB DRAM.
- iS3070 or 3090 : deve ter o firmware CIE versão A100.10.05 (ou superior).
- Placa ISG: aconselhado ser carregada com firmware versão fa2010v1.605 ou superior.
- Para uso de fax é imperativo usar pacote fa2010v1.605 ou superior
SOPHO iS3000 2000IPS
2. CARACTERÍSTICAS
A plataforma Call@Net 3.5 contém as funcionalidades “SIPTrunking” descritas abaixo :
- Tratamento de chamadas básico
- Operação de Registro
- Utilização de Codec (G.729 com 8K de banda, G.711 com 64K de banda)
- “Transport layer”
- Características de tronco: ex: tratamento/assistência para falhas DDR.
- CLI e “name display”
- Dual Tone Multi Frequency (DTMF)
- Quality of Service (QoS) (prioridade para o tráfego de pacotes marcados p/ voz)
- Network Address Translator (NAT) (ex: o cliente tem rede interna (ip 192…) e quer passar para rede
pública (ip 200...); assim deve haver uma conversão (isolando as duas partes)
- Facilidades suportadas pelo iS3000
1
CCIS
SIP
SIP
Provedor Externo SIP
(SIP server)
ex: VCX ou outro
que aceite registro

A plataforma Call@Net 4.1 contém as funcionalidades SIP Trunking descritas abaixo :
- P2P: “Peer-to-Peer RTP” SIP extensions/trunks
- iPVN no iS3000 com SIP trunking
- SIP trunk: direto entre dois sistemas iS3000.
A plataforma Call@Net 4.1E contém as funcionalidades SIP Trunking descritas abaixo :
- Número chamado original
- Evita a Media P2P para SIP, em uma configuração multi-unidade
O SIP@Net manipula o protocolo SIP.
- O SIP driver trata com socket multiplexing/de-multiplexing.
- A placa ISG –In System Gateway, é envolvida para media handling.
3. CONCEITO GERAL
O conceito geral para SIP trunking é descrito abaixo:
SOPHO iS3000
O fluxo de sinalização SIP se dá via SIP driver, geralmente integrado na placa ISG.
A “media”(voz) sempre flui via ISG. A sinalização pode fluir via TCP ou UDP. O tratamento de chamadas
é feito de acordo com a norma RFC 3261.(Request For Comment)
SOLICITAÇÕES & RESPOSTAS
O fluxo de informações no protocolo SIP se dá através de solicitações (request) e respostas;
As solicitações SIP previstas no sistema para serem suportadas são:
ACK é suportado
BYE é suportado
CANCEL é suportado
INVITE é suportado
REGISTER é suportado
OPTIONS somente recepção
Todas as outras mensagens não são relevantes para trunking e portanto, ainda, não são suportadas. As
respostas são também tratadas/geradas em conformidade com RFC 3261.
2
Proxy
SIP
dri
v
er
Rede SIP
ISG
Registrar
Domínio iS3000 Domínio do Provedor SIP

4. REGISTRO
Para que o processo de registro seja executado, devem ser configurados alguns parâmetros no SOPHO
iS; esta configuração é feita através do comando CHSIPA (Change SIP addresses).
O comando CHSIPA relaciona parâmetros com o número de rota relacionado a rota SIP.
- O “inside global IP address” que deve ser aplicado no caso de NAT.
- O iS3000 port number que deve ser aplicado (usualmente porta 5060).
- O Registrar’s URI (ex: registrar.necp.nl).
- O Registrar’s IP address que deve ser aplicado.
- O Registrar’s port number que deve ser aplicado (usualmente porta 5060).
- O Proxy's URI (ex: proxy.necp.nl).
- O Proxy's IP address que deve ser aplicado.
- O Proxy's port number que deve ser aplicado (usualmente porta 5060).
Os dados relativos ao SIP trunk como codec, payload, etc. serão configurados no signalling group,
associado ao hardware (placa virtual) que suporta o tronco SIP; estes parâmetros são atribuídos à
placa pelo comando ASBRDS.
As configurações adicionais relativas a rota SIP são feitas através do comando CHSIPD (Change SIP
data), conforme a seguir.
- O username part da URI: que deve ser aplicado para a operação de registro.
- O default lease time: que é solicitado para registro.
- O username que deve ser aplicado para propósitos de autenticação.
- O password que deve ser aplicado para propósitos de autenticação.
- A comunicação de saída aplicada em UDP ou TCP.
Agora o SIP trunk está apto para execução da operação de registro com o provedor de tronco. Isto
poderá ser ativado através do comando RESIPR.
Durante o processo de registro poderá, opcionalmente, ser solicitada pelo registrar, uma digest
authentication.
Para fins de trace o campo User-Agent na mensagem REGISTER poderá contém o texto; ex:
"Philips Business Communications SOPHO iS3000".
5. CHAMADA SIP DE SAÍDA
Uma chamada SIP trunk pode ser iniciada a partir de qualquer usuário do iS3000, discando para isto
código de acesso a rota, um TAC<EXTERNAL NUMBER>. O TAC é analisado levando ao acesso de uma
destinação (através de um hardware virtual já projetado) no domínio SIP externo.
A chamada é construída em direção ao SIP proxy externo; este SIP proxi é definido através do
comando CHSIPA.
Na direção de saída podem ser indicadas até 4 preferências de codec (0...3). As preferências e
payload são especificadas pelo comando CHIPPD.
Para SIP trunk toda mídia trafega através da placa ISG. O SIP@Net garantirá que a ISG será
envolvida na manipulação da mídia.
O SIP driver é instruído para tratar as mensagens SIP via UDP ou TCP dependendo do que for
especificado na rota SIP.
3

6. CHAMADA SIP DE ENTRADA
Sempre que uma chamada de entrada de tronco for recebida, o iS3000 verificará e aceitará os seguintes
codecs: G.711 uLaw, G.711ALaw, G.729, G.729A and G.729AB.
A prioridade da parte originadora será considerada para a seleção do codec apropriado. O payload
recebido pode ser tomado quando forem 20, 30 e 40mseg; caso contrário, então serão tomados os
valores projetados no signalling group da porta virtual usada.
Observe-se que para chamadas de entrada de tronco serão aceitas uma lista de vários codecs, enquanto
que para uma chamada tronco de saída somente serão disponibilizados codec(s) específicos 1 à 4.
O SIP driver recebe chamadas via UDP ou TCP conforme opção especificada na camada de transporte
para a rota SIP (OM command CHSIPD).
Com a recepção de um INVITE, será feito um teste se a chamada é recebida de uma rota SIP
confiável. Assim, é feita uma verificação se a chamada é recebida de um proxi relacionado a rota SIP;
caso contrário, a chamada será rejeitada conforme RFC 3261.
Mensagens INVITE com codecs não suportados ou layout de mensagens errado, serão rejeitadas
conforme RFC 3261.
Todas as outras mensagens INVITE que não puderem ser roteadas à destinação apropriada serão
oferecidas para DDI fail/assistance, dependendo das DDI-fail options, definidas na rota.
7. CARACTERISTICAS DE TRONCO
Para SIP trunks, são aplicadas placas de troncos virtuais (e circuitos de tronco relacionados).
As características (general/incoming/outgoing route options and bundle options) dos troncos poderão ser
mantidas.
No caso em que um SIP trunk não possa ser acessado, poderá ser definida uma rota de overflow da
mesma forma que para troncos tradicionais, usando as facilidades padrões para roteamento.
iS3000 Opções Gerais de Rota suportadas em SIP ?
P = Data protection applied : Sim
Q = Assistance required : Sim
R = Add-on allowed : Sim
S = Toll-ticketing on route : Sim
T = Impulse post dialling allowed : Não
U = Keytone post dialling allowed : Sim (SKT, não válido G.729)
V = Enquiry on trunk allowed : não aplicável
W = Flexible operator assistance available : não aplicável
X = Time-break check : Sim
Y = Time-break enabled : Sim
Z = CNND translation : Sim
A = Network priority/Force release possible : não aplicável
B = Line park allowed : não aplicável
C = QSIG segmenting allowed : não aplicável
D = Tone types : Sim
iS3000 Opções de Entrada de Rota suportadas em SIP ?
P = DDI-traffic on route : Sim
Q = Break-in protection : Sim
R = Transit allowed : Sim
S = Malicious Call Trace allowed : Não
T = Announcement allowed : Sim
U = Answer before announcement : Sim
V = Calling party control : Sim
W = DDI-delay time required : Não
X = DDI-barred check on inc. calls : Sim
Y = DDI-call waiting required : Sim
4

Z = Socotel shortened protocol : não aplicável
DDI options : Sim
iS3000 Opções de Saída de Rota suportadas em SIP
P = Direct switch through : não aplicável
Q = Break-in protection on outgoing calls : Sim
R = D-button allowed : Não
S = Transit allowed : Sim
T = Source identification : não aplicável
U = Insert or append close sign : Sim
ATF by Camp-On-Busy : Sim
ATF by Automatic Ring Back : Sim
iS3000 Opções de Bundle (feixe) de Rota suportadas em SIP
K = Long line check Sim
L = Exchange line barred check : Sim
M = Register Recall available on bundle : não aplicável
N = Echo canceller connected : não aplicável
O = ISDN date/time synchronisation : não aplicável
P = Metering available on bundle : Não
Q = Detection 1st dial tone applied : não aplicavel
R = Pre dial tone det. time on 1st dial tone applied : não aplicavel
S = Pre dial tone det. time on 2nd dial tone applied : não aplicavel
T = Provisional switch through : não aplicável
U = Answer sensitive : Sim
V = DDO wait for answer : Não
W = Routing tone : Sim
X = TRANSCOM tone det. and alarming : não aplicável
Y = DDO send MFC area number : não aplicável
Z = DDO local ring tone provided : Sim
8. SIP DRIVER
Como o número máximo de “virtual SIP shelves” é limitado a 2, o número máximo de
SIP extensions é 2x512 = 1024.
O SIP driver é capaz de tratar até 1600 ramais. Ele roda na mesma ISG que também é aplicada para
media handling.
Assim, quando estiver rodando na ISG, o SIP driver é capaz de tratar estes 1024 ramais SIP.
Opcionalmente, o SIP driver pode rodar em uma plataforma Windows/PC dedicada.
No arquivo de configuração ISG é possível especificar o endereço IP do PABX e o número de porta
relacionado. Observe que não é possível limitar a quantidade de ramais que usem o SIP driver.
Boundary NEBOUND 418 especifica o número máximo de SIP trunk calls por unidade.
Boundary NEBOUND 426 especifica o número máximo de SIP extension calls por unidade.
O driver não tem conhecimento da quantidade de terminais registrados.
É possivel se ter juntos SIP driver e iTMP driver rodando na mesma ISG.
Para habilitação do SIP driver na ISG, incluir a informação abaixo no arquivo de configuração
(prebisg<mac-address>.txt) :
- [SipPabxIp]
Ip=192.168.1.215 (este é o IP address para CPU/CIE)
Port=2610
O iS3000 gera um Alarm Code /QLF 061/082 e 067/040 no caso de perda da conexão e comunicação
com o SIP driver.
5

REDUNDANCIA
É possível se ter mais que um SIP driver no iS3000. Por exemplo, no caso de mais ISGs instaladas, em
cada ISG, pode estar disponível um SIP driver.
O NEBOUND 417 especifica o número máximo de SIP drivers.
Agora em terminal SIP pode ser registrado em cada SIP driver, considerando que o terminal SIP
suporta a função de se registrar em mais que um SIP driver. Os terminais Polycom possuem esta
funcionalidade.
No arquivo <mac-address>-phone.cfg é possível especificar mais que um servidor de registro.
reg.1.server.1.address="192.168.116.201" reg.1.server.1. etc.
reg.1.server.2.address="192.168.116.101" etc.
9. USO DE CODECs
É possível selecionar codec(s) específicos, para um determinado circuito ou uma placa de tronco virtual,
através do signalling group. Esta seleção de codec se aplica na direção de saída; para a entrada
(chamada SIP de entrada) são suportados os seguintes codecs: G.711 uLaw, G.711 ALaw, G.729A and
G.729AB. a ordem de apresentação do codec na parte SDP da mensagem SIP determina a ordem de
preferência. A RFC3555 contém os codecs possíveis, que podem ser identificados na SDP.
Para o seleção do payload (também associado ao signalling group) será considerado o valor (20, 30 or
40 mseg) idetificado pelo chamador. No caso em que o payload não for especificado ou estiver for a da
faixa suportada pela ISG será considerado o valo default para este circuito.
A seleção de codecs será feita conforme 3264.
Codecs e payload podem ser projetados usando os comando OM CHPCTB/CHIPPD.
10. CAMADA DE TRANSPORTE (Transport Layer)
A camada de transporte é UDP ou TCP.
Ela será selecionada pelo comando CHSIPD. Para media é aplicado RTP e RTPC.
11. DISPLAY DE NOME/ NÚMERO
Para chamadas de saída o nome é adicionado usando a base de dados CNND. Para chamadas de
entrada, no caso de nenhum nome ser encontrado via CNND será considerada a informação de nome da
mensagem SIP (desde que disponível). O comando associado é o CHNAME.
2.9. CLI/COL TRANSLATION
This facility enables users to express with which CLI they wish to be presented to the SIP
network. This facility can be applied to SIP trunk calls. So the system should have at least one
route in which SIP bundles are specified. Users of the CLI translation functionality are
extensions, which do not want their own DNR to be send as CLI to the SIP domain. This could
apply for example in the following situations :
- non-DDI extensions
- All or some extensions send the general access number as CLI
- Group members send their group DNR.
Two types of DNRs can use the facility :
- internal DNRs, extensions in the PBX where the CLI translation facility is executed.
- network DNRs, extensions in a PBX which is connected via DPNSS to the PBX in which
6

the CC translation facility is executed.
External parties, which use the PBX as transit-PBX can not use the facility to translate their
DNR.
The relation between the DNR and its translated CLI is defined by means of OM command
CHCCTR. This relation is added to a table, the CC translation table. This table contains a list
of DNRs, which are to be translated before their identity is presented to the SIP domain. The
translation is only executed on SIP-routes, which have a link to a CC translation table. This
relation is made using OM command CHRTCG.
If an internal or network DNR should not be translated anymore, then it should be removed
from the CC translation table, using OM command CHCCTR. If no CC translation should be
done anymore for a specified route, then the relation between that route and a CC translation
table should be removed (CHRTCG).
• CLI Presentation Restriction (CLIR)
An extension could have the CLI presentation restriction specified : FCM 46 or system
option NESYSOP 074 (Unconditionally CLIR). This means that its identity is not sent to
the SIP domain.
• Assistance Calls
It is not usual to send the individual operator DNR to the opposite (assisted) party. With
this functionality it is possible to send another CLI, for example the general access number.
2.10. DTMF
There are 2 ways to deal with DTMF tones :
1. Injected tones into the speech channel as DTMF tones. This will cause problems in case a
low rate codec is applied (e.g. G.729). At the TDM side of the SIP connection all users have
the ability to generate DTMF tones, either by themselves or with the support of the
iS3000. The ISG will relay the tones towards the SIP trunk. This is the default method.
2. RFC 2833. In case the ISG detects a DTMF tone at the TDM side the ISG will suppress the
passing of the DTMF tone and inject a DTMF tone as an RFC 2833 frame, by reformatting
the speech sample that is received from the DSP. RFC2833 frames are detected at the IP
side and injected as DTMF tones at the TDM side.
Via the offered SDP the CPU detects that the other end has the capability to receive RFC 2833
frames. The CPU passes this information on to the ISG that will take care of the generation
and detection of the DTMF "tones". In the outgoing direction the CPU will pass along the RFC
2833 type to the other end.
2.11. QOS
For details refer to IP-Enabling Customer Engineer Manual. The ISG can either generate
tagged or non-tagged traffic; no distinction in traffic is possible. This implies (but this was also
known for the IP enabling concept) that for the SIP driver IEEE 802.1Q tagging has to be
stripped (in case it is applied for speech and signalling). Due to the fact that dedicated ports
are used for the communication between the iS3000 and the SIP driver this can be done with
an intelligent switch. Notice that in case the SIP driver runs on a PC it depends on the
possibilities of the PC if QOS can be supported, but this is identical to the iTMP driver.
2.12. AUTHENTICATION/SECURITY/ENCRYPTION
Authentication is performed during registration. Upon reception of an incoming call a check
will be done if the call is received from a trusted SIP trunk. See chapter 8. "SIP SECURITY
ASPECTS" for more details.
2.13. NAT
A static NAT solution is implemented, this implies that for each trunk it's related inside global
IP address needs to be projected. In the headers of the SIP messages, in case an inside global
IP address has been specified for signalling, this IP address will be applied, instead of the
iS3000's own IP address (SIP driver IP address). In SDP bodies in SIP messages, in case an inside
global IP address has been specified for media, this IP address will be used, instead of the ISG'sIP
address. The inside global IP addresses are applied in the Via, Contact URI and in the SDP media
information. This method to support NAT is limited to one ISG per SIP trunk.
7

2.14. FDCR
FDCR based on time is supported for SIP trunks. No changes in the MAC manager or the
MA4000 are required.
2.15. DIRECT TRUNK BETWEEN 2 iS3000 SYSTEMS
It is also possible to connect the SIP trunk from one iS3000 to another iS3000 without the use
of a SIP proxy. This allows the possibility to connect 2 iS3000 systems with SIP trunking,
including the registration process.
One iS3000 (A) should activate the SIP route as registrar (server) and the other iS3000 (B)
should activate the SIP route as registerer (client). This is done using OM command RESIPR,
for example :
- in iS3000-A do the following :
Use OM command CHSIPA and specify the IP address of the SIP driver in the opposite
iS3000-B and registrate the iS3000-A as server as follows :
<RESIPR:<SIP route to iS3000-B>,3; SIP route as registrar (server)
- in iS3000-B do the following :
Use OM command CHSIPA and specify the IP address of the SIP driver in the opposite
iS3000-A and registrate the iS3000-B as client as follows :
<RESIPR:<SIP route to iS3000-A>,1; SIP route as registerer (client)
2.16. P2P RTP SIP EXTENSIONS/TRUNKS / iPVN
From SIP@Net 4.2 onwards it is possible to have RTP running via the ISG or to have peerto-peer
RTP in case a call is made between two SIP extensions via iPVN connection using SIP
trunking.
The function of peer-to-peer RTP is only allowed when the function is configured in all the
concerned iPVN-nodes. So the systems must run SIP@Net 4.2 or higher and in all nodes the
function is activated.
iPVN is possible via the SIP trunk. To activate this feature the next projecting aspects are
required:
- Set the P2P option in the route characteristics of the SIP trunk using OM command
CHSIPD.
- Change the answering mode of iPVN user channels in the iPVN route characteristics to
DELAYED PVN (=1) : this is parameter USER-MODE in OM command CHPVNR.
- Do not project the reservation of iPVN user channels after release (default = 0).
For more details, see Appendix C . "PEER-TO-PEER MEDIA".
2.17. iPVN SIP P2P ROUTE OPTIMIZATION
P2P RTP SIP iPVN also supports the iSNet Route optimization protocol as for traditional PVN.
To avoid a possible crossing between the transfer and the route optimization within P2P RTP
SIP iPVN, the optimization process will be started with an extra delay time of 2 seconds after
the Route Optimization timer (NETIMER196) has expired. The iPVN SIP P2P route
optimization can be switched “active” or “non-active” by system option LOSYSOP180 (iPVN
SIP P2P Route Optimization).
Constraint : Unlike the normal PVN route optimization, during the optimization process it may
happen that a silent time is present for about 1 to 3 seconds (depending on the traffic on the
IP network). This silent time is caused by the P2P media negotiation for the route
optimization.
2.18. ORIGINAL CALLED NUMBER
Original Called Number (OCN) on outgoing SIP
Microsoft Exchange is able to offer Voicemail functionality to an external SIP-gateway.
Microsoft Exchange uses a SIP-trunk interface to communicate with an external gateway. The
iS3000 with SIP@Net 4.1 can act as external gateway. By setting an applicable call forwarding
relation to the Microsoft Exchange server, Voicemail functionality can be activated : see figure
below.
8

To support this functionality the diversion header as described in http://ietfreport.isoc.org/allids/
draft-levy-sip-diversion-08.txt is applied. In this diversion header the original called number
and the diversion reason is indicated. Supported diversion reasons are :
"unknown", "user-busy", "no-answer", "unavailable", "unconditional",
"time-of-day", do-not-disturb", "deflection", "follow-me",
"out-of-service", "away".
The original called number is required to maintain a relation with the VoiceMail message.
Offering of the diversion header is licensed with license 70.
No specific configuration is required for this subject. In case the iS3000 receives a 302
response from the Microsoft exchange server a new INVITE message using the contact header
in the 302 response. The 302 response is only accepted if it is within the domain of the original
provider.
Since SIP@Net 4.1H, the Diversion header is only appended if license 70 "Exchange UM
Interface" is active.
Original Called Number (OCN) on incoming SIP
Since SIP@Net 4.2, the diversion header will also be received by the iS3000. This offers the
possibility to use the received diversion info in the diversion header in the iS3000 like already
available for internal diversions. The only known device that sends this diversion header is the
Eicon ISDN card.
For receiving the diversion info in the diversion header, no license 70 is required.
2.19. AVOID P2P MEDIA FOR SIP IN A MULTI-UNIT
CONFIGURATION
By default the iS3000 establishes a P2P connection between two SIP phones, even if the SIP
phones are located in different units of the multi-unit (FIN) network. This is not applicable in
all situations. Therefore a network-wide system option used : NESYSOP 178 : SIP P2P via
multi unit disabled. Setting this option to 'TRUE', will have the result that a SIP calls that crosses
2 units in a FIN will not have P2P media. The media will be routed via the ISG and the multi
unit lines to the other unit. Note that this is a system wide setting and should be set to the
same value in the complete FIN.
2.20. ALTERNATIVE ROUTING ON SIP-TRUNK INTERFACE IN FAIL
SITUATIONS
Up to SIP@Net 4.1 alternative routing on a failing trunk interface is already present with the
LCCR implementation. But this alternative routing is not fast enough in case the SIP trunk does
not respond at all. In the situation that the peer from the SIP trunk does not respond at all, the
problem is that it takes 32 seconds before this is detected and an alternative route is selected
via LCCR. These 32 seconds are according the SIP RFC 3261 and can not be changed.
System timer (NETIMER241 : SIP Trunk Invite Guarding Time) will guard the INVITE. If no
response is received from the trunk before this timer expires, the call is cancelled and an
alternative route is selected according the LCCR function.
9

2. INSTALAÇÃO & PROGRAMAÇÃO
1. CONFIGURAÇÃO
Para utilização em uma plataforma de comunicação IP, o sistema SOPHO iS3000, pode ser configurado
conforme as opções seguintes:
- "IP enabling", (ex: IP trunking)
- “CCIS over IP” (ex: conexão com IPS)
- "Software SMA" (ex: DECT iP)
Em princípio 3 coisas precisam ser configuradas primeiramente:
- projeto de uma shelf SIP virtual
- uma placa de tronco SIP virtual
- uma placa ISG
REQUISITOS DO SISTEMA
Condições básicas para SIP trunking, no SOPHO iS3000:
- Call@Net 3.5 (ou superior).
- CPU3000: com Accelerator Module (AM) e uma 32 MB DRAM (não 32R).
- Firmware CIE: release A100.10.05 (ou superior).
- Firmware ISG: release A201.03.05 (ou superior)
- Licença ISG 59: para liberar canais ISG; (caso contrário só dispõe 10 canais)
Nota: pacotes iS3090 sem AM (F6810…) com AM (F9810…)
Os boundaries relativos a SIP a serem observados são relacionados a seguir :
Valores Recomendados / valores default
10

Depois de alterar os boundaries acima (dentro do PE) reprojetar a central.
2. HARDWARE VIRTUAL
1. Verificar os boundaries:
LOBOUND083 (número máximo de PMs)
NEBOUND372 (número máximo de PMs virtuais: 5 (ex: SIP/DECT/SMA) em uma unidade).
Total de PMs (a soma destes 2 boundaries) em uma unidade : nunca pode exceder 31.
2. Projetar uma PM virtual com as seguintes características:
PM-shelf number 15,
shelf-type 18 (virtual "SIP" shelf)
gabinete 1 (gabinete onde estejam fisicamente localizadas as placas CPU3000/CCS).
ASSHLF:15,18;
Nota: O shelf “type 18” é também usada para suportar SIP extensions; assim, é permitido misturar
placas dos tipos virtual trunk e virtual extension.
11

A quantidade de shelves (compartimentos) dependerá da configuração do sistema:
iS3050:
BOUND154 (system limited number of shelves per cabinet) deve ser setado para 4.
iS3030:
a quantidade de virtual PM-shelves deve ser setada para 3; considerando o LOBOUND 083 setado
para 2,
3. Projetar uma placa PMC na posição 17, com as seguintes características:
board-type 90 (CCS) ou 91 (CPU3000),
signalling group : 0101 (não relevante),
hw-type : 255,
as-pcts : 0.
ASBRDS:15,17,91,0101,255,0;
4. Coloque a PMC em serviço.
SETINS:15,17;
5. Projetar uma placa de tronco virtual SIP com as seguintes características:
board-type : 44,
signalling group : B001,
hw-type : 255,
as-pcts : 1.
Teremos um máximo de 512 portas SIP (16 placas com 32 circuitos cada);
ASBRDS:15,1,44,B001,255,1;
6. Atribuir o “SIP” service, a um serviço client profile; exemplo o default profile 0 (CHPROF).
CHPROF:0,5,1;
0: padrão, sempre existe
Obs: Não coloque os circuitos/placas tronco virtual SIP em serviço, antes de atribuir os dados
específicos SIP á rota SIP.
12

3. Instalação do(s) signalling group(s)
Utilizar o comando CHIPPD para definição do SIP signalling group :
· SIP media access code (caminho de voz),
· codec,
· payload (20 ms.fornece uma qualidade melhor de voz em relação aos outros)
· uso ou não do RFC2833.
Verificar o boundary NEBOUND 420 (número max. de SIP signalling groups).
NEBOUND 420 determina o número de signalling groups que podem ser projetados no sistema;
determina também o maior número de signalling group,; assim, o número resultante de signalling group
B0xx: xx nunca poderá ser superior a (NEBOUND 420 - 1).
Use um signalling group livre dentro do range B000 ... B0FF para SIP trunks ou SIP extensions.
1. Atribuir o código de acesso de mídia correto ao(s) signalling group(s); ex: signalling
group "B001" e o código de acesso de mídia "75".
Este código de acesso de mídia 75 resultará em um caminho de comunicação através da ISG e
portanto deverá ser projetado na árvore de análise relativa ao “DIAL-TYPE 11” : (não é você que
disca e sim a central que o faz).
CHIPPD:B001,0,75;
Onde 0: representa programação de código de acesso a mídia (mídia access code).
2. Atribuir os CODECs utilizados; o caso de ser usado mais que um codec, o primeiro codec será o
codec preferido.
São suportados os seguintes codecs: G.711 uLaw (0), G.711 ALaw (1),G.729A (2) e G.729AB (3).
Assim no exemplo a seguir, G.729A será o codec preferido, em relação a G.729AB, G.711 uLaw e
finalmente G.711 ALaw.
Nota: Estes codecs escolhidos também devem estar definidos também no arquivo prebisg.txt.
CHIPPD:B001,4,2,3,0,1;
Onde 4: representa a lista de preferências de codecs
3. Atribuir o payload : poderá ser 20, 30 ou 40 msec.
CHIPPD:B001,5,30;
Onde 5: representa o payload usado
4. Definir se será ou não usado o RFC2833 (1) or não (0). Assim, (1) na pós-discagem os dígitos DTMF
vão sob forma de mensagens SIP; se for (0) vão via faixa de voz (in-band).
CHIPPD:B001,6,1;
5. apresentação das alterações feitas nos dados do signalling group:
DIIPPD:B001;
13

É possível definir mais signalling groups, por exemplo B002, com diferentes características.
O comando OM CHPCTB poderá ser usado para alterar um signalling group, para um circuito em
particular.
4. Análise Numérica e Rotas
1. Atribuir um Trunk Access Code (exemplo TAC = 6) para acessar um SIP destination (88).
ASINTN:0,6,3,21,88;
Projeto semelhante será feito de maneira nas três árvores relativas às discagens: enquiry dialling,
operator dialling e alternative destination dialling.
2. Definir as características para a destinação 88.
CHDSTC:88,88,00,88;
3. Definir o Esquema de Numeração Externo.
ASEXTN:88,x(0...9),3,4,4,0;
4. Criar uma rota para SIP trunks.
CRROUT:88;
Para esta rota deverão ser atribuídos outros dados SIP Trunk específicos utilizando para isto os
comandos OM CHSIPD e CHSIPA .
5. Introduzir a rota na tabela de rotas.
CHROTA:88;
:88,1,2;
:;
6. Definir as características de rota (gerais, entrada e saída)
CHRTCG:88,11110100111000,440440;
CHRTCI:88,11101100100,000699999,38;
CHRTCO:88,010100,0;
7. Definir o range numérico interno (4xxx) na árvore de análise de entrada (38).
14

ASBLCK:38,4,3,4,10;
8. Definir as características de rota : deve ser usado o parâmetro CON-AND-SIG-TYPE 524.
CHBNDC:88,22,1100000000101001,524;
9. Associar o bundle à rota.
ASBNDL:88,88;
10.Associar as 32 linhas ao bundle.
ASLINE:88,0100,15,1,0;
ASLINE:88,0101,15,1,1;
ASLINE:88,0102,15,1,2;
| | | |
ASLINE:88,0131,15,1,31;
5. Dados Específicos para SIP Trunk
Antes de um tronco SIP ser colocado em serviço, deverão ser primeiramente projetados alguns itens
relacionados SIP. Isto será feito usando os comandos CHSIPD, CHSIPA e RESIPR.
1. Atribuir dados específicos SIP à rota SIP(88).
CHSIPD:88;
ROUTE-NAME : 018904850;
LEASE-TIME : 60; (tempo de re-registro da placa de tronco no servidor SIP)
(significa 60 minutos)
UDP, TCP ou TLS : ;
(quando for omitido é usado UDP (default)
USERNAME : 018904850;
PASSWORD : svdvheho; (o seu provedor SIP é que fornece o username/pass. para se
autenticar)
SIP PROTOCOL VARIANT: 0;
(novo para SIP@Net 4.1)
PEER-TO-PEER RTP : 0;
(novo para SIP@Net 4.1) 0: não (para tronco SIP), 1: sim (para ramal SIP)
2. Atribuir dados relacionados à SIP IP à rota SIP (88).
CHSIPA:88;
INSIDE-GLOBAL-IP-ADDR : 150.83.22.187;
INSIDE-GLOBAL-IP-PORT : 5060;
PROXY-IP-ADDR : 170.35.171.21;
PROXY-IP-PORT : 5060;(ex:1571)
PROXY-NAME : proxy.necp.nl; (ex: vono.net.br)
REGISTRAR-IP-ADDR : 170.35.171.21;
(no caso em que for omitido, será usado o endereço IP do proxi)
REGISTRAR-IP-PORT: 5060;
15

(no caso em que for omitido, será aplicada a porta 5060)
REGISTRAR-NAME : regist.necp.nl;
3. Ativação do registro na rota SIP
RESIPR:88,1;
0: desativar
1: ativar como client (servidor SIP externo)
2: ativar sem registro
3: ativar como server
OBS: Para o caso 1: Quando cai a rede pode acontecer de ser necessário repetir o comando;
Na cofiguração client/server deve-se iniciar primeiramente o server.
4. Apresentação dos itens SIP projetados.
DISIPR:88;
5. Colocação em serviço da PMC virtual e correspondentes placas/circuitos SIP.
SETINS:15,17;
(PMC virtual)
SETINS:15,1;
(placa de tronco virtual SIP)
SETINS:15,1,0&&31;
(circuitos de tronco virtual SIP)
6. Projeto da ISG
ISG – In System Gateway
- A placa ISG deve estar carregada preferencialmente com o firmware: release fa2010v1.605
- A placa CIE (nos sistemas CCS) deve estar carregada com o firmware release fa1001.003 ou
superior.
As funcionalidades: "IP-enabling", "IP-trunking" e “CCIS” podem compartilhar os canais da ISG com SIP,
desde que as licenças ISG estejam presentes.
Além da possibilidade de se ter uma única rota para ISG, é possível também projetar mais rotas e aplicar
separação de feixes (bundle splitting). O Bundle splitting pode ser implementado a fim de deixar uma
quantidade garantida de canais ISG disponíveis para chamadas SIP.
É possível se ter load-sharing quando duas (ou mais) ISGs estiverem presentes no sistema.
1. Projetar a ISG com os parâmetros: board-type is 18, signalling group is 5D21 – QSIG, em uma shelf
PM real com uma PMC with package 410.11.01 / 510.11.01 / 810.02.01 ou superior.
É permitido um máximo de 10 ISGs por sistema iS3000. Note que para shelves PM2500 deverá
se usar o último pacote PPU.
ASBRDS:11,5,18,5D21,255;
2. Criar uma árvore de análise para DIAL-TYPE 11: "media dialling". O TAC a ser usado para código
media access code é analisado na árvore de análise projetada; neste exemplo 11.
16

ASTREE:11,11;
3. Criar o media access code (trunk access code) a destinação (a ISG) na árvore de análise relativa ao
dial type "media dialling" :
Neste exemplo árvore de análise “11” trunk access code '75' e destinação '75'
ASINTN:11,75,2,21,75;
4. Definir as características da destinação.
CHDSTC:75,75,00,75;
5. Criar a rota QSIG..
CRROUT:75;
6. Introduzir a rota no route table.
CHROTA:75;
:75,1,2;
:;
7. Definir as características de rota.
CHRTCG:75,01100100001,543543;
CHRTCI:75,10100000000,000699999,35;
CHRTCO:75,000100,0;
8. Definir as características de feixe.
CHBNDC:75,22,0000000000010001,420;
9. Atribuir o feixe à rota.
ASBNDL:75,75;
10. Atribuir 10, 20 or 30 linhas ao feixe (dependendo da quantidade de licenças ISG).
ASLINE:75,0101,11,5,0,1;
| | | |
ASLINE:75,0115,11,5,0,15;
ASLINE:75,0117,11,5,0,17;
| | | |
ASLINE:75,0131,11,5,0,31;
11. Certifique-se de que esteja presente no TFTP server um arquivo prebisg.txt (ou prebisg<mac-address>.
txt.
Este arquivo contém o nome do pacote de software ISG usado ex: fa2010v1.605
Quando o SIP driver estiver na ISG, certifique-se de que os dados abaixo estejam incluídos no
arquivo prebisg.txt:
[SipPabxIp]
Ip=192.168.1.215 este é o IP address da CPU/CIE !
17

Port=2610
12. Certifique-se de que esteja presente no TFTP server o software package fa2010v1.605.
13. Coloque a placa ISG e o circuito 0 em serviço.
SETINS:11,5; (11, 5 corresponde a posição da ISG fornecida no passo 1)
SETINS:11,5,0;
14. Para verificar as configurações presentes na ISG, utilize um browser com o IP address da ISG; usar o
login, "isgadmin" para o Username e Password.
Tenha em mente que a tela do browser se presta principalmente para fins de teste/check.
Observe-se também que nem todos os dados estão válidos; quando os dados aparecem como
"unknown", significam valores default.
Na tela 'Channel Status Overview', a segunda coluna indica o status dos canais.
Podem ser:
- Free : canal-B não usado.
- Busy IO : canal-B é usado para chamada 'Internal Outgoing' (chamada de/para phone IP).
- Busy TO : canal-B é usado para chamada 'Trunk Outgoing' (chamada entre ISGs).
- Busy TI : canal-B é usado para chamada 'Trunk Incoming' (chamada entre ISGs).
- Busy C : canal-B é usado para chamada 'CCIS'.
- Busy CN : canal-B é usado para chamada 'CCIS', but no RTP channel is assigned.
- Busy EI : canal-B é usado para chamada ‘Incoming’ de um ramal conectado a um IP21.
- Busy EO : canal-B é usado para chamada ‘Outgoing’ de um ramal conectado a um IP21.
- Busy S : canal-B é usado para chamada ‘SIP’.
- Busy SN : canal-B é usado para chamada ‘SIP’, but no RTP channel is assigned.
Observe que para uma chamada CCIS não é possível discriminar entre chamadas de entrada e de
saída.
• ASPECTOS DE SEGURANÇA
A partir do release fa2010v1.501 ISG em diante é possível comutar em OFF a página ISG web
server; para isto deve-se incluir as linhas de texto abaixo no arquivo prebisg.txt:
[WebServer]
WebServerEnabled = 0
Os valores default para webserver estarão em on.
18

7. Processo de operacionalização da ISG
Diferentemente de outras placas do sistema, a placa ISG necessita de um procedimento de
inicialização para que a mesma se torne operacional;
Neste processo ocorrem: o carregamento do pacote (firmware), a adoção de um endereço iP
válido associado ao seu MAC address.
Neste processo a placa ISG deve estar conectada ao SERVER, onde estão armazenadas as
informações a serem carregadas na placa ISG; esta conexão é através de rede ou via cabo cross
conectando-a diretamente ao SERVER [próprio notebook].
Este procedimento é iniciado através dos comandos SETNIN em seguida SETINS na placa, ou
também retirando-a por 30 segundos & inserindo-a novamente no slot da shelf.
Com a inicialização do processo, a ISG envia, através da rede, um broadcast “DHCP discover
+ MAC add”;
O DHCP Server (presente no SERVER), responderá a este broadcast, com um IP address +
MAC address da ISG.
“broadcast”
SOPHO iS3000
O procedimento para o carregamento na placa ISG do: IP address + pacote ISG (fa2010 v1 605)
segue os seguintes passos:
1) Construir uma conexão direta (via cabo cross) entre a ISG e um notebook [neste exemplo IP
address 192.168.1.83], que deverá conter um servidor DHCP [neste exemplo: srv.exe &
srv.ini].
No servidor DHCP deverão ser indicadas as seguintes informações:
• Subnetmask [no exemplo 255.255.255.0]
• ROUTER [no exemplo: 192.168.1.10]
19
Rede IP
“DHCP discover + MAC add”
DHCP
“IP adress” server
ISG
Provedor Externo

• NEXT SERVER [no exemplo: 192.168.1.83]; (iP do notebook)
• Os dados da ISG:
Mac address/ iP proposto/ arquivo de boot
ISG
[O8-00-6F-82-B6-56]
IPADDR= 192.168.1.6
bootfile=prebisg08006f82b756
SOPHO iS3000
“broadcast”
2) Providenciar um Servidor de transporte de arquivo (ex: TFTP Server) apontando para a pasta do
notebook que contenha o arquivo de boot [no exemplo prebisg08006f82b756]; este arquivo
deverá conter, entre outras, as informações sobre: identificação do pacote da ISG [fa2010v1.605] ;
Qos; codecs; Sip Pabx Ip [indicando o iP da CPU/CIE no exemplo: 192.168.1.5] ...)
Todos os dados a serem transferidos para a ISG deverão estar presentes na pasta apontada pelo
servidor TFTP assim como o arquivo referente ao pacote ISG. No exemplo: pacote ISG
[fa2010v1.605]; isg_trunk08006f82b756; prebisg08006f82b756.
20
cabo cross dhcpsrv.
dhcpsrv.
“DHCP discover + MAC add”
“IP adress”+ bootfile
[General]
SUBNETMASK:255.255.255.0
ROUTER: 192.168.1.10
---------------
---------------
NEXT SERVER: 192.168.1.83
[Settings]
---------------
---------------
ISG
[O8-00-6F-82-B6-56]
IPADDR= 192.168.1.6
bootfile=prebisg08006f82b756
192.168.1.83
ISG

SOPHO iS3000
“solicitação” 192.168.1.83 prebisg 08006f82b756
NOTA: Após a carga o parâmetro “replace” deve ser trocado por “reuse”;
Desta forma, ocorrendo um evento que implique na perda do Ip da placa ISG, a mesma envia
para a rede, um broadcast “DHCP discover + MAC add” solicitando um novo iP. Não
encontrando o IP na rede ela utiliza o que já tiver indicado no arquivo de boot, desde que haja
a indicação de “reuse” neste arquivo de boot [prebisg].
21
cabo cross
“TFTP server”
fa2010v1.605
[QOSGlobal]
DSCP=0
UP=255
VID=0
[QOSVoiceData]
DSCP=0
UP=255
[Codecs]
Preferred1=G729AB
Preferred2=G711aLaw
[Control]
DhcpLease=Replace
[PabxIp]
Ip=192.168.1.1
Port=2600
[SipPabxIp]
Ip=192.168.1.5
Port=2610
MaxNrOfExt=50
+
Solicitação do
“boot file+arquivos”
isg_trunk08006f82b756
fa2010v1.605
ISG

2. SIP Extension
1. Introdução
O SIP@Net manipula o protocolo SIP.
O SIP driver trata com socket multiplexing/de-multiplexing.
A placa ISG (In System Gateway), é envolvida para media handling.
1. FUNCIONALIDADES
As funcionalidades SIP Extension disponíveis para o SIP@Net 4.0 são as seguintes:
• Tratamento de chamadas básicas incluindo retenção, consulta e transferência,
• Registro,
• Media P2P (pear-to-pear),
• Facilidades discadas,
• Utilização de codecs,
• Camada de Transporte,
• CLI e name display,
• Dual Tone Multi Frequency (DTMF) para pós-discagem,
• Quality of Service (QoS),
• SIP driver,
• Network Address Translator (NAT),
• CSTA,
As funcionalidades SIP Extension disponíveis para o SIP@Net 4.1 são as seguintes:
22

• Facilidades relativas a chefe-secretária e grupo de busca,
• Monitoração de Estado (ramal e facilidade),
• Captura de chamadas,
• Estacionamento de chamadas,
• Suporte para codec de vídeo SIP,
• Messaging usuário-usuário SIP,
• Redirecionamento/twinning quando circuito em ABL-Fail,
• Conferêcia a Três/ Intercalação/ Escuta usando TDM,
• “Display lease time” para um terminal SIP,
• “Reboot” forçado para terminais Polycom usando OM,
• NAT para ramais com sinalização SIP usando RFC 3581,
• P2P RTP SIP Extensions/Trunks,
• Indicação LED-rota em terminais Polycom.
As funcionalidades SIP Extension disponíveis para o SIP@Net 4.1E são as seguintes:
• Display do No. das partes conectadas para terminais Polycom,
• Suporte para codec de alta definição G722,
• Suporte Intercom e Corrente de Chamada diferenciada para terminais Polycom.
2. Conceito geral
O fluxo de sinalização SIP se dá via SIP driver, geralmente integrado na placa ISG.
A “media”(voz) sempre flui via ISG. A sinalização pode fluir via TCP ou UDP. O tratamento de chamadas
é feito de acordo com a norma RFC 3261.(Request For Comment)
SOPHO iS3000
SOLICITAÇÕES & RESPOSTAS
O fluxo de informações no protocolo SIP se dá através de solicitações (request) e respostas;
As solicitações SIP previstas para ramais no sistema para serem suportadas são:
ACK é suportado
BYE é suportado
23
SIP
dri
v
er
ISG

CANCEL é suportado
INVITE é suportado
REGISTER é suportado
OPTIONS somente recepção
REFER é suportado
NOTIFY somente transmissão
SUBSCRIBE é suportado
MESSAGE é suportado
Todas as outras mensagens não são relevantes para extensions (ramais) e portanto, ainda, não são
suportadas. As respostas são também tratadas/geradas em conformidade com RFC 3261.
3. Telefones IP SIP
Os modelos Polycom SIP IP, homologados pela PHILIPS são:
- Soundpoint IP 320/330
- Soundpoint IP 550
- Soundpoint IP 650
- Soundpoint IP (Módulo de Expansão0
- Soundpoint IP 4000
Além dos modelos anteriores:
- Soundpoint IP 430
- Soundpoint IP 501
- Soundpoint IP 601
As funcionalidades suportadas por estes modelos são:
- Chamada básica
- CLI
- Mensagem em Espera
- tons DTMF
- Dialled facilities
- Transferência, retenção e consulta
- monitoração do estado do ramal
- ativação e desativação de facilidade
Os telefones Polycom SIP IP são totalmente suportados na plataforma iS3000; de igual modo, são
também suportados os SIP IP-DECT e os AudioCodes gateways
4. REGISTRO
Para que a operação de registro possa ser realizada deverão ser feitas algumas configurações
através do comando OM CHSUSR (Change SIP extensions user data). O comando CHSUSR cria
uma relação entre o terminal SIP (por meio de seus username/password) e seu endereço de
hardware virtual EHWA. Como username será aplicado seu número de ramal atribuído.
A autenticação somente poderá ser executada durante o processo de registro. Nesta fase, a
mesma combinação username/password aplicada durante o processo de registro será aplicada
para a autenticação. O tamanho do lease atribuído durante o processo de registro é armazenado
pelo iS3000; caso este lease venha a expirar, o circuito virtual irá para ABL-fail. Será
responsabilidade do terminal garantir que o lease sofra um refresh em intervalos de tempo
regulares.
Os dados relativos a ramais SIP como codec, payload etc. são associados a um signalling group.que por
sua vez é atribuído a uma placa pelo comando ASBRDS. Um circuito específico de uma placa poderá
receber um signalling group diferente (CHPCTB).
24

Nota: Maiores detalhes sobre registro poderão ser obtidos na RFC 3216 seção 10; o mecanismo de
autenticação é implementado de acordo com a RFC 2617 e RFC 3261 seção 22.
5. CHAMADAS SIP ORIGINADAS
Um terminal SIP é capaz de fazer chamadas para todos os outros usuários no ambiente iS3000
(Ergoline@Net, ErgoLines tradicionais, PVN, DPNSS, etc), sendo que o iSS3000 oferece suporte para
geração de tom ou MOH.
Pelas caraterísticas da ISG, até o momento só são suportados os codecs G.711 e G.729.
Devido à aplicação de hardware virtual, um terminal SIP recebe um DNR como se fosse um
terminal tradicional usando o comando OM CHDNRC.
Somente é possível uma chamada por ramal. Alguns terminais SIP possuem a capacidade de ter
mais linhas registradas com um DNR diferente usando para isto mais circuitos virtuais. Desta forma
é possível ter mais que uma chamada ativada ao mesmo tempo.
Nota: Maiores detalhes sobre iniciação de uma chamada SIP poderão ser obtidos na RFC 3261; codecs
usando SDP de acordo com a RFC 2327; procedimento para determinação de codec na RFC 3264.
6. CHAMADAS SIP TERMINADAS
Uma chamada terminada em um terminal SIP contém o username e o DNR da parte originadora (desde que
disponível); dependerá dos recursos do terminal a possibilidade de mostrar para o usuário.
2. INSTALAÇÃO & PROGRAMAÇÃO
1. RAMAIS SIP
1. Projetar primeiramente uma placa de ramal SIP virtual na PM virtual:
board type 39,
signaling group : B0xx, exemplo B001,
hw-type : 255,
as-pcts : 1.
ASBRDS:15,2,39,B001,255,1;
Todos os circuitos da placa serão projetados automaticamente com AS-PCTS “1”. O signalling group
associado a placa é usado para atribuição de um media access code, codec e payload a um circuito.
Poderão ser projetadas até 16 placas com 32 circuitos; teremos então, um total de 512 portas SIP por PM
vitual. Uma segunda shelf virtual poderá ser projetada; observar LOBOUND 091 (max number of
resource relations).
2. Colocar placa e circuitos em serviço:
SETINS:15,2;
SETINS:15,2,0&&31;
25

Embora nenhum ramal SIP ainda esteja registrado, os circuitos ficarão em INS. Isto é feito para permitir a
execução de Call Forwarding Not Reachable, Message Waiting Indication e Twinning em ramais SIP que
ainda não estejam registrados.
3. Opcionalmente, pode ser definido o nome do domínio iS3000 SIP, por exemplo:
CHSIDO:;
DOMAIN-NAME : NECPHilversum;
No caso em que a autenticação for requerida o DOMAIN-NAME será mandatório.
O DOMAIN-NAME é usado no algoritimo de autenticação.
No caso em que nenhuma PASSWORD e ALTERNATIVE USERNAME for usado (passo 6) o DOMAIN-NAME
poderá ser omitido.
4. Verificação do domain name.
DISIDO:;
UNIT DOMAIN-NAME
1 NECPHilversum
5. Associar os DNRs dos ramais SIP aos circuitos virtuais, por exemplo:
CHDNRC:2010,15,2,0;
CHDNRC:2011,15,2,1;
CHDNRC:2020,15,2,2;
CHDNRC:2021,15,2,3;
6. No caso em que a autenticação deva ser executada então, deve-se atribuir os SIP user data. Quando
não for requerida autenticação, este comando CHSUSR poderá ser omitido.
Para o caso de desksharing deverá ser introduzido um ALTERNATIVE USERNAME.
CHSUSR:15,2,2;
PASSWORD:2020;
ALTERNATIVE-USERNAME:;
CHSUSR:15,2,3;
PASSWORD:2021;
ALTERNATIVE-USERNAME:;
7. Verificação dos dados introduzidos pelos passos 5 & 6 usando:
- para SIP@Net 4.0, o comando OM: DISUSR
- para SIP@Net 4.1, o comando OM: DISIED
26

Observe que para os DNRs 2010 e 2011, não houve autenticação. O endereço IP e PORTA somente
serão preenchidos quando a operação de registro tiver sido completada com êxito.
Com o auxílio do browse apontando para o endereço IP do telefone SIP proceda as configurações
necessárias.
EXEMPLO
No exemplo apresentado a seguir é usado um telefone SIP Grandstream.
1. com o browse aponte o endereço IP do telefone SIP IP Grandstream e proceda as configurações. A
“Admin Password” para este telefone é “admin”.
2. Introduzir o endereço IP da ISG no campo “SIP Server” e “Outbound Proxy”. Introduzir, em seguida o
“SIP User ID”, o “Authenticate ID” e “Name”. O campo “Authenticate Password” deve ter o mesmo
conteúdo que o especificado com o comando CHSUSR. Em seguida especificar os codecs.
27

3. Neste exemplo, o User ID corresponde ao número de telefone; assim, selecione “yes”. Para permitir a
utilização do “#” como um prefixo e não como dígito de teclado, selecionar aqui “no”.
2. RAMAIS IP SIP POLYCOM: SOUNDPOINT IPxxx RANGE
6.3. POLYCOM SIP IP PHONES :
NOTES BEFORE YOU START !
1. Incidental some Polycom phones might not become operational when they are connected
to one of the following hubs : 3Com hub type 8C, Linksys EZXS88W and Linksys EF2H24.
The port LED on the hub remains OFF : no ethernet activity.
2. Initially the Polycom SIP phone might be set to FTP. This has to be changed to Trivial FTP
(TFTP). At power-up, select SETUP, Enter Password “456”, OK and scroll down to the
Server Menu. Select Server Type, Edit and change it to Trivial FTP.
28

An alternative is to do the following :
In the DHCP server pass the boot server for TFTP along in option 66 as follows :
tftp://192.168.116.100
So include tftp:// in front of the IP address.
This forces the Polycom terminal to use TFTP in stead of the default FTP.
The Polycom SIP IP phones can be installed in two different ways :
- by browsing to the IP address of each individual SIP phone and specifing the various
settings.
- by using a number of configuration files, available on a TFTP server in the LAN network.
The second option is advised.
Polycom SIP phones require a set of three per-phone configuration files and one common file
to be present on a network TFTP server in order for them to work, after power-up. Template
configuration files (XML-compatible) are available from Polycom. Those Polycom template
configuration files are slightly adapted by NEC-Philips to be able to coop with the iS3000
functionality. So when connecting the Polycom terminals to the iS3000, the NEC-Philips
template configuration files must be used. To be able to discriminate between the Polycom
and NEC-Philips Template Configuration files, the NEC-Philips files have a different file name
as follows :
It is advised to download all relevant Polycom files from the NEC-Philips SoftWare DataBase
(SWDB).
WARNING : Obtain the new version Polycom files from the NEC-Philips SWDB and
use the various NEC-Philips template files :
para cada telephone:
- necp-sip@net.cfg
- necp-sip@net-phone.cfg
- necp-sip@net-directory.xml
Do not obtain the files directly from the Polycom site !!!
The following figure illustrates the necessary directories and files required on a TFPT server.
Note that the PHILIPS bitmap image files are the logo’s which will appear on the display. These
files can be modified to a customer’s logo. There are no bitmap image files available for the
Soundpoint IP 320/330 terminals, because of the size of the display.
29

Figure 6-1 Example of Polycom Configuration files and Directories.
1. Make sure that the following directories are available on the TFTP server in for example
the Polycom directory :
- Contacts
- Current
- Log
2. Make sure that the following files are also in the Polycom directory on the TFTP server :
- necp-sip@net.cfg (the default master configuration file)
- necp-sip@net-directory.xml (the template for a local directory and speed dialing keys)
- necp-sip@net-phone.cfg (per phone configuration file)
- sip.cfg
3. Copy the “necp-sip@net.cfg” file and rename this to <mac address>.cfg for each
terminal, for example 0004f204ed31.cfg.
4. In the <mac address>.cfg preencher dentro do arquivo :
- APPLICATION APP_FILE_PATH="sip.ld"
- CONFIG_FILES="<mac address>-phone.cfg, sip.cfg"
- LOG_FILE_DIRECTORY="log"
- OVERRIDES_DIRECTORY="current"
- CONTACTS_DIRECTORY="contacts"
EXAMPLE
30

5. Copy the “necp-sip@net-phone.cfg” file and rename this to <mac address>-phone.cfg
for each terminal. for example 0004f204ed31-phone.cfg.
6. Este é o mais trabalhoso…
In the <mac address>-phone.cfg fill in the following (see also the example on next page) :
- reg.1.displayName and reg.1.address with the DNR (in the example ”1510”) of the
SIP terminal.
- in case authentication is required also fill in reg.1.auth.userId and reg.1.auth.password
(in the example below are both the DNR ”1510”) .
- reg.1.server.1.address with the IP address of the SIP driver (in the example
”192.168.116.151”).
- reg.1.server.1.port with the port number (in the example ”5060”).
- msg.mwi.1.subscribe=”1510”.
- For each entry in the reg section a line key is defined. For the iS3000 usually one line
key is sufficient. It is allowed to define more line keys but in that case each line
represents a single DNR in the iS3000.
Make sure that the OVERRIDES_DIRECTORY has been specified. If not, the <mac
address>-phone.cfg files will be overwritten with a file type that is not expected. The
terminal will no longer start up.
Exemplo:
7. Copy the “necp-sip@net-directory.xml” file and rename this to <mac-address>-
directory.xml for each terminal. Notice that this file is used to create the speed dial keys
as well as the local directory. In case <sd> is put to 0 the entry is not put under a speed
dialing key.
8. Copy the directory SoundPointIPLocalization with its contents to the TFTP server. Make
sure the latest SIP (sip.ld) and boot package (bootrom.ld) is on the root directory of the
TFTP server. Make sure a file called SoundPointIPWelcome.wav or any other wav file is
available.
9. In the sip.cfg file : Adapt the dial plan. For example 4xxx are internal numbers, 9 is
operator, etc.
Exemplo
31

6.5. POLYCOM SIP TERMINAL CONFIGURATION TOOL
Para a configuração de uma grande quantidade de terminais Polycom, faz automaticamente as
operações de copying and renaming dos arquivos; assim o Polycom SIP terminal Configuration Tool
gera automaticamente os 3 arquivos "MAC address specific".
Esta ferramenta permite que o técnico prepare os arquivos de configuração files para uma série de
terminais, usando uma página Microsoft Excel® como fonte para os dados importados ou
adicionando novas configurações de telefone a partir de um scratch. Para rodar, a ferramenta requer
um path para o conjunto apropriado de arquivos de configuração Polycom template configuration
files (necp-sip@net.cfg, necp-sip@netphone. cfg and necp-sip@net-directory.xml) to be properly set.
Compatibility Notes :
- A ferramenta roda no Microsoft Windows 2000 SP3 or superior.
- .NET Framework v1.1 é requerido no PC (delivered with the installer).
- MDAC v2.6 or superior é requerido para importação de arquivos Excel.
- Só é suportaado o formato Microsoft Excel ’97 (ou superior).
Via File->Import->From XLS command, the tool is able to read Microsoft Excel files and
import phone numbers and their assigned MAC Addresses. The format of the Excel document
needs to comply with the following rules :
- Only the first sheet in the document is imported.
- The first row (the imported columns) needs to be filled in with the names of settings from
the phone template (e.g. reg.1.server.1.address).
- The first two columns contain the MAC ADDRESS and DNR : these two are always
required to be present and valid.
- The next rows (2 and the following) should contain the actual settings. With the exception
of the MAC Address and DNR columns, all other settings are optional for the imported
entries.
Figure 6-2 Example of an .XLS file
32

Instead of using the 3 master template files, one can adapt and edit those 3 files first with the
required customer settings and use the updated files then as the template files.
For example : First include the customers phone directory in the “necp-sip@netdirectory.
xml” file and then copy this file and rename it to <mac-address>-directory.xml.
33

Sopho si ptrunk & extension

Mais conteúdo relacionado

Mais procurados

Semelhante a Sopho si ptrunk & extension

Mais de zeu1507

Sopho si ptrunk & extension