Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

In this section:

Panel

Children Display



 

This section describes general tips and other useful information for the

Spacevars
0series4
.

 

Note

Hardware and BMC-related topics do not apply to the SBC SWe platform.

Congratulations on obtaining your 
Spacevars
0series4

platform

! Below is a summary of the steps to follow to get your SBC functional.
  • Create an IP plan. This plan lays out what the IP addresses the 
    Spacevars
    0product
    will use for its management ports, media ports and next hop router. The media ports are used for SIP and RTP traffic. Example IP plans:
    1. SBC 5000/7000 series: Creating an IP Plan
    2. SBC SWe: Creating an IP Plan for SBC SWe on VMware or KVM Hypervisor).
  • Install the Hardware. See Installing SBC 5000 Series Hardware or Installing SBC 7000 Hardware

    .

  • Configure the Field Service Port and Management Port IP address. The Field Service Port (FSP) is an Ethernet port located on the back of the
    Spacevars
    0product
    . This port allows you to access the 
    Spacevars
    0product
    Baseboard Management Controller (BMC) web page. The BMC allows for system monitoring, power control, and configuring the Management Ports of the
    Spacevars
    0product
  • Install SBC Application software. This is accomplished from the EMA. See Installing SBC 5000 and 7000 Series Software.

  • You are now ready to configure your 

    Spacevars
    0product
    platform for processing! See How to Set up a Basic Call Flow.

    Background on SIP Trunking and Access

    The 

    Spacevars
    0product
    basically acts as a SIP B2BUA (Back to Back User Agent). An important concept on the 
    Spacevars
    0product
    is that all signaling and routing is based upon Trunk Groups.

    SIP Trunk Groups are a logical connection between the 

    Spacevars
    0product
    and a far end. A SIP Trunk can be one to one or one to many with the 
    Spacevars
    0product
    always being a single point. A SIP Trunk for end point (phones) access will be one IP address on the 
    Spacevars
    0product
    with the far end consisting of many different end points. A SIP Trunk for a carrier or PBX will generally be a one to one connection.

    Access configurations involve end points (SIP phones, IADs, Soft Clients, etc.) that Register via the 

    Spacevars
    0product
    to their feature server (Class 5, PBX, Hosted PBX, etc.). The 
    Spacevars
    0product
    can cache Registrations in order to reduce the processing time the feature server spends on them. Even in Access configurations, a set of endpoints is represented by a trunk group.

    From an 

    Spacevars
    0product
    viewpoint, all calls (SIP sessions) involve two trunk groups on the
    Spacevars
    0product
    . For example, if Party A wished to connect to Party B via the
    Spacevars
    0product
    , two trunk groups on the 
    Spacevars
    0product
    are involved, one to Party A and one to Party B. There are generally two types of point-to-point SIP Trunks: Interconnect between two carriers and Interconnect between a PBX and a carrier. Interconnection between carriers is static and do not require registrations.

    In the case of interconnection between a carrier and a PBX, the amount of Registrations that can take place vary.

    • In a static trunking environment, no registrations take place. This is similar to two carriers interconnecting.
    • PBX can use Group registration for its endpoints.
    • When a pilot number is Registered, calls are routed (via the feature server) to that pilot number (which would include the extension in the INVITE) on the PBX.
    • Each endpoint can Register

    Both SIP Trunking and Access configurations may be implemented on the same 

    Spacevars
    0product
    server.

    Commonly Used Element Names

    Below is a list of commonly used element names on the 

    Spacevars
    0product
    platforms.

    To see system name and hostname conventions and restrictions, see System Name and Hostname Naming Conventions page.

    Name

    Description

    Examples


    System Name

    • Should be in all CAPS.
    • On a HA system the units are referred to as one name. This name is used in billing,
    • external PSX queries (if done), and system logs.
    • The 1st 3 letters describer the physical location of the system, for example Dallas = DAL
    • The 2nd 3 letters are NBS or SBC to indicate what this machine is.
    • The last two characters are numerical, indicating which number NBS at this particular location

    DALNBS01
    DALSBC01

    Unit #1 of HA name

    The System name with an "a" appended on it

    DALNBS01a

    Unit #2 of HA name

    The System name with an "b" appended on it

    DALNBS01b

    IP Interface Group

    Represent the type of far ends.

    TRUST_IPIG, UNTRUST_IPIG Or
    INTERNAL_IPIG, EXTERNAL_IPIG

    IP Interface

    Include the packet port number and VLAN tag (if used) in the name

    IPIF0
    IPIF1
    IPIF2_200

    Zone

    All CAPS

    Describes the far end.

    INTERNAL, EXTERNAL, CUSTOMER_A

    Trunk Groups

    • All CAPS
    • Can use underscores
    • Describes the far end. Will show up in billing records, so discuss with your downstream billing team

    CORE, PEER, CUSTOMER_A

    Packet Service Profile

    Create a unique one for each customer type. Append "PSP" at the end.

    SIP_PEER_PSP

    Signaling Peer

    Lower case "peer" prefixing the trunk group

    peerCUSTOMER_A

    Routing Label

    • The text "rlTo" prefixing the trunk group.
    • Or prefix "TO_" to the trunk group name.
    • Appears in the billing record

    rlToCUSTOMER_A, TO_CUSTOMER_A

    IP Signaling Profile

    • Describers the signaling flags associated with the customer. Could be re-used among multiple customers
    • Leave the DEFAULT unmodified, create a new ones as needed.
    • Append "_IPSP" to the trunk group name or type of peer.

    CUSTOMER_A_IPSP ALLPEERS_PSP

    Link Detection Groups

    The names should include the IP Interface Group.

    Include an "A" or "B" to indicate the unit.

    UNTRUST_LDG_A, UNTRUST_LDG_B, TRUST_LDG_A, TRUST_LDG_B, MGT_LDG_A,
    MGT_LDG_B