SOPHO iS3000 & 2000IPS Conexões em Rede 
1. SIP Trunk 
1. Introdução 
O protocolo usado para sinalização é o SIP (Session ...
SOPHO iS3000 & 2000IPS Conexões em Rede 
A plataforma Call@Net 4.1 contém as funcionalidades SIP Trunking descritas abaixo...
SOPHO iS3000 & 2000IPS Conexões em Rede 
4. REGISTRO 
Para que o processo de registro seja executado, devem ser configurad...
SOPHO iS3000 & 2000IPS Conexões em Rede 
6. CHAMADA SIP DE ENTRADA 
Sempre que uma chamada de entrada de tronco for recebi...
SOPHO iS3000 & 2000IPS Conexões em Rede 
Z = Socotel shortened protocol : não aplicável 
DDI options : Sim 
iS3000 Opções ...
SOPHO iS3000 & 2000IPS Conexões em Rede 
REDUNDANCIA 
É possível se ter mais que um SIP driver no iS3000. Por exemplo, no ...
SOPHO iS3000 & 2000IPS Conexões em Rede 
the CC translation facility is executed. 
External parties, which use the PBX as ...
SOPHO iS3000 & 2000IPS Conexões em Rede 
2.14. FDCR 
FDCR based on time is supported for SIP trunks. No changes in the MAC...
SOPHO iS3000 & 2000IPS Conexões em Rede 
To support this functionality the diversion header as described in http://ietfrep...
SOPHO iS3000 & 2000IPS Conexões em Rede 
2. INSTALAÇÃO & PROGRAMAÇÃO 
1. CONFIGURAÇÃO 
Para utilização em uma plataforma d...
SOPHO iS3000 & 2000IPS Conexões em Rede 
Depois de alterar os boundaries acima (dentro do PE) reprojetar a central. 
2. HA...
SOPHO iS3000 & 2000IPS Conexões em Rede 
A quantidade de shelves (compartimentos) dependerá da configuração do sistema: 
i...
SOPHO iS3000 & 2000IPS Conexões em Rede 
3. Instalação do(s) signalling group(s) 
Utilizar o comando CHIPPD para definição...
SOPHO iS3000 & 2000IPS Conexões em Rede 
É possível definir mais signalling groups, por exemplo B002, com diferentes carac...
SOPHO iS3000 & 2000IPS Conexões em Rede 
ASBLCK:38,4,3,4,10; 
8. Definir as características de rota : deve ser usado o par...
SOPHO iS3000 & 2000IPS Conexões em Rede 
(no caso em que for omitido, será aplicada a porta 5060) 
REGISTRAR-NAME : regist...
SOPHO iS3000 & 2000IPS Conexões em Rede 
ASTREE:11,11; 
3. Criar o media access code (trunk access code) a destinação (a I...
SOPHO iS3000 & 2000IPS Conexões em Rede 
Port=2610 
12. Certifique-se de que esteja presente no TFTP server o software pac...
SOPHO iS3000 & 2000IPS Conexões em Rede 
7. Processo de operacionalização da ISG 
Diferentemente de outras placas do siste...
SOPHO iS3000 & 2000IPS Conexões em Rede 
• NEXT SERVER [no exemplo: 192.168.1.83]; (iP do notebook) 
• Os dados da ISG: 
M...
SOPHO iS3000 & 2000IPS Conexões em Rede 
SOPHO iS3000 
“solicitação” 192.168.1.83 prebisg 08006f82b756 
NOTA: Após a carga...
SOPHO iS3000 & 2000IPS Conexões em Rede 
2. SIP Extension 
1. Introdução 
O SIP@Net manipula o protocolo SIP. 
O SIP drive...
SOPHO iS3000 & 2000IPS Conexões em Rede 
• Facilidades relativas a chefe-secretária e grupo de busca, 
• Monitoração de Es...
SOPHO iS3000 & 2000IPS Conexões em Rede 
CANCEL é suportado 
INVITE é suportado 
REGISTER é suportado 
OPTIONS somente rec...
SOPHO iS3000 & 2000IPS Conexões em Rede 
Nota: Maiores detalhes sobre registro poderão ser obtidos na RFC 3216 seção 10; o...
SOPHO iS3000 & 2000IPS Conexões em Rede 
Embora nenhum ramal SIP ainda esteja registrado, os circuitos ficarão em INS. Ist...
SOPHO iS3000 & 2000IPS Conexões em Rede 
Observe que para os DNRs 2010 e 2011, não houve autenticação. O endereço IP e POR...
SOPHO iS3000 & 2000IPS Conexões em Rede 
3. Neste exemplo, o User ID corresponde ao número de telefone; assim, selecione “...
SOPHO iS3000 & 2000IPS Conexões em Rede 
An alternative is to do the following : 
In the DHCP server pass the boot server ...
SOPHO iS3000 & 2000IPS Conexões em Rede 
Figure 6-1 Example of Polycom Configuration files and Directories. 
1. Make sure ...
SOPHO iS3000 & 2000IPS Conexões em Rede 
5. Copy the “necp-sip@net-phone.cfg” file and rename this to <mac address>-phone....
SOPHO iS3000 & 2000IPS Conexões em Rede 
6.5. POLYCOM SIP TERMINAL CONFIGURATION TOOL 
Para a configuração de uma grande q...
SOPHO iS3000 & 2000IPS Conexões em Rede 
Instead of using the 3 master template files, one can adapt and edit those 3 file...
Próximos SlideShares
Carregando em…5
×

Sopho si ptrunk & extension

685 visualizações

Publicada em

CENTRAL PHILIPS

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
685
No SlideShare
0
A partir de incorporações
0
Número de incorporações
22
Ações
Compartilhamentos
0
Downloads
11
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Sopho si ptrunk & extension

  1. 1. 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
  2. 2. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  3. 3. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  4. 4. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  5. 5. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  6. 6. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  7. 7. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  8. 8. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  9. 9. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  10. 10. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  11. 11. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  12. 12. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  13. 13. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  14. 14. SOPHO iS3000 & 2000IPS Conexões em Rede É 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
  15. 15. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  16. 16. SOPHO iS3000 & 2000IPS Conexões em Rede (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
  17. 17. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  18. 18. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  19. 19. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  20. 20. SOPHO iS3000 & 2000IPS Conexões em Rede • 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
  21. 21. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  22. 22. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  23. 23. SOPHO iS3000 & 2000IPS Conexões em Rede • 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
  24. 24. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  25. 25. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  26. 26. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  27. 27. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  28. 28. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  29. 29. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  30. 30. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  31. 31. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  32. 32. SOPHO iS3000 & 2000IPS Conexões em Rede 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
  33. 33. SOPHO iS3000 & 2000IPS Conexões em Rede 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

×