Cisco Unified Border Element Configuration Guide Through Cisco IOS XE 17.5
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
- Overview of Cisco Unified Border Element
- Virtual CUBE
- Dial-Peer Matching
- DTMF Relay
- Introduction to Codecs
- Basic SIP Configuration
- Matching Inbound Dial Peers by URI
- Multiple Pattern Support on a Voice Dial Peer
- Outbound Dial-Peer Group as an Inbound Dial-Peer Destination
- ENUM Enhancement per Kaplan Draft RFC
- Support for Multi-VRF
- Configuring Multi-Tenants on SIP Trunks
- Codec Support and Restrictions
- Codec Preference Lists
- Video Suppression
- Network-Based Recording
- SIPREC (SIP Recording)
- Third-Party GUID Capture for Correlation Between Calls and SIP-based Recording
- Cisco Unified Communications Gateway Services—Extended Media Forking
- Passing Headers Unsupported by CUBE
- Copying SIP Headers
- Delayed-Offer to Early-Offer
- H.323-to-H.323 Interworking on CUBE
- ICE-Lite Support on CUBE
- Mid-call Signaling Consumption
- Early Dialog UPDATE Block
- Consumption of Forked 18x Responses with SDP During Early Dialog
- Support for Pass-Through of Unsupported Content Types in SIP INFO Messages
- Support for PAID PPID Privacy PCPID and PAURI Headers on the Cisco Unified Border Element
- Dynamic Refer Handling
- SIP TLS Support on CUBE
- CUBE Call Quality Statistics Enhancement
- Voice Quality Monitoring
Book Title
Cisco Unified Border Element Configuration Guide Through Cisco IOS XE 17.5
Configurable SIP Parameters via DHCP
View with Adobe Reader on a variety of devices
Results
Chapter: Configurable SIP Parameters via DHCP
Configurable SIP Parameters via DHCP
The Configurable SIP Parameters via DHCP feature allows a Dynamic Host Configuration Protocol (DHCP) server to provide Session Initiation Protocol (SIP) parameters via a DHCP client. These parameters are used for user registration and call routing.
The DHCP server returns the SIP Parameters via DHCP options 120 and 125. These options are used to specify the SIP user registration and call routing information. The SIP parameters returned are the SIP server address via Option 120, and vendor-specific information such as the pilot, contract or primary number, an additional range of secondary numbers, and the SIP domain name via Option 125.
In the event of changes to the SIP parameter values, this feature also allows a DHCP message called DHCPFORCERENEW to reset or apply a new set of values.
The SIP parameters provisioned by DHCP are stored, so that on reboot they can be reused.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to https://cfnng.cisco.com/. An account on Cisco.com is not required.
Prerequisites for Configurable SIP Parameters via DHCP
A DHCP interface has to be associated with SIP before configurable SIP parameters via DHCP can be enabled.
Cisco Unified Border Element
Cisco IOS Release 12.4(22)YB or a later release must be installed and running on your Cisco Unified Border Element.
Cisco Unified Border Element (Enterprise)
Cisco IOS XE Release 3.17S or a later release must be installed and running on your Cisco ASR 1000 Series Router.
Restrictions for Configurable SIP Parameters via DHCP
DHCP Option 120 is the standard DHCP option (RFC3361) to get a SIP server address, and this can be used by any vendor DHCP server. Only one address is supported, which is in the IPv4 address format. Multiple IPv4 address entries are not supported. Also, there is no support for a DNS name in this or for any port number given behind the IPv4 address.
DHCP Option 125 (RFC 3925) provides vendor-specific information and its interpretation is associated with the enterprise identity. The primary and secondary phone numbers and domain are obtained using Option 125, which is vendor-specific. As long as other customers use the same format as in the Next Generation Network (NGN) DHCP specification, they can use this feature.
A primary or contract number is required in suboption 202 of DHCP Option 125. There can be only one instance of the primary number and not multiple instances.
Multiple secondary or numbers in suboption 203 of DHCP Option 125 are supported. Up to five numbers are accepted and the rest ignored. Also, they have to follow the contract number in the DHCP packet data.
Authentication is not supported for REGISTER and INVITE messages sent from a Cisco Unified Border Element that uses DHCP provisioning
The DHCP provisioning of SIP Parameters is supported only over one DHCP interface.
The DHCP option is available only to be configured for the primary registrar. It will not be available for a secondary registrar.
Information About Configurable SIP Parameters via DHCP
To perform basic Configurable SIP Parameters via DHCP configuration tasks, you should understand the following concepts:
Cisco Unified Border Element Support for Configurable SIP Parameters via DHCP
The Cisco Unified Border Element provides the support for the DHCP provisioning of the SIP parameters.
The NGN is modeled using SIP as a VoIP protocol. In order to connect to NGN, the User to Network Interface (UNI) specification is used. Cisco TelePresence Systems (CTS), consisting of an IP Phone, a codec, and Cisco Unified Communications Manager, are required to internetwork over the NGN for point-to-point and point-to-multipoint video calls. Because Cisco Unified Communications Manager does not provide a UNI interface, there has to be an entity to provide the UNI interface. The Cisco Unified Border Element provides the UNI interface and has several advantages such as demarcation, delayed offer to early offer, and registration.
The figure below shows the Cisco Unified Border Element providing the UNI interface for the NGN.
Figure 1. Cisco NGN with Cisco Unified Border Element providing UNI interface 
DHCP to Provision SIP Server, Domain Name, and Phone Number
NGN requires Cisco Unified Border Element to support DHCP (RFC 2131 and RFC 2132) to provision the following:
IP address for Cisco Unified Border Element’s UNI interface facing NGN
SIP server address using option 120
- Pilot number (also called primary or contract number), there is only one pilot number in DHCPACK, and REGISTER is done only for the pilot number
- Additional numbers, or secondary numbers, are in DHCPACK; there is no REGISTER for additional numbers
- SIP domain name
DHCPFORCERENEW to reset or apply a new set of SIP parameters (RFC 3203)
DHCP-SIP Call Flow
The following scenario shows the DHCP messages involved in provisioning information such as the IP address for UNI interface, and SIP parameters including the SIP server address, phone number, and domain name, along with how SIP messages use the provisioned information.
The figure below shows the DHCP and SIP messages involved in obtaining the SIP parameters and using them for REGISTER and INVITE.
Figure 2. DHCP-SIP Call Flow 
DHCP Message Details
The DHCP call flow involved in obtaining Cisco Unified Border Element provision information, including the IP address for UNI interface and SIP information such as phone number, domain, and SIP server, is shown in the figure below.
Figure 3. DHCP Message Details 
The DHCP messages involved in provisioning the SIP parameters are described in Steps 1 to 6.
F1: The Cisco Unified Border Element DHCP client sends a DHCPDISCOVER message to find the available NGN DHCP servers on the network and obtain a valid IPv4 address. The Cisco Unified Border Element DHCP client identity (computer name) and MAC address are included in this message.
F2: The Cisco Unified Border Element DHCP client receives a DHCPOFFER message from each available NGN DHCP server. The DHCPOFFER message includes the offered DHCP server’s IPv4 address, the DHCP client’s MAC address, and other configuration parameters.
F3: The Cisco Unified Border Element DHCP client selects an NGN DHCP server and its IPv4 address configuration from the DHCPOFFER messages it receives, and sends a DHCPREQUEST message requesting its usage. Note that this is where Cisco Unified Border Element requests SIP server information via DHCP Option 120 and vendor- identifying information via DHCP Option 125.
F4: The chosen NGN DHCP server assigns its IPv4 address configuration to the Cisco Unified Border Element DHCP client by sending a DHCPACK message to it. The Cisco Unified Border Element DHCP client receives the DHCPACK message. This is where the SIP server address, phone number and domain name information are received via DHCP options 120 and 125. The Cisco Unified Border Element will use the information for registering the phone number and routing INVITE messages to the given SIP server.
F5: When NGN has a change of information or additional information (such as changing SIP server address from 1.1.1.1 to 2.2.2.2) for assigning to Cisco Unified Border Element, the DHCP server initiates DHCPFORCERENEW to the Cisco Unified Border Element. If the authentication is successful, the Cisco Unified Border Element DHCP client accepts the DHCPFORCERENEW and moves to the next stage of sending DHCPREQUEST. Otherwise DHCPFORCERENEW is ignored and the current information is retained and used.
F6 and F7: In response to DHCPFORCERENEW, similar to steps F3 and F4, the Cisco Unified Border Element requests DHCP Options 120 and 125. Upon getting the response, SIP will apply these parameters if they are different by sending an UN-REGISTER message for the previous phone number and a REGISTER message for the new number. Similarly, a new domain and SIP server address will be used. If the returned information is the same as the current set, it is ignored and hence registration and call routing remains the same.
How to Configure SIP Parameters via DHCP
Configuring the DHCP Client
To receive the SIP configuration parameters the Cisco Unified Border Element has to act as a DHCP client. This is because in the NGN network, a DHCP server pushes the configuration to a DHCP client. Thus the Cisco Unified Border Element must be configured as a DHCP client.
Perform this task to configure the DHCP client.
Before you begin
You must configure the ip dhcp client commands before entering the ip address dhcp command on an interface to ensure that the DHCPDISCOVER messages that are generated contain the correct option values. The ip dhcp client commands are checked only when an IP address is acquired from DHCP. If any of the ip dhcp client commands are entered after an IP address has been acquired from DHCP, the DHCPDISCOVER messages’ correct options will not be present or take effect until the next time the router acquires an IP address from DHCP. This means that the new configuration will only take effect after either the ip address dhcp command or the release dhcp and renew dhcp EXEC commands have been configured.
5 DHCP Service Design
This chapter provides information related to DHCP service design as applicable to Oracle Communications Internet Name and Address. DHCP is an extension of the Bootstrap Protocol (BootP). You can use DHCP to assign IP addresses and host names automatically and to distribute IP configuration information.
Each client on your network requires its own IP address and configuration information. The client’s IP address is the identifier that other network machines use to recognize that client. The computer’s configuration information includes, among other items, the network domain name, the address of network servers and gateways, and the subnet mask.
Without DHCP or BootP, each time your organization adds a device to its network, the system administrator must go to the new device and manually assign the IP address and configuration information. When devices change offices or users, or leave the network altogether, the configuration information changes as well.
DHCP makes network management easier by automating and centralizing IP address administration and by providing this information automatically to each network device when it is needed.
This chapter provides specific information regarding the implementation of DHCP in Oracle Communications Internet Name and Address Management.
Basic Operation
This section explains the basic operation of the DHCP service design.
Lease Information
When provisioning a network using dynamic addressing, each time a client connects onto the network, the client is assigned an IP address that can be used for a predetermined period of time known as lease time. The IP address and lease is assigned from the dynamic range of IP addresses for which the DHCP server is responsible.
Lease time is the length of time that a computer can use a dynamic IP address. You define the lease time when you provision a dynamic range from the Internet Name and Address Management interface. The default lease time is seven days.
When a client has an address with a lease time, it contacts the DHCP server and attempts to renew the lease half-way through the lease time. This is called the renewal time . In most cases, the DHCP server renews the client’s address and the lease time for that address. For example, if your computer has an address with a lease time of eight days, it asks to renew the address approximately four days after it has started to use it. When the DHCP server renews the address, your computer is able to use the address for another eight days. This process continues until the client is no longer connected to the network.
Occasionally the client does not receive an answer to its renewal request which it sent to the DHCP server (perhaps because the server is down at the renewal time). At the rebind time (by default 87.5% through the lease time), the client attempts to communicate with any other DHCP server and requests the same IP address. If the client’s attempt to rebind is unsuccessful, when the client’s lease expires, the client sends out a broadcast and attempt to communicate with any DHCP server, requesting a new IP address.
DHCP Options
DHCP options are additional configuration elements that can be selected, to allow more information to be exchanged from the DHCP server to the client. Internet Name and Address Management is pre-configured with a list of supported DHCP options. Internet Name and Address Management automatically generates all lease-related options (when autonaming is applied to a dynamic range).
When options are applied on a dynamic range, they are sent to the DHCP server through the DHCP PIC. The DHCP server then sends out the options to clients requesting addresses on that range. Different DHCP option sets may be assigned to different ranges. You can associate multiple DHCP options to a range.
Typically, all networks enable the Router and Name Server DHCP options.
For information on DHCP Option classes option (option 77) refer to the section «DHCP Option Classes and Client Pools».
Internet Name and Address Management DHCP Server (Solaris)
This section explains DHCP service design for a Solaris DHCP server.
Server Deployment and Configuration
This section explains server and deployment considerations for a Solaris DHCP server.
Redundancy
DHCP redundancy is a process that allows you to have more than one DHCP server be responsible for a range or ranges of IP addresses. Redundancy ensures that when a DHCP server fails, clients on your network continue to receive IP addresses.
Internet Name and Address Management offers DHCP redundancy through a server-to-server protocol with a primary and a backup server. A primary DHCP server is a DHCP server that is configured with a set of ranges and serves addresses in those ranges to DHCP clients. A backup DHCP server is a DHCP server that communicates with a primary DHCP server and serves the ranges of the primary server when the backup server can no longer communicate with the primary server.
Users can assign one backup server to each primary DHCP server on the network. Any primary server can have only one backup server, but a server can be a backup for any number of primary servers. Any server that does not have a backup server assigned to it is operating without DHCP redundancy.
If any of the primary DHCP servers for which the backup server is acting have not contacted the backup server within a certain time, the backup server considers the primary to be offline and begins to serve the address ranges for the primary server that has failed. The backup server continues to serve the address ranges until it receives a message from the primary server that the primary has resumed operation.
When the primary server resumes operation, it contacts the backup server. The backup server sends changed lease information to the primary server for which it has been acting. Leases will have changed if the backup DHCP server has allocated a new lease, or released or renewed an existing lease. The backup server returns to a non-serving mode, waiting for and responding to keepalive messages from the primary server.
Virtual DCHP
Internet Name and Address Management supports multiple «virtual» DHCP servers deployed on a single hardware platform, with each instance dedicated to a unique logical interface.
A virtual DHCP server listens to unicast IP packets received on a specific IP address and port. Broadcast IP packets received on the physical network interfaces and unicast IP packets received on any other IP address are ignored. Therefore, multiple virtual DHCP servers may be deployed on the same hardware platform with one or more physical network interfaces, as long as each server is assigned a specific IP address.
Refer to Internet Name and Address Management Installation and Administration Guide for complete information on the installation and provisioning of virtual DHCP servers.
DHCP Processes
Internet Name and Address Management DHCP processes include the operation of the DHCP server which assigns IP addresses and leases to clients in a dynamically provisioned network, as well as the operation of the DHCP PIC which transfers configuration information from the Directory to the DHCP server.
Typically, DHCP processes are configured during installation of Internet Name and Address Management. However, if certain provisioning parameters are modified after installation, the files that support the DHCP processes may have to be manually reconfigured.
The DHCP server runs from a script called inamdhcp . The DHCP PIC runs from a script called inamdhcppic .
The DHCP server gets its start up and configuration information from inamdhcp.properties which is typically located in <OCINAM_HOME>/etc . This directory also contains a soft link to the inamdhcppic.properties file.
After the DHCP server begins operating, it caches configuration information locally in a file called dhcpcfg.cur which is located in the <OCINAM_HOME>/data/dhcppic directory. The dhcpcfg.cur file contains configuration and lease information. It is an auto-generated file and should not be edited. A backup of your dhcpcfg.cur file should be performed at least once a day.
The inamdhcp.properties can be modified if server configuration information needs to be modified after installation. For example, if a server’s default customer needs to be changed, this cannot be done from the GUI. The change needs to be made in the inamdhcp.properties file. If this file is edited, the DHCP server has to be restarted. Table 5-1 shows the inamdhcp.properties file attributes.
Table 5-1 Example inamdhcp.properties file
DHCP server IP as datafilled in Internet Name and Address Management.
Timeout (seconds) for the server discovery pings.
0 is no Dynamic DNS (DDNS), 1 is start up with DDNS enabled. Usually, DHCP server DDNS configuration is controlled from the GUI.
Full path of the directory where the DHCP server stores any generated files or other configuration files, except log files. This file should not be edited.
IP address which the DHCP PIC is running on.
Port that the DHCP PIC is listening on.
The DHCP PIC queries the Directory. It waits for the DHCP server to connect to it, and then pushes information and configuration changes to the DHCP server. The DHCP PIC runs on the same machine as the DHCP server, but can point to a Directory on another machine.
The DHCP PIC configuration is controlled by inamdhcppic.properties , which is found in <OCINAM_HOME>/java/dhcppic and is usually soft-linked from <OCINAM_HOME>/etc . The PIC jar file and DHCP PIC logger.properties file are also located in the <OCINAM_HOME>/java/dhcppic directory. If the inamdhcppic.properties file or the logger.properties file are edited, the DHCP PIC needs to be restarted.
This inamdhcppic.properties file and also the inamdhcppic.properties file in the /java/dhcppic folder contain some common properties. Refer to «Connection Recovery Properties» to see examples of common properties.
Table 5-2 lists the unique properties in the inamdhcppic.properties file:
Table 5-2 Example inamdhcppic.properties file
DHCP server name as datafilled in Internet Name and Address Management.
Full path of the directory where the DHCP server stores any generated files or other configuration files, except log files. This file should not be edited.
Port that the DHCP PIC is listening on.
Advanced DHCP Configurations
This section explains advanced DHCP configurations.
DHCP Option Classes and Client Pools
User and vendor class comparators are used in combination with Client Pools to accept or reject incoming DHCP requests for specific dynamic ranges.
DHCP Option Classes
Option classes refer to DHCP options that can mark incoming DHCPDISCOVER packets.
User and vendor Class comparators are set using the DHCP Option Classes browser. Option classes consist of a name, type (User or Vendor), match condition, and match pattern.
Match conditions are:
exact : the DHCP option exactly matches the match pattern.
contains : the DHCP option contains the match pattern anywhere.
starts with : the DHCP option begins with the match pattern.
ends with : the DHCP option ends with the match pattern.
The match pattern is a string, used in case sensitive string compares.
This information is pushed down to the DHCP server, and used with dynamic ranges and associated Client Pools to accept or reject incoming client requests for an IP address.
For example, a user class could be a grouping of common network clients such as members of a particular department of a company. Sales and engineering could be set up as a separate DHCP user classes.
Client Pools are groups of option classes and MAC Address support classes. Client Pools can contain multiple user and vendor classes and also MAC Address support classes. Both user, and vendor and MAC Address support class types can be mixed in a Client Pool.
A Client Pool is utilized when associated with a dynamic range. Client Pools enable a dynamic range to serve or not serve an IP address based on a client’s DHCPDISCOVER packet. The Client Pools associated with a dynamic range are made up of allowed and denied Client Pools.
If a dynamic range receives a DHCPDISCOVER packet that meets the criteria contained in an associated allowed Client Pool, that dynamic range serves out an IP address to that client. If a dynamic range receives a DHCPDISCOVER packet that meets the criteria contained in an associated denied Client Pool, the dynamic range does not release an IP address to the client.
If a DHCPDISCOVER packet includes a user class or vendor class option, the DHCP server first looks at all dynamic ranges for a Client Pool with an entry that matches the provided user or vendor class. If a denied client pool matches, the server skips that range and moves to the next. If an allowed Client Pool matches, the server offers a lease from that range, if there is an IP address available. If a lease is not found with this search, the DHCP server checks ranges with no Client Pools.
If a client request does not include a user class or vendor class option, the DHCP server skips any ranges with allowed client pool entries.
Denied Client Pools take precedence over allowed Client Pools. If a client request matches both an allowed Client Pool and a denied client pool on the same dynamic range, the client does not get a lease offer from that range.
When a DHCP server serves an IP address from a dynamic range it can be made to issue the IP address only if the MAC address of the requester is specified. In this case, the DHCP server can hand out addresses from a pool of addresses in a dynamic range only to hosts that have the MAC ID listed (they are the hosts with NIC cards loaded in the network).
Support for P-CSCF Address Discovery
With Internet Name and Address Management, a feature to add support for DHCP Option 120 (SIP server) and 121 classless Static Route option has been implemented. It defines a Dynamic Host Configuration Protocol (DHCP-for-IPv4) option that contains a list of domain names or IPv4 addresses that can be mapped to one or more Session Initiation Protocol (SIP) outbound proxy servers.
The 120 option shall contain the P-CSCF identity as a 32-bit (binary) IPv4 address or, preferably, a DNS name to be used by the SIP client to locate a SIP server.
The 121 option, is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless — each routing table entry includes a subnet mask. This option can contain one or more static routes, each of which consists of a destination descriptor and the IP address of the router that should be used to reach that destination.
Adding DHCP Option 120 results in the following configuration added to the Internet Name and Address Management Solaris DHCP Server in the dhcpcfg.cur file, which is the configuration file for the Solaris-based DHCP Server:
Where 78 is 120, 09 is length of bytes, and IP addresses 1.1.1.1 and 2.2.2.2 respectively.
Autonaming
In a dynamic range, the Internet Name and Address Management Autonaming feature enables a client to receive an automatically generated domain name.
In addition to receiving an IP address and lease, the DHCP server also assigns a domain name to a client if the autonaming feature has been enabled. The domain name assigned to a client consists of the autonaming prefix and domain component, which are set when configuring the dynamic range. As well, the MAC address of the client is appended to the domain name that is auto-generated for the client. Table 5-3 lists autonaming examples.
Chris Lehr’s Microsoft blog
Active Directory, Exchange, Windows, Lync, Skype for Business and Office 365 how-to’s and tips and tricks as we pick them up. Feel free to pass on anything you see here, and PLEASE subscribe to our RSS feed, and leave comments if you find our posts helpful!
Wednesday, July 08, 2015
SIP DHCP Option 120 DeMystified
On the surface, Option 120 seems simple — it’s the Pool FQDN, encrypted.
Everyone knows to run the DHCPUtil.exe -sipserver server.domain.com and it spits out a long hex value for you. Option 43 is a little fancier, and gets more press. Option 120 seems straightforward in comparison. What if I asked you to create the hex code without DHCPutil? Sure sounds easy, you take that FQDN, run off to your local hex to asc convertor and punch in your FQDN, you get a non-human readable string, and you set your DHCP options. Done and done — What do you mean it’s not working?
So, reading through RFC3361 (as I am known to do in front of the fireplace, pouring over dot-matrix printed copies, burning the parts I have already committed to memory) we learn that Option 120 has a VERY particular format.
That format can be seen below — where «##» is the hex code for the length of the ASCII section following it.
00 + ## + HEXCODEHOSTNAME + ## + HEXCODEDOMAINNAME + ## + HEXCODETLDNAME + 00
That’s confusing, but for a machine with limited CPU/RAM, that’s a pretty sweet input.
So, let’s un-Lync this for a minute and pretend our SIP server was www.bing.com Keep in mind, the 00-FF range is 0-255 characters in each section of the FQDN. I don’t know a TLD above 10 characters, but I guess they really wrote this code openly!
| Section | Characters | Hex Code |
|---|---|---|
| www | 3 | 03 |
| bing | 4 | 04 |
| com | 3 | 03 |
I’ll avoid the haiku here but the encoding for this would look like:
00 03 HEXCODE(www) 04 HEXCODE(bing) 03 HEXCODE(com) 00
Or this (bolded the Hex count codes)
| 00037777770462696E6703636F6D00 |
Armed with information, I began working in Excel to make it so I could build these codes without having RDP to a Lync or S4B server available to me, or from a place where I might not have DHCPUtil.exe access.
Taking an input in Excel using the FQDN, you need to do some fair complicated text manipulation to break down the sections, perform the ASC to Hex conversions and concatenate the text. I am pleased to report that in my search for this code already existing, I was able to find this Design Document Generator written by Alessio Giombini.
I have taken the tab and modified it some to release it separately to you here.
Download from the TechNet Gallery!
My Teams Lab
Microsoft Teams and Skype for Business learnings from the lab and field.
Sunday, November 29, 2015
Skype4B / Lync DHCP Config Tool
DHCP Vendor Class Options — Option 43
DHCP Option 120
How Does DHCP Option 120 interact with DNS?
- _sipinternal._tls SRV record
- _sip._tls SRV record
- sipinternal.<user domain> (Be careful of this record. This is not included in the certificate SAN list by default so don’t enter it into DNS unless you have added it specifically to the SAN list)
- sip.<user domain> (This record is included by default in the certificate SAN list. So it’s safe to use.)
Configuring the DHCP Server
Skype4B / Lync DHCP Config Tool
- Deploy Server and Scope level settings within your Windows DHCP server.
- The tool will encode the settings as required to be deployed within the server.
- The tool will download and display the current settings from the DHCP server.
- Edit and remove individual settings as required.
- Export to Cisco IOS Switch/Router DHCP configuration commands.
Available on the TechNet Gallery:
Your DHCP server may already have Option 120 or the Vendor Class options defined. If this is the case and any of these options are defined as anything other than the Binary type then the tool will display the setting as <UNSUPPORTED TYPE> . This looks like the following:
 |
| Unsupported Type of and Existing Option |
 |
| Option Definition Change Dialog |
The tool also does checks on Option 120 when it reads it from the DHCP server to ensure that it is formatted correctly (as defined by RFC3361). If it determines that the setting is not in the correct format it will display <UNSUPPORTED FORMAT> in the text box. If this happens, then I suggest you upload a new setting over the top of the unsupported setting to ensure that your phones can parse the option properly.
Important Note: You must refresh the scopes within the Windows DHCP Server MMC console in order to see changes you have made with the DHCP Config Tool.