Thursday, 9 August 2012

PRI/E1 Configuration on Cisco Voice Gateway


 Step by step configuration of PRI/E1 on Cisco Voice Gateway
The Primary Rate Interface (PRI) is a standardized telecommunications service level within the Integrated Services Digital Network (ISDN) specification for carrying multiple DS0 voice and data Transmission. E1 is a European Standard and has 32 x 64Kbps channels where 30 is used for voice and two are used for synchronization and signaling

ISDN PRI Switch types:
Below is the list of ISDN PRI switch type support on Cisco voice gateways

 primary-4ess    Lucent 4ESS switch type for the U.S.
 primary-5ess    Lucent 5ESS switch type for the U.S.
 primary-dms100  Northern Telecom DMS-100 switch type for the U.S.
 primary-dpnss   DPNSS switch type for Europe
 primary-net5    NET5 switch type for UK, Europe, Asia and Australia
 primary-ni      National ISDN Switch type for the U.S.
 primary-ni2c    The Cisco NAS-SC switchtype based on NI2C
 primary-qsig    QSIG switch type
 primary-ts014   TS014 switch type for Australia (obsolete)

1. Configuration

Note: once you logged-in in the router you will see card type command required in show running output


Card type e1 0 0
!
network-clock-participate wic 0
network-clock-select 1 E1 0/0/0
!
isdn switch-type primary-net5
 
!
controller E1 0/0/0
 framing no-crc4
 linecode hdb3
 pri-group timeslots 1-31
!
voice-port 0/0:15
 
!
dial-peer voice 1 pots
Incoming called-number.
 direct-inward-dial
port 0/0/0:15
!
2. Verification

Now we have to check the status of PRI using show isdn status command. If you see the layer 2 state as MULTIPLE_FRAME_ESTABLISHED this means that PRI is successfully configured and ready to make/receiveCalls. If it doesn’t show the MULTIPLE_FRAME_ESTABLISHED then follow the troubleshooting section.

VOICE_GW#show isdn status
Global ISDN Switchtype = primary-net5
ISDN Serial0/0/0:15 interface
        dsl 0, interface ISDN Switchtype = primary-net5
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
        5 Active Layer 3 Call(s)
    Activated dsl 0 CCBs = 1
        CCB:callid=7D5, sapi=0, ces=0, B-chan=9, calltype=DATA
        
    The Free Channel Mask:  0xFFFF78FC
ISDN Serial0/0/0:15 interface
        dsl 1, interface ISDN Switchtype = primary-net5
    Layer 1 Status:
        ACTIVE
    Layer 2 Status

3.      Troubleshooting

The show isdn status command displays a summary of all ISDN interfaces. It also displays the status of Layers 1, 2, and 3. Complete the following steps to check the status of the layers:

1.       Verify that Layer 1 is in the ACTIVE state. The status of Layer 1 should always be ACTIVE unless the E1 is down.
If the show isdn status command output indicates that Layer 1 is DEACTIVATED, then there is a problem with the physical connectivity of the E1 line. If the line is administratively down, use the no shutdown command to restart the interface.
2.       Ensure that Layer 2 is in the MULTIPLE_FRAME_ESTABLISHED state. This is the desired state for Layer 2, indicating that Layer 2 frames are being exchanged and Layer 2 initialization has finished.
If Layer 2 is not in the MULTIPLE_FRAME_ESTABLISHED state, use the show controller e1 EXEC command to diagnose the problem.
Since the show isdn status command displays a summary of the current status, it is possible that Layer 2 is bouncing up and down despite indicating a MULTIPLE_FRAME_ESTABLISHED state. Use the debug isdn q921 command to verify that Layer 2 is stable.

Following is an example of show isdn status output:
VOICE_GW#show isdn status
Global ISDN Switchtype = primary-net5
ISDN Serial0/0/0:15 interface
        dsl 0, interface ISDN Switchtype = primary-net5
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
        5 Active Layer 3 Call(s)
    Activated dsl 0 CCBs = 5
        CCB:callid=7D5, sapi=0, ces=0, B-chan=9, calltype=DATA
        CCB:callid=7D6, sapi=0, ces=0, B-chan=10, calltype=DATA
        CCB:callid=7DA, sapi=0, ces=0, B-chan=11, calltype=DATA
        CCB:callid=7DE, sapi=0, ces=0, B-chan=1, calltype=DATA
        CCB:callid=7DF, sapi=0, ces=0, B-chan=2, calltype=DATA
    The Free Channel Mask:  0xFFFF78FC
 
VOICE_GW#show isdn status
 
ISDN Serial0/0/0:15 interface
        dsl 1, interface ISDN Switchtype = primary-net5
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = TEI_ASSIGNED
    Layer 3 Status:
        0 Active Layer 3 Call(s)
    Activated dsl 1 CCBs = 0
    The Free Channel Mask:  0xFFFF7FFF
    Total Allocated ISDN CCBs = 5

Notice that E1 0 (whose D-channel is Serial 0:15) has Layer 1 as ACTIVE and Layer 2 as MULTIPLE_FRAME_ESTABLISHED indicating that the signaling channel is functioning correctly and is exchanging Layer 2 frames with the Telco switch. The D-channel (Serial0/0/0:15) for E1 1 has Layer 1 ACTIVE, but Layer 2 is TEI_ASSIGNED. This indicates that the PRI is not exchanging Layer 2 frames with the switch. Use the show controller e1 x command to troubleshoot.

Using the debug q921 Command
The debug isdn q921 command displays data link layer (Layer 2) access procedures that are occurring at the router on the D-channel.
Note: If debug isdn q921 is turned on and you do not receive any debug outputs, place a call or reset the controller to get debug outputs.
Complete the following steps to ensure that the data link layer access procedures are occurring at the router on the D-channel:
1.       Verify that Layer 2 is stable by looking for messages in the debug output. If the line is bouncing up and down, output similar to the following will appear:

Jul 30 10:06:07.882: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0/0/0:15, TEI 0 changed to down
Jul 30 10:06:09.882: %LINK-3-UPDOWN: Interface Serial0/0/0:15, changed state to down
Jul 30 10:06:21.274: %DSX1-6-CLOCK_CHANGE: Controller 0 clock is now selected as clock source
Jul 30 10:06:21.702: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0/0/0:15, TEI 0 changed to up
Jul 30 10:06:22.494: %CONTROLLER-5-UPDOWN: Controller E1 0, changed state to up
Jul 30 10:06:24.494: %LINK-3-UPDOWN: Interface Serial0/0/0:15, changed state to up
 
2.       Verify that only service access point identifier (SAPI) messages appear on both the transmit (TX) and receive (RX) sides. For example:

Jul 30 10:06:52.505: ISDN Se0/0/0:15: TX -> RRf sapi = 0 tei = 0 nr = 0
   Jul 30 10:06:52.505: ISDN Se0/0/0:15: RX <- RRf sapi = 0 tei = 0 NR = 0
Jul 30 10:07:22.505: ISDN Se0/0/0:15: TX -> RRp sapi = 0 tei = 0 NR = 0
Jul 30 10:07:22.509: ISDN Se0/0/0:15: RX <- RRp sapi = 0 tei = 0 NR = 0
Jul 30 10:07:22.509: ISDN Se0/0/0:15: TX -> RRf sapi = 0 tei = 0 NR = 0
Jul 30 10:07:22.509: ISDN Se0/0/0:15: RX <- RRf sapi = 0 tei = 0 NR = 0

3.       Verify that asynchronous balanced mode extended (SABME) messages do not appear. These messages indicate that Layer 2 is trying to reinitialize. The messages usually appear when poll requests (RRp) are transmitted and there is no response from the switch (RRf), or vice versa. Following are examples of SABME messages:
Jul 30 10:06:21.702: ISDN Se0/0/0:15: RX <- SABMEp sapi = 0 tei = 0
Jul 30 10:06:22.494: ISDN Se0/0/0:15: TX -> SABMEp sapi = 0 tei = 0
If SABME messages appear, complete the following steps:

a.        Use the show running-config command to ensure that isdn switch-type and pri-group timeslots are configured correctly. Contact your Service Provider for the correct values and change the isdn switch-type and timeslots respectively
b.       To change the isdn switch-type and pri-group settings, enter the following commands:
c.  VOICE_GW#configure terminal
d.  VOICE_GW(config)#isdn switch-type XXXXXX
e.  VOICE_GW(config)#controller e1 0
f.  VOICE_GW(config-controlle)#pri-group timeslots X-XX
 
4.       Ensure the D-channel is up using the show interfaces serial number:15 command, where the number is the interface number.
If the D-channel is not up, use the no shutdown command to bring it up. For example:
VOICE_GW(config)#interface serial 0/0/0:15
VOICE_GW(config-if)#no shutdown


Note: Dial plan will be cover in next H.323 gateway configuration blog J
 
Posted by at 4 comments:

Thursday, 2 August 2012

Session Initiation Protocol (SIP)

The Session Initiation Protocol (SIP) is an IETF-defined signaling protocol widely used for controlling communication sessions such as voice and video calls over IP. The protocol can be used for creating, modifying and terminating two-party or multiparty sessions. Sessions may consist of one or several media streams.

The SIP protocol is an Application Layer protocol designed to be independent of the underlying Transport Layer; it can run on TCP, UDP and SCTP. It is a text-based protocol, incorporating many elements of the HTTP and SMTP.

Other SIP applications include video conferencing, streaming multimedia distribution, instant messaging, and presence information and file transfer. The Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE) is the SIP-based suite of standards for instant messaging and presence information. MSRP (Message Session Relay Protocol) allows instant message sessions and file transfer.

Network elements
SIP also defines server network elements. Although two SIP endpoints can communicate without any intervening SIP infrastructure, which is why the protocol is described as peer-to-peer, this approach is often impractical for a public service.

User Agent
A SIP user agent (UA) is a logical network end-point used to create or receive SIP messages and thereby manage a SIP session. A SIP UA can perform the role of a User Agent Client (UAC), which sends SIP requests, and the User Agent Server (UAS), which receives the requests and returns a SIP response.

Proxy server
An intermediary entity that acts as both a server (UAS) and a client (UAC) for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity "closer" to the targeted user. Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it.

Registrar
A server that accepts register requests and places the information it receives in those requests into the location service for the domain it handles which registers one or more IP addresses to a certain SIP URI, indicated by the sip: scheme, although other protocol schemes are possible (such as tel:). More than one user agent can register at the same URI, with the result that all registered user agents will receive a call to the SIP URI.

Redirect server
A user agent server that generates 3xx (Redirection) responses to requests it receives, directing the client to contact an alternate set of URIs. The redirect server allows proxy servers to direct SIP session invitations to external domains.

SIP messages
SIP is a text-based protocol with syntax similar to that of HTTP. There are two different types of SIP messages: requests and responses. The first line of a request has a method, defining the nature of the request, and a Request-URI, indicating where the request should be sent. The first line of a response has a response code.

 List of SIP request methods
  • REGISTER: Used by a UA to indicate its current IP address and the URLs for which it would like to receive calls.
  • INVITE: Used to establish a media session between user agents.
  • ACK: Confirms reliable message exchanges.
  • CANCEL: Terminates a pending request.
  • BYE: Terminates a session between two users in a conference.
·         OPTIONS: Requests information about the capabilities of a caller, without setting up a

List of SIP response codes
  • Provisional (1xx): Request received and being processed. Like 100 for Trying, and 180 for Alerting.
  • Success (2xx): The action was successfully received, understood, and accepted. Like 200 for OK, and 202 for Accepted.
  • Redirection (3xx): Further action needs to be taken (typically by sender) to complete the request. Like 301 for Moved Permanently and 302 for Moved Temporarily
  • Client Error (4xx): The request contains bad syntax or cannot be fulfilled at the server. Like  404 User Not Found and 480 Temporarily Unavailable
  • Server Error (5xx): The server failed to fulfill an apparently valid request. Like 500 for Server Internal Error or 503 for Service Unavailable
  • Global Failure (6xx): The request cannot be fulfilled at any server. Like 603 when the call is declined



 
Class of ResponseStatus CodeExplanation
Informational/provisional 100Trying
180Ringing
181Call Is Being Forwarded
182Queued
183Session Progress
Success 200OK
Redirection 300Multiple Choices
301Moved Permanently
302Moved Temporarily
305Use Proxy
380Alternative Service
Client-error 400Bad Request
401Unauthorized
402Payment Required
403Forbidden
404Not Found
405Method Not Allowed
406Not Acceptable
407Proxy Authentication Required
408Request Timeout
410Gone
413Request Entity Too Large
414Requested URL Too Large
415Unsupported Media Type
416Unsupported URI1 Scheme
420Bad Extension
421Extension Required
423Interval Too Brief
480Temporarily Not Available
481Call Leg or Transaction Does Not Exist
482Loop Detected
483Too Many Hops
484Address Incomplete
485Ambiguous
486Busy Here
487Request Terminated
488Not Acceptable Here
491Request Pending
493Undecipherable
Server-error 500Internal Server Error
501Not Implemented
502Bad Gateway
503Service Unavailable
504Server Timeout
505SIP Version Not Supported
513Message Too Large
Global failure 600Busy Everywhere
603Decline
604Does Not Exist Anywhere
606Not Acceptable



  SIP Trunk configuration on Cisco Voice Gateway
!
voice service voip
 ip address trusted list
  ipv4 0.0.0.0 0.0.0.0
 allow-connections h323 to h323
 allow-connections h323 to sip
 allow-connections sip to h323
 allow-connections sip to sip
 supplementary-service h450.12
 no supplementary-service sip moved-temporarily
 no supplementary-service sip refer
 sip
  registrar server expires max 3600 min 3600
  outbound-proxy ipv4:xxx.xxx.xxx.xxx:5060
--- SIP UA Configuration ---
sip-ua
 keepalive target ipv4:xxx.xxx.xxx.xxx:5060
 authentication username xxxxxxx password 7  xxxxxx
 no remote-party-id
 retry invite 2
 retry register 10
 timers connect 100
 timers keepalive active 10
 sip-server ipv4:4.xxx.xxx.xxx:5060
 host-registrar
!
voice class codec 1
 codec preference 1 g711ulaw
!
--- SIP Trunk Configuration ---
dial-peer voice 100 VoIP
 permission term
 description ** Incoming call from SIP trunk (Level 3) **
 session protocol sipv2
 session target sip-server
 incoming called-number .%
 voice-class codec 1 
 voice-class sip dtmf-relay force rtp-nte
 dtmf-relay rtp-nte
no vad
!
Dial-peer voice 101 VoIP
Description ******outgoing call to SIP trunk******
Destination-pattern 9.T
 Session protocol sipv2
 Session target sip-server
 Voice-class codec 1 
voice-class sip dtmf-relay force rtp-nte
  dtmf-relay rtp-nte
no vad
!

Troubleshooting Tools
If calls cannot be made between SIP gateways or over SIP trunks, dial peer configuration is one of the first places to check. Make sure that the dial peer is configured to use SIP and that both devices are using the same transport protocol and DTMF relay method. Make sure that destination patterns and session targets are correct, also.

The show sip-ua connections {udp|tcp} command gives you information on active connections, including those with errors. To stop a problem connection, use the clear sip-ua {udp | tcp} [connection id number] [target ipv4: ip-address] command.
To ensure that the SIP is enabled on the gateway, use the show sip-ua service command. You should get the following result:

SIP-GW#show sip-ua service
SIP Service is up


Posted by at 2 comments:
Subscribe to: Posts (Atom)