Cisco AS5350 as E1 Gateway

This is a special case of use Cisco AS5350 as Trunk Gateway for remote site where it is planned to connect Customer's PBX (Private Branch eXchange) via E1 (EDSS/PRI). Remote Site's AS5350 is connected to Central SoftSwitch by SIP protocol.

“DISCLAIMER”: SIP protocol as well as EDSS signalling system and baseline Cisco configuration are not subjects of this review. It is supposed that you are quite familiar with these ones.

Overview

Cisco AS5350 has the following modules installed:

Router#show chassis slot detail | include AS535
DFC type is AS5350 NP60 DFC
DFC type is AS5350 E1 2 PRI DFC
DFC type is AS5350 E1 2 PRI DFC
Router#

“NP60” is 60x56k modems Card, it is not so interesting, and the next two are Cisco AS535-DFC-2CE1. They have on-board all necessary hardware such as DSP, memory, etc. That is they are self-sufficient.

First of all let's talk about VoIP Objects Hierarchy in Cisco Routers. It inherits ISO/OSI principles - there is special “entity” for each ISO/OSI level.

  1. controllers are responsible for physical link in E1 span;
  2. serial interfaces are responsible for time-slots grouping, for signalling selection and controlling;
  3. voice ports are intended for some global setting. For example, here preliminary or final translation of A- and B-numbers can be done.


This is not exact accordance to ISO/OSI but it helps to understand what by what follows. As you can see first of all Controller must be set up. Then some global action on Synchronization set up can be required to do prior other steps. Then we create Serial interfaces (or they can be created automatically depending on settings choosen during controller configuration. For example, for PRI they will be created immediately after we choose this signalling type in controller configuration mode). Then we create Voice port (or just set up automatically created one). At last we configure Voice Routing which defines what calls depending on contained in corresponding signalling messages B-numbers where must be routed (directed) to. Routing configuration is culminating moment (and the most frequently claimed later) in whole process.

There are two ways to set up VoIP-PSTN routing in those diagram.

  • The first - “traditional”.
    • it is very desirable to perform routing with “normalized” numbers: i. e. operate with “pure” E.164 numbers as: +74957889188 or “national” 4957889188, for example.
    • Because connected PBXs are “leaves” (or “stubs”) in “routing tree”, routes leading to them (SIP-to-TDM in this case) must have priority higher than back route (TDM-to-SIP).
    • Each Phone Number Pattern must have corresponding Dial-peer even if these are routes to the same PBX. Multiple “destination-pattern” lines are not allowed in Dial-peer configuration.
    • Every time when numbers are changed you need to “visit” AS5350 and do corresponding configuration changes.
  • The second - “prefixed
    • Each direction is assigned some special addition called “prefix”, which prepends number. Under “direction” we understand one customer's PBX. Not a E1 span but exactly PBX - it's because PBX may have several E1 spans. For example if it is a big PBX and the number of concurent calls is more than 30 (the number of time-slots in one E1). For example: 00000174957889188,00000174957873222 - these numbers belong to the same direction and they are marked by prefix “000001”. And we nake routing depending on this prefix not on numbers themself. That is we create the only Dial-peer for each PBX and indicate “destination-pattern 000001.+” in it instead of creating TWO Dial-peers with: “destination-pattern 74957889188” and “destination-pattern 74957873222”.
    • Of course this requres that SoftSwitch must be set up accordingly - it also must “understand” prefixes. And all information about exact numbers per direction will be accumulated on the SoftSwitch. But as a rule to do this via its Web interface is much more convenient than through Cisco's CLI!
    • There is no more need to “visit” Cisco each time the numbers are changed. We can add, remove or change phone numbers in corresponding direction simply doing that on the SoftSwitch side.

We are going to make routing by the second way.

E1 Controller setup

First of all set up controller.

Router>enable
Password: *************
Router#configure terminal
Router(config)#controller e1 2/0
Router(config-controller)#pri-group timeslots 1-31
Router(config-controller)#lineconde hdb3
Router(config-controller)#line-termination 120-ohm
Router(config-controller)#framing crc4
Router(config-controller)#end
Router#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
Router#

Some comments:

  1. pri-group timeslots 1-31 - defines EDSS signalling on this controller E1.
  2. linecode hdb3 - indicates that HDB3 code has been choosen as channel code, not AMI which is more typical for “American” T1 lines.
  3. line-termination 120-ohm - notice that this is default. Another case is “75-ohm” which is for coaxial cable as media.
  4. framing crc4 - switches on superframe mode when single frames are grouped by 16 in super structure in which 0-timeslot carries part of CRC of this mutiframe. With no CRC4 each frame is independent.

Sinchronization Issues

Let's setup syncronization and other global parameters.

Router#configure terminal
Router(config)#tdm clock priority 1 freerun
Router(config)#isdn switch-type primary-net5
Router(config)#end
Router#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
Router#

Some comments:

  1. tdm clock priority 1 freerun means that Cisco will use internal clock source. All possible values are:
    • external - to use external source plugged to AS5350 via external BITS (BNC-) connector by coaxial cable.
    • xx/yy span number - to get clock from one of E1 spans.
    • freerun - internal clock source.
      Let's look at drawing on the right. There are several schemes of “getting-in-sync”. E1 is such a thing wich requires that both of its ends must be synchronous. Otherwise there is great probability of transmittion errors called “slips” which is determined by difference of moments of time when transmitter sends a bit of information and when receiver tries to detect it. Ideally all over the world TDM network must be in synchronous state. But… There can be a cases. For example, when considered AS5350 plays role of gateway (second case on a diagram) between PSTN and endpoint Asterisk. Then Cisco will be in-sync with PSTN but finite Asterisk will not be. Because it is SIP-oriented (not TDM) and because it has no source for that even if it would want it because Ethernet/IP is asynchronous in its nature. And at last in out case (the third case) Cisco itself will be out-of-sync with TDM but so long as Ciso connects other TDM stations it must give correct clock to others. Well.. Since we connected to PSTN via SIP and we have no External source therefore we are forced to use Internal Clock Generator.
      You can see the status of Clocks by command “show tdm clocks”.
  2. isdn switch-type primary-net5 - defines variety of DSS Signalling system which is ETSI (European Telecommuncation Standard Institute) compliant and commonly used in Russia. Reference to www.cisco.com with search pattern “as5350 isdn switch-type” to look at other Signalling Systems.
    Note: It can be issued as in global configuration mode as in Serial interface configuration described later.

Now we can plug E1 span connector to Cisco and look at controllers:

Router#show controllers e1 2/0 brief
E1 2/0 is up.
  Applique type is Channelized E1 - balanced
  No alarms detected.
  alarm-trigger is not set
  Version info of slot 2:  HW: 517, PLD Rev: 1
  Framer Version: 0x8

Manufacture Cookie Info:
 EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x0A,
 Board Hardware Version 2.5, Item Number 73-5268-02,
 Board Revision B0, Serial Number JAE072004U6,
 PLD/ISP Version <unset>,  Manufacture Date 15-May-2003.

  Framing is CRC4, Line Code is HDB3, Clock Source is Free Running.
  Data in current interval (114 seconds elapsed):
     0 Line Code Violations, 0 Path Code Violations
     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
  Total Data (last 2 15 minute intervals):
     1 Line Code Violations, 1 Path Code Violations,
     0 Slip Secs, 0 Fr Loss Secs, 1 Line Err Secs, 0 Degraded Mins,
     1 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Router#

Main moments to pay attention to are here:

  • E1 2/0 is up”;
  • No alarms detected”;
  • Framing is CRC4, Line Code is HDB3, Clock Source is Free Running.”;
  • 0 Line Code Violations, 0 Path Code Violations” and “0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins” and “0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs” - in the section “Data in current interval”. When “Total Data” shows errors - it's no matter - it could be at the beginning moment when E1 brings UP.

Serial Interfaces

Then we need to customize Serial interface which has been created automatically when we typed “pri-group” in controller configuration. Most of parameters concerned to considered issue are focused in “isdn” clause. These are parameters of EDSS/ISDN/PRI level (logical level). Most of things you are not needed to complete - EDDSS will work fine with the default values, but sometimes it's needed. For example, you may want to modify the following (it is not obligue) parameters (these are not critical):

  • isdn service b_channel” - disables separate B-channels (voice channels) for choosing them for phone calls.
  • isdn negotiate-bchan ” - allows to try to setup phone call repeatedly if B-channel negotiation with conter-side is failed.
  • isdn calling-number” - allows to replace A-numbers sent to this direction by AS5350 by one indicated number
  • isdn outgoing” - controls wether or not some IEs will be sent via this E1 span.
  • isdn outgoing-voice” - define one of: 3.1kHz/Speech.
  • isdn reject” - indicates some types of calls that will be rejected.
  • isdn send-alerting” - defines wether or not AS5350 will send ALERTING before CONNECT message.
  • isdn timer” - sets up various ISDN timers

…and so on.

As it has been said previously interface “Serial” is created automatically as soon as you assign pri-group into “controller E1”. It always has name: “Serial XX/YY:15” where XX/YY are the same as in “controller E1 XX/YY” name. Look at the following:

Router#configure terminal
Router(config)#inteface Serial 2/0:15
Router(config-if)#isdn switch-type primary-net5
Router(config-if)#isdn protocol-emulate network
Router(config-if)#isdn incoming-voice data
Router(config-if)#end
Router#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
Router#

Some comments:

  • isdn switch-type primary-net5 the same as previously considered for global configuration mode. It defines DSS standard for this certain E1 span if globally defined DSS differs from locally used one.
  • isdn protocol-emulate network - this is the very first configured parameter for EDSS: “User” or “Network”. In our case Cisco plays role of “Network” for all its connected PBXes.
  • isdn incoming-voice data - this is the Bearer capability. It can be “data” (voice) or “modem” (digital signal of modem or fax). To be truthful I configured this parameter only due to Cisco's reluctance to establish calls - it showed in debug “wrong capability”. All my previous experience shows that there is no need to configure one.

Configure other ISDN parameters as needed.

Configuring Voice Port

So.. Since we have done with Serial interface let's configure Voice-ports. Generally speaking voice port is more abstract entity than Serial Interface. It is intended for voice property and routing configuration. As Serial Interface as Voice port is created automatically when controller E1 is assigned “pri-group” and it has “synonymous” name as parental controller E1: controller E1 2/0 → voice-port 2/0:D. “D” is referred to D-channel in ISDN(PRI), which has number “15” (just remember interface Serial 2/0:15).

Voice port allows to define different voice features of associated with this direction. For example:

  • bearer-cap” - defines Bearer Capability for EDSS.
  • cptone RU” - indicates Call Progress tones (RU - Russian Federation) for “analog” part of Voice-port.
  • threshold” - defines sound threshold. When noise in line is not above this threshold Cisco stops sending RTP (with voice) packets on Ethernet to reduce its bandwidth consumtions for this certain call.
  • music-threshold” - when music-on-hold is played too quiet Cisco can stop sending RTP by mistake thinking that this is NOISE. To avoid that this parameter is used.
  • comfort-noise” - when Cisco stop sending RTP packets with voice, for speaker (human) it looks like absolute silence and human begins to cry out into handset: “Hallo! Hallo!” thinking that call is crached. This brings some discomfort. This option generates some noise in handset and therefore speaker fills himself well.
  • echo-cancel” - customizes Echo cancellation parameters. When Analog (old) station is connected to VoIP network voice Echo is arised. Cisco eliminates it summing voice signal with its shifted in time copy.

Let's configure.

Router#configure terminal
Router(config)#voice-port 2/0:d
Router(config-voiceport)#no vad
Router(config-voiceport)#translation-profile incoming 1001
Router(config-voiceport)#end
Router#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
Router#

Some comments:

  • no vad - notice, that this command could not be viewed via ”?”. It switches off VAD at all. Inspite of all fandangles and advantages which VAD gives it would be better to disable it if there is no acute need of bandwidth economy.
  • translation-profile incoming … - this is A- and B-number manipulation rule which cuts off or on the contrary adds some digits or replaces whole number and so on. This is one of pillar of Routing which will be described later.

Well, all above was about TDM part of call. It is called “leg”. VoIP Leg does not require special object hierarchy all its issues are resolved during routing. Let's consider routing.

Configuring Dial-peers

Routing in Cisco (and in all VoIP devices generally) is intriduced by Dial-peers. Each dial-peer is separate route. It has certain structure: destination number pattern (or exact mutch of number), some translation of A- and/or B-number and destination represented by described above voice port (this is for E1 spans or for FXS/FXO analog ports) or immediate indication of an IP address of Soft-switch for SIP side. These are most important parts of any Dial-peer.

So, there are two types of dial-peers depending on type of ”physics”:

Router#configure terminal
Router(config)#dial-peer voice 100 pots
Router(config-dial-peer)#destination-pattern 011100.+
Router(config-dial-peer)#translation-profile outgoing 1000
Router(config-dial-peer)#direct-inward-dial
Router(config-dial-peer)#port 2/0:D
Router(config-dial-peer)#forward-digits all
Router(config-dial-peer)#exit
Router(config)#dial-peer voice 999 voip
Router(config-dial-peer)#destination-pattern 999.+
Router(config-dial-peer)#translation-profile outgoing 9999
Router(config-dial-peer)#voice-class codec 1
Router(config-dial-peer)#session protocol sipv2
Router(config-dial-peer)#session target ipv4:10.0.98.99
Router(config-dial-peer)#dtmf-relay rtp-nte
Router(config-dial-peer)#no vad
Router(config-dial-peer)#fax-relay ecm disable
Router(config-dial-peer)#fax rate 9600
Router(config-dial-peer)#fax protocol t38 ls-redundancy 5 hs-redundancy 3 fallback none
Router(config-dial-peer)#end
Router#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
Router#

Some comments:

  • destination-pattern - routing is built so that there is no matter from where call has arised it is much more important what to do with it. In that sence Dial-peers are made to find out egress direction: “Destination pattern” is the pattern of B-number or whole B-number. The rules for pattern building are the following:
    • .” - any symbol. This may be a digit, letter or some special symbol, for example: ”+”, ”(”, ”)”, ” ”, etc. Just look at that: +7 (495) 788 9188.
    • ^” - - special symbol meaning beginning of a string. For example: “^8985…….” means that match will be positive if real number has the same digits: “8985” exactly at the beginning (not somewhere else). And then they are followed by seven arbitrary symbols (at least). Symbol “^” when it is a part of number is introduced by backslash: “\^”. Another example: “8985” regexp means that “8985” can occur everywhere in B-number: 84951898507, 89851984384 and 4996548985. But “^8985” means that these digits can be exactly the beginning, that is: 89851984384 B-number only, but not two others!
    • $” has the similar sence as previous, but “at the end of the string. That if record “4384$” means that this digits can be at the and of B-number and not somewhere else. B-number must finish with this digits. “$” binds forestolling digits to the end of B-number (for positive match). In this case B-number: 84954384156” will not match, but 89851984384 will match to this pattern.
    • []” introduce “alphabet” for certain position of pattern for B-number. For example: “^849[589]…….$” means that in fourth position of expected B-number could occur digits “5”, “8” or “9”. That is this pattern expands to three real patterns: “8495…….”, “8498…….” and “8499…….”.
    • +” means “one or more repetitions of previous symbol”. Expression “3+” means “3 from here and for infiniti”, This can be “3” at the current position, “33”, “333” and so on to the end of B-number. The most frequent use of ”+” is ”.+” - “for the rest of number”. For example, if length is not critical you can write pattern as “^8495…….” of just as reduced “^8495.+” - the result will be the same if you need that B-number begins with “8495”.
    • *” means “zero or more repetitions of previous symbol” much like previous example but be careful! If there it must be “some” symbols (at least one!) than here it easy can be “nothing or more”! It can be or it can not be. And “from here up to the end of number”.
    • ?” - “zero or one repetition of previous symbol”. The same as “*” but “not to infinity”. For example: “8?495…….$” expands to 84957835599 or 4957835599. That is it accounts if user dials 8 before number or not.
    • \(” and “\)” introduce “parentheses” - a part of the pattern which then can be used in replacement. Notice that they are introduced with backslash! This is particular for Cisco's Regexp. In PCRE (Perl Compatible Regular Expressions) they are introduced without “\”. In Cisco parenthesis is a part of number by default: +7 (495) 787 3222. And here the most frequent use of them: /^000001\(495…….\)$/ /\1/. Here the first ”/…/” is comparision and the second ”/…/” is replacement. “It must match that replacement is actuated”. This works as follows: number in 495-area with prefix “000001” replaced with number without prefix. That is: 0000014957873222 → 4957873222 - all from parentheses is carried to egress expression. Another use: /^000001\(495…….\)$/ /000002\1/ here one prefix (000001) is replaced by another (000002). For example: 0000014957835599 → 0000024957835599. One more notice: the first parentheses will be in replacement “\1”, the second parentheses will be in replacement “\2” and so on.
    • |” - within parentheses means “this or that”. For example: ^8495783\(5599|5588\)$ which expands in two numbers: 84957835599 or 84957835588.
    • \” - introduces above symbols as part of number, for example: /192\.168\.0\.1/ - remember that ”.” is “any symbol” by default.
      Let's look at some examples of use RegExp: \\
      /^8?49[589]......./ matches to 8495....... and 495....... and 8498....... and 498....... and 8499....... and 499....... and 8495................. (only start of the number is bind).
      /^849578355\(99|88\)$/ matches to 84957835599 and 84957835588.
      /8495/ matches to 84957873222 and 84991478495. It's because it is not clear where 8495 must occur in B-number.
      /^0.....\(.*\)$/ /\1/ will eliminate 6-digit prefix in B-number and leave intact remainder of one. For example 00000284957873222 will become 84957873222.
      /^0..\(...\)\(.......\)$/ /000\18495\2/ will replace 0110017873222 with 00000184957873222. Notice, here length is exact because "^" and "$" are used! "^" binds the beginning of B-number but nothing says about its length!
  • translation-profile outgoing - in our case all dial-peers will be ”terminating” (because we use “destination-pattern” instead of “incoming called-number” as for ”initiating” dial-peers, or in other words “incoming route”), so translation can be outgoing too. Initiating Dial-peers work for corresponding voice-port when indicated in “incoming called-number” arrives from associated with voice-port PSTN. Outgoing Translation Profile defines “last translation” for B- or A-number, which will occur AFTER routing and before call information will be sent through E1-span or SIP-network. Here the name of translation profile is indicated. There are rules for A- and/or B- numbers in profile. Profile can also contain single rule for one of these numbers it is not obligue to translate both of them. Right here we modify (strip or on the contrary add some digits from/to) A- and/or B-number.
  • direct-inward-dial enables to send digits of B-number to PSTN direction. This matters for PSTN Dial-peers only. As it is explained in ”?” in dial-peer configuration mode, this means: ”Use Called Number as final call destination”.
  • port 2/0:D chooses target Voice-port 2/0:D for this PSTN dial-peer (and assicated PSTN direction).
  • forward-digits sets mode of B-number digits forwarding for PSTN Dial-peers. For example we can forward all digits, we so indicate “all” here. Abother case we can stripe some digits from original B-number. In that case we indicate the number of “right-justified” digits to be forwarded. For example for B-number 84957873222 and “forward-digits 7” only “7873222” will be forwarded to this PSTN direction. And at last we can indicate some “additional” digits which will be forwarded as extension number as DTMF signals after Connection will be established.
  • voice-class codec defines voice codecs set for VoIP Dial-peer. Codec sets which Cisco AS5350 supports for this given voice direction are defined in global configuration mode separately. How this is done will be shown later.
  • session protocol and session target describes which protocol must be used and what is an IP of counter side. Of course this is applicable for VoIP Dial-peers only.
  • dtmf-relay rtp-nte - send DTMF pressings as symbols in RTP headers according to RFC2833, not as sounds in voice channel. Another method is SIP-Info messages containing symbols corresponding to DTMF signals.
  • no vad disables VAD features for certain VoIP Dial-peer(route). This is actual for VoIP Dial-peers only.
  • fax-relay ecm disable this and two subsequent commands determine how faxes will be relayed through VoIP networks (again, VoIP Dial-peers only). This option disables Error Correction Mode (ECM) for faxes. Using ECM fax-machine divides all image onto number of blocks with graphical data and calculates Control Sums for each one. Then blocks are transmitted into line one-by-one and if one of them will have errors receiving side will ask to send it again. Not all Faxes support this mode, it is better to switch it off. The fact is that Cisco is located between the first Fax-machine connected to it via TDM network and VoIP network which has further changeover (in any event) back to analog lines connecting the second Fax-mashine.
    Here it is suitable to discuss some aspects of fax processing. Look at the drawing. It is the most important moment when Fax is initiated from TDM directly connected to AS5350. When Fax comes from VoIP Cisco gets all needed parameters from incoming from VoIP T.38 packets to establish connection to TDM-side Fax-machine correctly. But.. When fax comes from TDM Cisco has not all needed parameters to relay fax throug VoIP side. We need indicate them and the most appropriate place to do that is outgoing Dial-peer. That is VoIP Dial-peer.
    Let's look what is happening when user dials number on his Fax. After number is dialed usual voice call established from end to end: from the left-side Fax machine throug Cisco Soft-switch remote gateway, PSTN and right-side Fax. When the user near left-side Fax presses “Start” button on it acoustic beeps are heared and they are transmitted to the remote Fax (right-side) within voice channel. It hears them and begins to setup T.30 session (Fax data over voice (analog) line). Remote Gateway intercepts T.30 and sets up T.38 relay session between it and its VoIP dial-peer. That is with Soft-switch. The last tries in order to set up T.38 session with subsequent VoIP peer which is AS5350 in our case. And so on while T.38 will not be established from one VoIP end to another (between two TDM clouds). Then Cisco sets up T.30 with left-side Fax and all begins to work: T.30 message incoming from left-side Fax is relayed to remote gateway through VoIP cloud(s) being incapsulated into T.38 packet then it is forwarded by remote gateway to right-side Fax. This continues up to Faxes finish transmit facsimile image.
    In conclusion cast a glance at Wireshark's trace on the right. Here 4991589848 initially calls to 4996540000 but Fax session is established vice versa - from 4996540000 to 4991589848. Here 10.0.99.99 and 10.0.99.121 are IPs of one transit Soft-switch, 10.0.99.100 and 10.0.99.111 are IPs of another transit Soft-switch (which can be considered as remote VoIP gateway), 10.0.99.31 is left-side gateway (near 4991589848), right-side gateway could not be viewed from this point of trace (the nearest to 4996540000 VoIP device is 10.0.99.100/10.0.99.111). The voice call flows from left to right regarding to upper diagram.
  • fax rate 9600” limits speed of facsimile images transmission. One more speed is 14400, but old Faxes could not understand higher tham 9600 speeds. So we make our gateway most acceptable for most of Faxes. We work for most common case.
  • fax protocol t38 ls-redundancy 5 hs-redundancy 3 fallback none” defines what transport for fax protocol will be used. It could be T.38, Cisco propreitary protocol or Voice channel. In the last case AS5350 does not establish T.38 session and prefers to send T.30 messages packed as voice in G.711a/u codec (or another actual codec choosen for VoIP network). All cases except T.38 are not desirable for VoIP networks so we indicate T.38. LS- and HS- are decrypted as Low-Speed and High-Speed redundancy attempts. Fact is that Fax tries several times to speed up or speed down during establishing T.30 session. The number of attempts is empirical for this certain network. And at last “fallback” means that if T.38 session could not be established wether or not Cisco will try to pack T.30 messages as voice into codec G.711a/u. In our case this is not a flavor to use fallback.

Codecs Customization

Now, let's consider mentioned above “voice class codec”. This is a set of codecs which will be supported by Cisco on VoIP side. On TDM side this will always be one of G.711a/u codecs. But for VoIP it could be the same G.711a/u and in addition to them: G.279, G.722, G.723, G.726 and so on. These are very efficient for bandwith economy which is very actual for Ethernet networks where bandwidth is divided between its consumers as opposed to TDM where timeslots have fixed 64k bandwidth.

Router#configure terminal
Router(config)#voice class codec 1
Router(config-class)#codec preference 1 g711alaw
Router(config-class)#codec preference 2 g729r8
Router(config-class)#end
Router#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
Router#

Some comments:

  • voice class codec 1 - defines a group (set) of codecs.
  • codec preference specifies a codec and its order (priority). When two SIP peers negotiate about codecs they sort their codec sets and choose one of matched. For example, one SIP device has the following list: G.729(1),G.711a(2),G.726(3) and the second one has list: G.711a(1),G.722(2),G.729(3). First of all SIP devices find intersection of two declared sets (G.711a and G.729). At the second step they determine actual codec basing on the minimum of sum of priorities: G.711 has 2+1=3 and G.729 has 1+3=4. G.711 will be used.
    They also have algorithms of resolving the situations when some of codecs have the same “sum of priorities” but it does not matters at this moment. The main idea: codec sets must intersect! The best practice is to use G.711a codec which is most common for Russian PSTN (for whole TDM and for some of VoIP networks too) and some of “bandwidth efficient” ones (G.729 or G.723 - remember that they both are not free and it could be required that they must be licensed!).
    Notice: -r8 or -br8 are variations of G.729 (-A or -B annexies) and it could be required to select needed Annex empirically.

A-/B- numbers translation (modification)

The last moment on the way to building own Routing Schema is A- and B-numbers translation. This was mentioned but not considered. So. Translation is used by Voice Ports of Dial-peers as reference to Name-of-Translation-Profile. Translation can be as for incoming call leg (for example for calls incoming from TDM E1 spans into Cisco) as for outgoing to VoIP (in VoIP Dial-peer). For each of these directions translation can be further as for A-number as for B-number or for both. Translation profile consists of rule sets called simply rule in Cisco configuration. Separate rule's conditions (those are very matches which were deescribed before) are compared with B-number (or A-numer) and in a case of match some replacements are performed. First matching occurence breaks rules precessing and translation is finished.

Router#configure terminal
Router(config)#voice translation rule 100
Router(cfg-translation-rule)#rule 1 /^\(.......\)$/ /74996549999/
Router(cfg-translation-rule)#rule 2 /^\(..........\)$/ /74996549999/
Router(cfg-translation-rule)#rule 3 /^8\(..........\)$/ /7\1/
Router(cfg-translation-rule)#rule 2 /^810\(.....+\)$/ /\1/
Router(cfg-translation-rule)#exit
Router#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
Router#

Some comments:

  • This is example of typical number normalization to full E.164 numbers before routing.
  • voice translation rule opens ruleset. Be careful with syntax because there is “translation rule” (without “voice” ahead). It means something else.
  • rule 1 /^\(…….\)$/ /74996549999/ defines the first rule in the set. Number of rule is its priority. B-number (of A-number) will be compared with rules according an order in which rules are numbered! The sence of this rule is to check if only 7 digits were dialed (instead 8-xxxxxxxxxx, i.e. without national telephone prefix) and replace B-number with new one which forwards call to corporate autoresponder with “Wrong Number” message.
  • rule 2 /^\(……….\)$/ /74996549999/ checks if 10 digits were dialed and if so replaces original B-number with number of autoresponder (4996549999) which informs about incorrect dialing.
  • rule 3 /^8\(……….\)$/ /7\1/ - this replaces in correctly dialed number national prefix “8” with country code “7” (”+7” is for Russian Federation and Kazakhstan).
  • rule 2 /^810\(…..+\)$/ /\1/ - this strips “810” from international number.

We will use as incoming translation as outgoing one.

Routing

Let's start considerartion of routing now. Look at the diagram. It shows logic of routing obviously.

Roughly we can mark out only two mainstream directions of call flow:

  1. from SIP to TDM;
  2. from TDM to SIP.

And our Cisco is between both TDM and SIP performs routing as border gateway. As it is mentioned we are intended to follow prefix-oriented routing with 10-digit national significant phone numbers (not E.164). There are several prefixes which mark different TDM directions, and we compare the prefix and forward call to some direction depending on wether its prefix matched prefix from actual call or not. Notice that for call-flow from TDM to SIP there is no need in prefix because SIP direction is just one. But nevertheless we translate some prefix into SIP cloud. And this prefix matches the one used for calls to TDM. This is information for Soft-switch: what if it would needed to route this calls depending on direction via this call were originated. This is so called “origin-based routing”. For example, we have two customers and also we have two PSTN Providers who connect our PSTN segment to itself. One of our customer prefers when we use for his certain calls the first our PSTN Provider (for example on voice quality reasons) and the second one has now difference. In that case we need to know on what customer PBX this call is originated. If it is the first customer's PBX then our Soft-switch forwards call to the first PSTN Provider only, if it is the second one Soft-switch will load-balance calls between two of our uplinks.

As you can see at the drawing here the following prefixes are used:

  • 011100 - the first TDM direction (controller E1 2/0);
  • 011101 - the second TDM direction (controller E1 2/1);
  • 011102 - the third TDM direction (controller E1 3/0);
  • 011103 - the fourth TDM direction (controller E1 3/1).

Take a look at the drawing again. When call arrives from SIP to Cisco it picks up a prefix, chooses corresponding E1 span and stripes the prefix to give customer's PBX “pure” 10 digits of national number. Digits are striped after routing, that is after routing decision has already made and corresponding TDM E1 span has choosen!

Ok. Go further. Let's look what happens when call goes from TDM to SIP. It is very fortunate that we have separate dial-peer for each TDM direction where we can perform phone number translation during or imediately after routing. But the situation with backward direction is more difficult because we have the only dial-peer for SIP. At the moment when call is routed to SIP there is no information yet where it is from. Recall that main principle of Cisco routing is: “it is no matter where call has come from it is more important what to do with it further!”

But we need to mark a call somehow with originating prefix. And the way out is! Voice-port has an opportunity to do phone number translation. What would be if we add prefix of actual TDM direction there? But let's predict what happens if incoming call would get prefix BEFORE routing at the “entrance” into AS5350. What dial-peer will be choosen if we add 011100 to B-number incoming from Voice-port 2/0:D? I think the same one will be choosen and we will have potential routing loop! So we can't use “pure” TDM direction's prefix! But what can we do?..

Take a look at the drawing again. In that case we use “intermediate” prefix “999xxx” which means SIP direction, and in VoIP dial-peer we match first three nines: “999.+”. And next three digits are from TDM directions prefix. That is. If call comes from the first TDM span it has added prefix “999100”, if it comes from third TDP span it has “999102” and so on. If you take a notice to prefix used for TDM routing you realize that only the last digit is significant. It is shown in red at the above drawing. Generally we could use something like “999990”, “999991”… as a prefix. But we don't. As SIP dial-peer is chosen as we do in it the last translation of B-number changing nines (“999xxx”) onto “011xxx” of real prefix which is transmitted to SIP Soft-switch.


In conclusion let's explain how these prefixes are obtained. This sample routing schema is taken from real PSTN networking. Prefix is strongly structured there:

  • First digit is always zero: “0” - to discriminate prefix from user's dialing which begins with “8” in Russia. Of course we can compare the length of numbers but some transit PSTN switches have no notion about “length”. So “zero” is for them.
  • Then zero is followed by two-digit number of point of presence (PoP) of this PSTN provider. Here is eleventh PoP: “11”.
  • Then three-digit number of local PSTN direction follows.
    • Directions 000…099 are resrved for Uplinks (i. e. joining superior PSTN provider). Uplinks give us an “exit” to whole (world-wide) PSTN.
    • Directions 100…899 are for customer connections. So this is our case “100” is the first client's TDM direction on this certain Point-Of-Presence, “101” is the second one and so on.
    • Directions 900…999 are reserved for future use.

Well… “0” plus “11” plus “1” plus “00” gives “011100” - the first TDM span of AS5350. Do you understand? ;-)

Now let's look at how it looks in practice. :-) Let's gather separate pieces into entire view.

Router#configure terminal
Router(config)#voice class codec 1
Router(config-class)#codec preference 1 g711alaw
Router(config-class)#codec preference 2 g711ulaw
Router(config-class)#codec preference 3 g729r8
Router(config-class)#exit
Router(config)#
Router(config)#voice translation-rule 9990
Router(cfg-translation-rule)#rule 1 /^8\(..........\)$/ /\1/
Router(cfg-translation-rule)#rule 2 /^\(.......\)$/ /495\1/
Router(cfg-translation-rule)#exit
Router(config)#
Router(config)#voice translation-rule 999
Router(cfg-translation-rule)#rule 1 /^999\(...\)..........$/ /011\14996549999/
Router(cfg-translation-rule)#rule 2 /^999\(...\).......$/ /011\14996549999/
Router(cfg-translation-rule)#rule 3 /^999\(...\)8\(..........\)$/ /011\1\2/
Router(cfg-translation-rule)#rule 4 /^999\(...\)\(810......+\)$/ /011\1\2/
Router(cfg-translation-rule)#rule 5 /^999\(...\)\(0[123459]\)$/ /011\1\2/
Router(cfg-translation-rule)#rule 6 /^999\(...\)\(009\)$/ /011\1\2/
Router(cfg-translation-rule)#rule 7 /^999\(...\)\(057\)$/ /011\1\2/
Router(cfg-translation-rule)#rule 8 /^999\(...\)\(100\)$/ /011\1\2/
Router(cfg-translation-rule)#exit
Router(config)#
Router(config)#voice translation-profile 9999
Router(cfg-translation-profile)#translate calling 9990
Router(cfg-translation-profile)#translate called 9999
Router(cfg-translation-profile)#exit
Router(config)#
Router(config)#dial-peer voice 999 voip
Router(config-dial-peer)#translation-profile outgoing 999
Router(config-dial-peer)#destination-pattern 999.+
Router(config-dial-peer)#voice-class codec 1
Router(config-dial-peer)#session protocol sipv2
Router(config-dial-peer)#session target ipv4:10.0.99.99
Router(config-dial-peer)#dtmf-relay rtp-nte
Router(config-dial-peer)#fax-relay ecm disable
Router(config-dial-peer)#fax rate 9600
Router(config-dial-peer)#fax protocol t38 ls-redundancy 5 hs-redundancy 3 fallback none
Router(config-dial-peer)#no vad
Router(config-dial-peer)#exit
Router(config)#
Router(config)#
Router(config)#
Router(config)#voice translation-rule 1000
Router(cfg-translation-rule)#rule 1 /^011100\(.*\)$/ /\1/
Router(cfg-translation-rule)#exit
Router(config)#
Router(config)#voice translation-rule 1001
Router(cfg-translation-rule)#rule 1 /^\(.*\)$/ /999100\1/
Router(cfg-translation-rule)#exit
Router(config)#
Router(config)#voice translation-profile 1000
Router(cfg-translation-profile)#translate called 1000
Router(cfg-translation-profile)#exit
Router(config)#
Router(config)#voice translation-profile 1001
Router(cfg-translation-profile)#translate called 1001
Router(cfg-translation-profile)#exit
Router(config)#
Router(config)#controller E1 2/0
Router(config-controller)#pri-group timeslots 1-31
Router(config-controller)#exit
Router(config)#
Router(config)#interface Serial2/0:15
Router(config-if)#isdn switch-type primary-net5
Router(config-if)#isdn protocol-emulate network
Router(config-if)#isdn incoming-voice data
Router(config-if)#exit
Router(config)#
Router(config)#voice-port 2/0:D
Router(config-voiceport)#translation-profile incoming 1001
Router(config-voiceport)#no vad
Router(config-voiceport)#exit
Router(config)#
Router(config)#dial-peer voice 100 pots
Router(config-dial-peer)#translation-profile outgoing 1000
Router(config-dial-peer)#destination-pattern 011100.+
Router(config-dial-peer)#direct-inward-dial
Router(config-dial-peer)#port 2/0:D
Router(config-dial-peer)#forward-digits all
Router(config-dial-peer)#end
Router#
Router#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
Router#

Some comments:

  • This example contains full configuration of the VoIP part and configuration for the first E1 span. And the first in order VoIP, then TDM follows.
  • voice class codec is considered above in detail we will not discuss it severally.
  • voice translation profile 999 for VoIP Dial-Peer consists of two voice translation rules: 9990 (for A-numbers which are sent to SIP) and 9999 (the same but for B-numbers). Rule 9990 (tailing “0” means “A”) represents simple A-number normalization. Because customer's TDM PBX is not under our responsibility it can send to us a call with incorrect A-number. We can't control this but we need to provide that A- and B-numbers are sent to our central Soft-switch in correct 10-digit National Format (that is without County Code ”+7”). So what are cases which AS5350 can meet.
    A-number can be: a) correct 10-digit form; b) 7-digit number in code “495” which was correct several years ago and it is historically left on customer's PBX; c) 10-digit with National Prefix “8”. For the two latter cases we perform addition 495 for 7-digit number and remove “8” for number with prefix.
    All is more complicated when we talk about B-numbers! They are dialed by PBX user, it is not PBX programming which is always constant even if it is wrong. There are much more cases could be. For example, user can dial 7873222 (as traditionally without “495” zonal code and required for now prefix “8”) or 49578783222 (user forgot dial prefix “8”) instead 84957873222. In these cases we replace original user dialed number by number of autoresponder (4996549999) somewhere on our PSTN network segment which informs about incorrect dialing. The remainder of rules continues B-number normalization (remove prefix “8” from B-number for example) and modifies routing prefix replacing leading “999” by “011” (number of PoP) leaving last 3 digits of routing prefix intact. Let's recall that Voice-port add prefix “99910x” for incoming from TDM calls and VoIP Dial-peer makes from this prefix something normal: “01110x” where “10x” is Number-of-Customer's-TDM-Direction for this PoP (100, 101, 102, 103). Just look at these fragments of rules: “^999\(…\)” - in comparision and “011\1” in replacement.
    Also notice to order of three rules. They must be exactly such! First of all we identify incorrect dialing and send it to autoresponder and after that we normalize complete B-number (“complete” is in the sense of “8” presence). If order would be different (for example third rule suddenly would become the first) all calls would be treated as “incorrect input”.
  • Pay attention to dial-peer voice 999 voip. Here all is as descibed before. And the most notable moment destination pattern which is “999.+”. A call addressed to VoIP segment initially passes Voice-port where it is added 999+number-of-span, then it is matched here and this dial-peer is choosen as outgoing route. “999” is common for all voice ports and at the same unique for SIP direction and “number-of-span” differs. Then outgoing translation puts all on its places “999” is transformed to “normal” “011”. And at exit we get normal prefix of E1 originating span: “01110x”. This “999” plays dual role: firstly it let us to avoid route loop (TDM span to itself), and it identifies SIP dial-peer.
  • For TDM E1 span there are two translation profiles with its corresponding translation rules (one rule per translation profile). They numbered with certain sence: “100” is number of direction and right added digit means either incoming (“1”) or outgoing (“0”) direction. “1” is much similar with “I” and “O” with “0”.
    So “1001” is incoming profile. Here we just add mentioned “999100” for the first TDM E1 span and … “999103” for the last one. It is used in Voice-port. And “1000” is used in outgoing to TDM “POTS” dial-peer. It just stripes any prefixes from B-number before sending B-number to adjacent customer's PBXes.
  • controller e1 2/0 and interface serial 2/0:15 and voice-port 2/0:D are “bla-bla-bla” as described in detail in above text. The most notable momments are: “isdn-protocol emulate network” and “isdn incoming-voice data” for Serial, “no vad” is for Voice-port.
  • dial-peer voice 100 pots identifies its associated TDM E1 span. Certain dial-peer is for certain E1. There are four E1 spans and there are for corresponding dial-peers. Look at destination-pattern. Each catches its own routing prefix - “011100” in this certain case.

Misc diagrams

Now let's speak about some secific diagrams of using Cisco AS5350. E1 carrier in general is 30 simultaneous conversation. Experienced users quantity for this number of conversation is calculated as “1-to-5”. That is only 1 from 5 users is talking at any time. In any words one E1 (30 timeslots or conversations) is enough for approximately 150 users. But this is correct for average company. Let's imagine what is an organization with 150 employees just who has phone? It is large company! This is right but not always. Some call-centres can deviate common statisctics. For example call center with only 40 operators will utilize exactly 40 lines (time-slots) major part of the day. So we come up to main question: what to do if we meet PBX with two E1 spans?

Fortunately Cisco as the most of transit telephony switches has an opportunity to represent some separate E1 spans as a group - TRUNK GROUP. And they act as a single whole. What to do? First of all selected Controllers E1 are marked with an option “trunk group <name>”. Immediately after that trunk group <name> appears in global configuration. Then we can modify some trunk group settings in global configuration mode such as: translation profile incoming/outgouing, hunt-scheme, max-calls and some ISDN specific parameters. After that we indicate this newly created trunk group as traget in POTS Dial-peer.

In practice we used the same translation scheme as described, that is addition “99910x” to incoming from E1 B-number was performed in voice-port because it was created in any event as well as interface Serial 2/0:15. Outgoing translation was in corresponding Dial-peer. And trunk group was used only as “marker” and target for E1 group.

Router#configure terminal
Router(config)#controller e1 2:0
Router(config-controller)#trunk-group 100 timeslots 1-31
Router(config-controller)#exit
Router(config)#controller e1 2:1
Router(config-controller)#trunk-group 100 timeslots 1-31
Router(config-controller)#exit
Router(config)#trunk group 100
Router(config-trunk-group)#hunt-scheme ?
  least-idle    The interface with timeslot, that has been idle least, is selected
  least-used    The interface with maximum free timeslots is selected
  longest-idle  The interface with timeslot, that has been idle longest, is selected
  random        The timeslot is selected randomly
  round-robin   The next interface with free timeslots is selected
  sequential    The interface with highest preference is selected
  <cr>
Router(config-trunk-group)# hunt-scheme round-robin ?
  both  Select from all available timeslots
  even  Select from available even numbered timeslots at higher precedence
  odd   Select from available odd numbered timeslots at higher precedence
  <cr>
Router(config-trunk-group)#hunt-scheme round-robin both ?
  down  Timeslots are selected in the descending order
  up    Timeslots are selected in the ascending order
  <cr>
Router(config-trunk-group)#hunt-scheme round-robin both up
Router(config-trunk-group)#exit
Router(config)#dial-peer voice 100 pots
Router(config-dial-peer)#trunkgroup 100
Router(config-dial-peer)#end
Router#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
Router#

Some comments:

  • controller e1 2/0, controller e1 2/1 - at least two controllers must be marked as trunk-group “members”. Otherwise this idea has no sence - all issues with number of time-slots less (or equal) then 30 can be resolved using single E1 span.
  • trunk group 100 - defines common group parameters, for example huntimg algorithm - this how time-slots are selected for new calls. There different algorithms are shown. We have choosen cyclic go over free at the moment time-slots increasing each time time-slot and E1 spans numbers, i. e. 2/0-1, 2/0-2 … 2/0-14, 2/0-16, 2/0-31, 2/1-1, 2/1-2 … and so on. This is called “round-robin sequental both up”. Instead for example “round-robin sequental even down”. In the last case only “even” time slots are considered (odd will be used by counter side) and numbers of time-slots each time decreased (from end to beginning, that is: 30, 28, 26…).
  • dial-peer voice 100 pots - opens dial-peer's configuration. Here we indicate destination for calls as “trunkgroup 100”. Be careful - if you has added ”port 2/0:D” Cisco does not give to add ”trunkgroup 100”. It says: “ERROR: voice port exists”. You need to remove “port 2/0:D” directive first.
  • Some words about translations. Call flow are much the same. When Call flows from E1 to SIP each “controller E1”, “interface Serial” and “Voice-port” acts independently as before. When using trunk group we have to setup the same addition for both controllers - 2/0 and 2/1. The same prefix “011101” need to be added in voice-port translations because this is one direction which is compozed from two E1 spans. They connect to the same customer's PBX. And when call flows from SIP to TDM there is the only dial-peer where trunkgroup is indicated as call destination. There is the only translation is indicated to strip “011100” from B-number. And trunk group will decide which B-channel (time-slot) from which of two E1 spans to select for this certain call. “Trunkgroup” setting will lead the call through corresponding “Voice-port”, “Interface Serial” and “controller E1” objects for choosen E1 span.

IOS Commands

IOS (useful) Commands used:

  • debug voice dialpeer - enables debugging for voice dial-peers;
  • debug ccsip … - enables debugging of SIP packets/events and so on;
  • show tdm clocks - shows Clock Synchronization Sources and its statuses;
  • show controller e1 2/0 brief - shows brief summary on E1 status;
  • clear controller e1 2/0 - clears SLIPs (and others) counters;
  • show controllers | include Clock - shows which clock source which E1 Line uses;

Audiocodes Setup

Diagram

Let's consider work of Auciocodes as Media Gateway in two variants - as FXS and as FXO simultaneously. This customization is rather difficult.

The main diagram is represented on the left picture. Because of abcense real (analogue) PSTN connection was emulated by the second FXS (FXS2) we temporarily sacrifed it. We registered FXS2 on available Cisco 2821 CME and linked it FXO. When a call arrives from 2821 to FXS it redirected on wire on FXO port and vice-versa.

The first FXS (FXS1) works as planned - for connection of analogue Phone to Asterisk Server.

Let's describe diagram in detail. In the middle of the drawing is LAN (L2) segment represented by Cisco WS-C2960-8TC-L (actually it doesn't matter what a switch in use it maybe even non-controlled “plain” switch). Begind the switch Asterisk is placed. It is a central part of diagram it terminates all calls incoming from PSTN and initiate outgoing back to it. Also Asterisk registers local phones with short numbering plan (101, 102… FXS/analogue and IP Phones and so on).

Resetting Audiocodes

To return Audiocodes to Factory defaults you need to something like paper clip - to push and hold hidden pinhole button uninterruptedly for more than 6 seconds. Gateway will return to Factory Settings, particularly:

  • Username: Admin;
  • Password: Admin;
  • IP Address: 10.1.10.10 (or something like that).

Sometimes IP Address may restore to another value (10.10.10.10 or 10.10.10.1 etc.). In that case we need to dump broadcast traffic on this LAN segment (certainly ARP requests) by Wireshark. Just after Wireshark has started we need to reboot Audiocodes by Power Cycle. When it reboots it will send on the LAN (on certain bootstrap stage) so-called “Gratuitous ARP” to let other participants to know about itself existense (they update their ARP Tables to be ready to begin data exchange with the new device).

This illistration depicts just an example how it looks. In the illustration Hikvision IP Camera sends Gratuitous ARP, but in the case of Audiocodes all will be the same except MAC (“Audiocodes_XX:XX:XX”) and IP (10.xx.xx.xx).



Then we setup secondary (alias) IP on our computer's existing LAN connection, for example: 10.1.10.2/255.255.255.0, and connect Mediapack via browser by typing http://10.1.10.10. The next thing we should do is make general setup. It is also recommended - to chacnge default Username and Password in System → Management → Web User Account (depending on Audiocodes Software version Item Naming may change).

Cisco C2821 (Call Manager Express, CME) as IP PBX

This article considers a way to transform your 1841/2800/3800 into full-fledged IP-PBX. First of all - the diagram: As you can see Cisco is the pivotal figure of this scene. It is strongly recommended to upgrade it upto indicated IOS Version to avoiding problems like “something absent in CLI???”. As you can see Cisco brings together IP phones directly on a LAN and some different regular Phones and Faxes via internal High Density Module EVM-HD-8FXS with EM-HDA-3FXS/4FXO equipped on-board. The latter has Amphenol Connector with 25-pair cable which is pathched on a 24-port panel of RJ-45s where, in turn, regular Phones/Faxes are connected to.

Let's begin with Cisco IP Phone with SIP Frimware. Generally speaking it doesn't matter what a model of IP Phone if it is working via SIP Protocol. The first thing I had wondered to try was non-propreitary devices which widely used. If my CP7960 would be working then any other would do too. I need to notice that Cisco IP Phones have no embedded Web-interface. They are controlled via configuration file which is loaded via TFTP Protocol during Phone bootrstrap process. Let's consider it in detail because the most of settings are done via that file.


You need to know that Cisco products TWO Families of the Phones. They are: 79×0 and 79×1 (“79×1” is simply a name for the whole line of models which includes not only 7941/7961, but also 7942, 7975 and so on - from Cisco's point of view this is more perspective approach (and consequently architecture), so 7940/7960, perhaps, are “endangered spesies”. Literally!). Examples of the both can be CP7940 and CP7941. They are different in their nature:

  1. If 79×0 has binary image running in hardware (much like the most of operating systems like Windows or Ubuntu), the 79×1 initially boots its Loader image then Loader boots Java Machine into itself and finally Java boots Software for this or another Protocol (SIP or Skinny - it makes no odds). Due to its complexity 79×1 crashes sometimes, and in this sense 79×0 is more stable than 79×1. You might be needed to reset it down-to hardware bootloader, that is, remove not only Protocol Software, and even Java Machine too. Of course, all “secret codes” to do this will be “releaved” for you later.

  2. The second major difference between the families is their Configuration Files. For 79×0 it is a simple plain-text file in a form of: “option: value”. Instead, 79×1 has very complex XML-based configuration file, and you MUST BE very accurate to compose it - God help you if you forget some “closing stanza” (e. g. </code>), or if you even make excessive space in a wrong place - the Phone will reject such a Config with no comments!

  3. The third difference is how phones of these two families treat NAT. 79×0 works behind NAT with no problems. But it is a absolutely different story with 79×1: it is a some kind of nightmare to make it work when NAT is between the Phone and its SIP Server. The fact is that the Phone sends SIP Packets to the SIP Server from DYNAMIC UDP PORT (from the range: 1024..65535) BUT at the same time IT WAITS an answer on 5060! It broke my mind in olden times. Of course, the human mind is very interesting thing, and I found a solution (I will surely show you it) but… Let's say - it is not simple. And, of course, is not scalable. Try to avoid NAT when deal with 79×1.

  4. The fourth question is their Menus. If 79×0 let you do almost all settings via its Menus, the 79×1, instead, allow you to set up DHCP or Statis IP Address only. The most of all remain items are informational only. Exception is User Preferences (like Screen Logo or Ring Tone).

  5. The last what I'd like to mention is SNTP. SIP Firmware of 79×1 doesn't synchronize on-board time at all (at least I've not found a way), but 79×0 does the same easily. You may forget to see the time on your 79×1 Phone!


Let's begin consideration with 79×0 Family as more “understandable” and simple.

Cisco 79×0 IP Phones with SIP Firmware initially require from TFTP SIPDefault.cnf. It can comprise the most common settings for ALL PHONES but the particular ones will be asked later in the “personal” phone's file of the form: SIP00070E578F4F.cnf, where 00070E578F4F is nothing else but Phone's MAC Address: 0007.0E57.8F4F. You need to create and place eighter one or another or both onto TFTP Server (this role in this scenario was played by Ubuntu).

Well, it is suitable to deeply look into content of these files. Notice, they're identical in a sence of options allowed. If you have the only Cisco Phone you can deal with SIPDefault.cnf only. Or SIPMACADDRESS.cnf. It doesn't matter. The File has simple plain-text format, for example:

image_version: P0S3-06-3-00
logo_url: http://80.251.131.141/vily.bmp
proxy_register: 1
telnet_level: 2
time_zone: BT
sntp_mode: unicast
sntp_server: 80.251.131.136

SIPDefault.cnf Parameters

Parameter Description
anonymous_call_block (Optional) Configures anonymous call block. Valid values are as follows:
• 0—Disabled by default, but can be turned on and off using the user interface. When disabled, anonymous calls are received.
• 1—Enabled by default, but can be turned on and off using the user interface. When enabled, anonymous calls are rejected.
• 2—Disabled permanently and cannot be turned on and off locally using the user interface. Specify this parameter in the phone-specific configuration file.
• 3—Enabled permanently and cannot be turned on and off locally using the user interface. Specify this parameter in the phone-specific configuration file.

Default is 0.
auto_answer (Optional) Configures the intercom functionality so that the user can define one or more of their lines for this feature. It is an integer field that represents a bit mask of on or off for each line key. The bit mask reads from the least significant bit of 0 equal to line 1 to the most significant bit of 5 for line 6. Valid values are as follows:
• Cisco Unified IP Phone 7960G — 0 to 63
• Cisco Unified IP Phone 7940G — 0 to 3

Note This parameter cannot be set in the configuration file.
autocomplete (Phone-specific; optional) Configures automatic completion of numbers being dialed. Valid values are:
• 0—The autocomplete feature is disabled by default but can be turned on (or off) using the phone interface.
• 1—The autocomplete feature is enabled by default but can be turned off (or on) using the phone interface.
• 2—The autocomplete feature is disabled and cannot be turned on (or off) using the phone interface. To set this parameter for a specific phone, configure it in that phone's configuration file.
• 3—The autocomplete feature is enabled and cannot be turned off (or on) using the phone interface. To set this parameter for a specific phone, configure it in that phone's configuration file.

Default is 1.
call_hold_ringback (Phone-specific; optional) If you have a call on hold and are talking on another call, when you hang up the call, this parameter causes the phone to ring, letting you know that you still have another party on hold. Valid values are as follows:
• 0—Off by default, but can be turned on and off locally using the user interface.
• 1—On by default, but can be turned on and off locally using the user interface.
• 2—Off permanently and cannot be turned on and off locally using the user interface. Specify this parameter in the phone-specific configuration file.
• 3—On permanently and cannot be turned on and off locally using the user interface. Specify this parameter in the phone-specific configuration file.

Default is 0.
call_managerx_addr Reserved.
call_managerx_sip_port Reserved.
call_stats (Optional) Includes RTP statistics in BYE requests and responses. Valid values are 0 (disable) and 1 (enable). Default is 0. If this parameter is enabled, the phone inserts the headers RTP-RxStat and RTP-TxStat as follows:
• RTP-RxStat: Dur=a,Pkt=b,Oct=c,LatePkt=d,LostPkt=e,AvgJit=f
• RTP-TxStat: Dur=g,Pkt=h,Oct=i

where the following apply:
• Dur—Total number of seconds since the beginning of reception or transmission.
• Pkt—Total number of RTP packets received or transmitted.
• Oct—Total number of RTP payload octets received or transmitted (not including RTP header).
• LatePkt—Total number of late RTP packets received.
• LostPkt—Total number of lost RTP packets received (not including late RTP packets).
• AvgJit—Average jitter, which is an estimate of the statistical variance of the RTP packet inter-arrival time, measured in timestamp unit and calculated according to RFC 1889.
• a, b, c, d, e, f, g, h, and i—Integers.
call_waiting (Phone-specific; optional) Configures call waiting. Valid values are as follows:
• 0—Disabled by default, but can be turned on and off using the user interface. When disabled, call waiting calls are not received.
• 1—Enabled by default, but can be turned on and off using the user interface. When enabled, call waiting calls are accepted.
• 2—Disabled permanently and cannot be turned on and off locally using the user interface. Specify this parameter in the phone-specific configuration file.
• 3—Enabled permanently and cannot be turned on and off locally using the user interface. Specify this parameter in the phone-specific configuration file.

Default is 1.
callerid_blocking (Phone-specific; optional) Configures caller ID blocking. When enabled, the phone blocks its own number or e-mail address from phones that have caller identification enabled. Valid values are as follows:
• 0—Disabled by default, but can be turned on and off using the user interface. When disabled, the caller identification is included in the Request-URI header field.
• 1—Enabled by default, but can be turned on and off using the user interface. When enabled, “Anonymous” is included in place of the user identification in the Request-URI header field.
• 2—Disabled permanently and cannot be turned on and off locally using the user interface. Specify this parameter in the phone-specific configuration file.
• 3—Enabled permanently and cannot be turned on and off locally using the user interface. Specify this parameter in the phone-specific configuration file.

Default is 0.
cfwd_url (Optional) Configures the call forwarding feature. The maximum allowable characters for the string is 128. The character can be a telephone number or a URL.

Note This parameter cannot be set in the configuration file.
cnf_join_enable (Optional) Whether the conference bridge, when it hangs up, should attempt to join the two leaf nodes. Valid values are as follows:
• 0—Do not join the two leaf nodes.
• 1—Join the two leaf nodes.

Default is 1.
connection_manager_duration Reserved.
date_format (Optional) Format for dates. Valid values are as follows:
• M/D/Y—Month/day/year
• D/M/Y—Day/month/year
• Y/M/D—Year/month/day
• Y/D/M—Year/day/month
• Y-M-D—Year-month-day
• YY-M-D—4-digit year-month-day

Default is M/D/Y.
dial_template Template with which you specify which file to download for your dial plan.
directory_url (Optional) URL of the external directory server. This URL is accessed when you select Directory > External Directory. For example, use directory_url: “http://10.10.10.10/CiscoServices/Directory.asp”.
dnd_control (Phone-specific; optional) Sets the Do Not Disturb (DND) feature. Valid values are as follows:
• 0—Off by default, but can be turned on and off locally using the user interface.
• 1—On by default, but can be turned on and off locally using the user interface. The phone blocks all calls placed to the phone and logs those calls in the Missed Calls directory.
• 2—Off permanently and cannot be turned on and off locally using the user interface. Specify this parameter in the phone-specific configuration file.
• 3—On permanently and cannot be turned on and off locally using the user interface. This setting sets the phone to be a call-out phone only.
domain_name Name of the DNS domain in which the phone resides.
dscpForAudio Differentiated Services Code Point (DSCP) specifies the class of service for each audio packet.

Valid value is any positive integer. Default is 184.
dst_auto_adjust (Optional) Whether daylight savings time (DST) is automatically adjusted on the phones.

Valid values are 0 (do not adjust) and 1 (adjust). Default is 1.
dst_offset (Optional) Offset from the phone time when DST is in effect. When DST is over, the specified offset is no longer applied to the phone time.

Valid values are hour/minute, -hour/minute, +hour/minute, hour, -hour, and +hour.
dst_start_day (Optional) Day of the month on which DST begins. Valid values are the following:
• 1 to 31 (for days of the month)
• 0 (ignore this field and use the value in the dst_start_day_of_week parameter instead)

Default is 0.
dst_start_day_of_week (Optional) Day of the week on which DST begins. Valid values are as follows:
• Any of the following: Sunday or Sun, Monday or Mon, Tuesday or Tue, Wednesday or Wed, Thursday or Thu, Friday or Fri, Saturday or Sat, Sunday or Sun
• 1 to 7 (1 is Sunday; 7 is Saturday)

Name of the day is not case-sensitive. In the United States, the default is Sunday.
dst_start_month (Optional) Month in which DST starts. Valid values are the following:
• January, February, March, April, May, June, July, August, September, October, November, and December
• 1 to 12, with 1 being January and 12 being December

When the name of a month is specified, the value is not case-sensitive. In the United States, the default is April.
dst_start_time (Optional) Time of day on which DST begins.

Valid values are hour/minute (02/00) or hour:minute (02:00). In the United States, the default is 02:00.
dst_start_week_of_month (Optional) Week of month in which DST begins.

Valid values are 1 to 6 and 8 (1 is the first week; each subsequent number is a subsequent week; 8 is the last week in the month regardless of which week the last week is). In the United States, the default is 1.
dst_stop_day (Optional) Day of the month on which DST ends. Valid values are as follows:
• 1 to 31 (for the days of the month)
• 0 (ignore this field and use the value in the dst_stop_day_of_week parameter instead)

Default is 0.
dst_stop_day_of_week (Optional) Day of the week on which DST ends.

Valid values are Sunday or Sun, Monday or Mon, Tuesday or Tue, Wednesday or Wed, Thursday or Thu, Friday or Fri, Saturday or Sat, Sunday or Sun, and 1 to 7, with 1 being Sunday and 7 being Saturday. When the name of the day is specified, the value is not case-sensitive. In the United States, the default is Sunday.
dst_stop_month (Optional) Month in which DST ends.

Valid values are January, February, March, April, May, June, July, August, September, October, November, and December or 1 to 12 with 1 being January and 12 being December. When the name of a month is specified, the value is not case-sensitive. In the United States, the default is October.
dst_stop_time (Optional) Time of day on which DST ends.

Valid values are hour/minute (02/00) or hour:minute (02:00). In the United States, the default is 02:00.
dst_stop_week_of_month (Optional) Week of month on which DST ends.

Valid values are 1 to 6 and 8, with 1 being the first week, each number thereafter being subsequent weeks, and 8 being the last week in the month regardless of which week the last week is. In the United States, the default is 8.
Default is 0.
dtmf_avt_payload (Optional) Configures the payload type for Audio/Video Transport (AVT) packets. Range is from 96 to 127. If the value specified is null or invalid, default is 101.
dtmf_db_level (Optional) In-band DTMF digit tone level. Valid values are as follows:
• 1—6 dB below nominal
• 2—3 dB below nominal
• 3—nominal
• 4—3 dB above nominal
• 5—6 dB above nominal

Default is 3.
dtmf_inband Obsolete.
dtmf_outofband (Optional) Configures the out-of-band signaling (for tone detection on the IP side of a gateway).
Note The Cisco SIP IP phone supports out-of-band signaling using the AVT tone method. Valid values are as follows:
• none—Do not generate DTMF digits out-of-band.
• avt—If requested by the remote side, generate DTMF digits out-of-band (and disable in-band DTMF signaling); otherwise, do not generate DTMF digits out-of-band.
• avt_always—Always generate DTMF digits out-of-band. This option disables in-band DTMF signaling.

Default is avt.
dyn_dns_addr_1 (Optional) IP address of a new dynamic DNS server. If a new DNS server address is specified, it is used for any further DNS requests after the phone uses the initial DNS address upon bootup. The DNS addresses are used in the following order:
1. dyn_dns_addr_1 (if present)
2. dyn_dns_addr_2 (if present)
3. DNS Server 1
4. DNS Server 2
5. DNS Server 3
6. DNS Server 4
7. DNS Server 5

The dynamic DNS address is not stored in flash memory. Only dotted IP addresses are accepted. This value can be cleared by removing it from the configuration file or by changing its value to a null value ” ” or to “UNPROVISIONED.”

Note The dynamic DNS address is not stored in flash memory.
dyn_dns_addr_2 (Optional) IP address of a second dynamic DNS to be used for DNS requests. See dyn_dns_addr_1 for more information.
dyn_tftp_addr (Optional) IP address of a new dynamic TFTP server. After initially querying the default TFTP server, the phone rerequests the default and phone-specific configuration files from the new TFTP server. The dynamic TFTP server address is not stored in flash memory. The number of dyn_tftp_addr values supported by the phone is limited to prevent the phone configuration being downloaded repeatedly from multiple TFTP servers. Only dotted IP addresses are accepted. This value can be cleared by removing it from the configuration file or by changing its value to a null value ” ” or to “UNPROVISIONED.”
enable_vad (Optional) Enables voice activation detection (VAD).

Valid values are 0 (disable) and 1 (enable). Default is 0.
encrypt_key Reserved.
end_media_port (Optional) Configures the Real-Time Transport Protocol (RTP) end range for media.

Valid values are 16384 to 32766. Default is 32766.
garp_enable (Optional) Enables Gratuitous ARP for the phone. Valid values are as follows:
• 0—GARP is disabled.
• 1—GARP is enabled.
host_name Unique host name assigned to the phone. The value in this field is always SIPmac where mac is the MAC address of the phone.
http_proxy_addr (Optional) IP address of the HTTP proxy server. You can use either a dotted IP address or a DNS name.
http_proxy_port (Optional) Number of the HTTP proxy port. Default is 80.
image_version Firmware version that the phone should use. Enter the name of the image version as it is released by Cisco. Do not enter the filename extension (.bin).

Note You cannot change the image version by changing the filename because the version is also built into the file header. Trying to change the image version by changing the filename causes the firmware to fail when it compares the version in the header against the filename.
language (Optional) This parameter is for future use. English is the only value that is currently supported.
linex_authname (Phone-specific; optional) Name used by the phone for authentication if a registration is challenged by the proxy server during initialization. It is required only if a proxy server requires authentication from phones. If a value is not configured for the linex_authname parameter when registration is enabled, the default name is used. Default is UNPROVISIONED. The x argument can be 1 or 2.
linex_contact (Phone-specific; optional) The URL that appears in the contact field for SIP messages on a particular line.

The x is a line number on the phone. Default value is null.
linex_displayname (Phone-specific; optional) Identification as it should appear for caller-identification purposes. For example, instead of jdoe@company.com appearing on phones that have caller ID, you can specify User A in this parameter to have User A appear on the called party display. If a value is not specified for this parameter, nothing is used.

The x argument can be 1 or 2.
This is what will appear on a remote Cisco Phone screen when you call it!
linex_name (Phone-specific) Number or e-mail address for use when registering. Enter a number without dashes. For example, enter 555-0100 as 5550100. Enter an e-mail ID without the host name. The x argument can be 1 or 2.
linex_password (Phone-specific; optional) Password used by the phone for authentication if a registration is challenged by the proxy server during initialization. If a value is not configured for the linex_password parameter when registration is enabled, the default password is used. Default is UNPROVISIONED.

Valid values for x are (Cisco IP 7969G phone) 1 to 6 and (Cisco IP 7940G phone) 1 to 2.
linex_shortname Labels a line key with a name other than the directory number.
Label of a button on a Cisco Phone's Screen
local_cfwd_enable Whether the phone can do local call forwarding. This is a boolean field; it is either enabled or disabled.

Valid values are 0 (disable) and 1 (enable). Default is 1.
This enables Corresponding SoftKey on Cisco Phone's Screen
logo_url (Optional) Location of the company logo file. This logo appears on the phone display. The background space allocated for the image is 90 x 56 pixels. Images that are larger than this will automatically be scaled down to 90 x 56 pixels. The recommended file size for the image is from 5 to 15 Kb. For example, use logo_url: “http://10.10.10.10/companylogo.bmp”.

Note This parameter supports Windows 256 color bitmap format only. CMXML PhoneImage objects are not supported for this parameter. Using anything other than a Windows bitmap (.bmp) file can cause unpredictable results.
messages_uri (Optional) Configures the voice-mail number that is dialed when the messages button is pressed. Value is typically a phone number but can be a URI.
mwi_status (Optional) Displays the message waiting status.
Note You cannot set this parameter in the configuration file.
nat_address (Optional) WAN IP address of the Network Address Translation (NAT) or firewall server. Value is either a dotted IP address or a DNS name. (Use it carefully! This setting changes behavour of SIP Stack radically! It would much better to trust SIP Server and allow it detect and maintain NAT via difference between IP-Header and SIP Contact Field!)
nat_enable (Optional) Enables NAT. Valid values are 0 (disable) and 1 (enable). Default is 0.
•     If NAT is enabled, the Contact header appears as follows
          Contact: sip:lineN_name@nat_address:voip_control_port (This is what I've spoken about)
      If the nat_address is invalid or UNPROVISIONED, the Contact header appears as follows
          Contact: sip:lineN_name@phone_ip_address:voip_control_port
      and the Via header appears as follows
          Via SIP/2.0/UDP phone_ip_address:voip_control_port
• If NAT is enabled, the Session Description Protocol (SDP) message uses the nat_address and an RTP port between the start_media_port and the end_media_port range in the C and M fields. All RTP traffic is sourced from the port advertised in the SDP message.
nat_received_processing (Optional) Enables NAT received processing. Valid values are 0 (disable) and 1 (enable). Default is 0.
If nat_received_processing is enabled, and the received= tag is in the Via header of the 200 OK response from a REGISTER, the IP address in the received= tag is used instead of the nat_address in the Contact header. If this switch occurs, the phone unregisters the old IP address and reregisters with the new IP address.
network_media_type (Optional) Ethernet port negotiation mode. Valid values are as follows:
• Auto—Port is autonegotiated.
• Full100—Port is configured to be a full-duplex, 100-MB connection.
• Half100—Port is configured to be a half-duplex, 100-MB connection.
• Full10—Port is configured to be a full-duplex, 10-MB connection.
• Half10—Port is configured to be a half-duplex, 10-MB connection.

Default is Auto.
network_port2_type (Optional) Configures the device type that is connected to port 2 of the phone.
Valid values are Hub/Switch and PC. Default is Hub/Switch.
Note If the value is PC, port 2 can be connected only to a PC. If you are not sure about the connection, use the Hub/Switch default value. Specifying the PC option and then connecting port 2 to a switch results in spanning-tree loops and network confusion.
outbound_proxy (Optional) IP address of the outbound proxy server. You can use either a dotted IP address or a DNS name.
outbound_proxy_port (Optional) Port number of the outbound proxy server. Default is 5060.
When an outbound proxy is enabled, all SIP requests are sent to the outbound proxy server instead of to the proxyx_address. All responses continue to reconcile the normal Via processing rules. The media stream is not routed through the outbound proxy.
NAT and outbound proxy modes can be independently enabled or disabled. The received= tag is added to the Via header of all responses if there is no received= tag in the uppermost Via header and if the source IP address is different from the IP address in the uppermost Via header. Keep the following rules in mind:
• If a received= tag is in the uppermost Via header, the response is sent back to the IP address contained in the received= tag.
• If there is no received= tag and the IP address in the uppermost Via header is different from the source IP address, the response is sent back to the source IP address.
phone_label (Phone-specific; optional) Text to display on the top right status line of the LCD. This field is for end-user display only and has no effect on caller identification or messaging. For example, a phone label can display “User A's phone.” (Appears in the Top-Right Corner of a Cisco Phone's Screen) Limited to 11 characters.
phone_password (Phone-specific; optional) Password to be used for console or Telnet access. Limited to 31 characters. Default is cisco.
phone_prompt (Phone-specific; optional) Prompt to display during Telnet or console access. Limited to 15 characters. Default is SIP Phone>.
preferred_codec (Optional) Codec to use when a call is initiated.

Valid values are g711alaw, g711ulaw, g729a, and none. Default is g711ulaw.
proxy_backup (Optional) IP address of the backup proxy server or gateway. Enter this address in IP dotted-decimal notation.
Note You must specify at least one address or the phones cannot register.
proxy_backup_port (Optional) Port number of the backup proxy server. Default is 5060.
proxy_emergency (Optional) IP address of the emergency proxy server or gateway. Enter this address in IP dotted-decimal notation.
proxy_emergency_port (Optional) Port number of the emergency proxy server. Default is 5060.
proxy_register (Optional) The phone must register with a proxy server during initialization.

Valid values are 0 (disable registration during initialization) and 1 (enable registration during initialization). Default is 0.

Note You can also use this parameter in a phone-specific configuration file. After a phone has initialized and registered with a proxy server, you can remove the registration by changing this value to 0 in the phone-specific configuration file. To reinitiate registration, change the value back to 1.
Note If you enable registration and authentication is required, you must specify values for the linex_authname and linex_password parameters in the phone-specific configuration file.
proxyx_address IP address of the SIP proxy servers that are used by the phones. Enter the addresses in IP dotted-decimal notation or use the FQDN. The “x” argument is representative of server addresses.

Valid values for “x” are 1 to 6. If the proxyx_address parameter is provisioned with an FQDN, the phone sends REGISTER and INVITE messages by using the FQDN in the Req-URI, To, and From fields.

If the value of x is not specified in the proxyx_address parameter, the phone uses proxy1_address as the default value.
proxyx_port Port number of the SIP proxy server that will be used by phone lines other than line 1. The x variable represents a phone line.

Valid values are 2 to 6.

Note For additional phone lines, the proxyx_port parameter and the proxyx_port parameter can be used to assign different proxy addresses to different phone lines. The “x” in the parameters represents a phone line. The value of “x” can be from 1 to 6. If the value of the “x” is not specified in the proxyx_address parameter, the phone uses proxy1_address as the default.
remote_party_id (Optional) The Remote-Party-ID header supports network verification and screening of a call participant's identity (for example, name and number) and provides privacy for call participants.

Valid values are as follows:
• 0—Remote party ID is disabled. The phone does not send or accept the remote party ID.
• 1—Remote party ID is enabled. The phone sends the remote party ID, and can accept the remote party ID.

Default is 0.
rfc_2543_hold (Optional) Determine the SDP that a phone uses to place a remote party on hold. If this value is 1, the phone uses the RFC 2543 method and sets the media address to 0.0.0.0. If this value is 0, the phone uses the RFC 3264 style and instructs the other side to be in recvonly mode.

Default is 0.
semi_attended_transfer (Optional) Whether or not the caller can transfer the second leg of an attended transfer while the call is ringing.

Valid values are as follows:
• 0—Semi-attended transfer is disabled.
• 1—Semi-attended transfer is enabled.

Default is 1.
services_url (Optional) URL of the services BTXML files. This URL is accessed when the Services button is pressed. For example, use services_url: “http://10.10.10.10/CiscoServices/Services.asp.”
sip_invite_retx (Optional) Maximum number of times that an INVITE request will be retransmitted.

Valid value is any positive integer. Default is 6.
sip_max_forwards (Optional) The phone uses the value specified in this parameter in the Max-Forwards header of the SIP requests that it generates.

Default is 70.
sip_retx (Optional) Maximum number of times that a SIP message other than an INVITE request will be retransmitted.
Valid value is any positive integer. Default is 10.
sntp_mode (Optional) Mode in which the phone listens for the SNTP server.

Valid values are unicast, multicast, anycast, or directedbroadcast. Default is anycast
sntp_server IP address of the SNTP server from which the phone obtains time data.
speed_labelx (Optional) Configures the speed-dial key label. The x variable is from label 2 to label 6. There are five possible labels that can be configured on the Cisco IP 7960G but only one on the Cisco IP 7940G. The x variable is a string of up to 15 characters.
Note This parameter cannot be set in the configuration file.
speed_linex (Optional) Configures the speed-dial keys so that the user can set up one-touch dialing. There are five possible numbers that can be configured on the Cisco IP 7960G but only one on the Cisco IP 7940G. The x variable is a string of up to 128 bytes.
Note You cannot set this parameter in the configuration file.
start_media_port (Optional) Start RTP range for media.

Range is from 16384 to 32766. Default is 16384.
stutter_msg_waiting (Optional) Enables a stutter dial tone when there is a message waiting. It is disabled by default.
Valid values are 0 (off) and 1 (on).
sync (Optional) Value against which to compare the value in the syncinfo.xml file before a remote reboot is performed. Limited to 32 characters.
telnet_level (Optional) Enables Telnet for the phone. Valid values are as follows:
• 0—Disabled.
• 1—Enabled, and no privileged commands can be executed.
• 2—Enabled, and privileged commands can be executed.

Default is 0.
tftp_cfg_dir Path to the TFTP subdirectory in which phone-specific configuration files are stored.
Note This parameter is only required if the phone-specific files are in a subdirectory and not in the root directory.
time_format_24hr (Optional) Whether a 12- or 24-hour time format is displayed by default on the user interface. Valid values are as follows:
• 0—12-hour format is displayed by default but can be changed to a 24-hour format using the user interface.
• 1—24-hour format is displayed by default but can be changed to a 12-hour format using the user interface.
• 2—12-hour format is displayed and cannot be changed to a 24-hour format using the user interface.
• 3—24-hour format is displayed and cannot be changed to a 12-hour format using the user interface.

Default is 1.
time_zone (Optional) Time zone in which the phone is located. Abbreviations are case sensitive and must be in all capital letters. Default is PST.
timer_invite_expires (Optional) Amount of time, in seconds, after which a SIP INVITE expires. This value is used in the Expire header field.

Valid values are any positive number; however, we recommend 180. Default is 180.
timer_keepalive_expires Reserved.
timer_register_delta Configures the time interval at which reregistration will occur. This is a numeric field in which the time interval is measured in seconds.

Valid values range from 32767 to 0. Default is 5 (phone will attempt to reregister 5 seconds before its registration period expires).
timer_register_expires (Optional) Amount of time, in seconds, after which a REGISTRATION request expires. This value is inserted into the Expire header field.

Valid values are any positive number; however, we recommend 3600. Default is 3600.
timer_t1 (Optional) Lowest value, in milliseconds, of the retransmission timer for SIP messages.

Valid values are any positive integer. Default is 500.
timer_t2 (Optional) Highest value, in milliseconds, of the retransmission timer for SIP messages.

Valid values are any positive integer greater than timer_t1. Default is 4000.
tos_media Obsolete.
transfer_onhook_enabled If enabled, a user can transfer a call to a second user by hanging up the phone once the second user picks up the line. If disabled, a user must, before hanging up, press the Transfer button again to complete the transfer. Valid values are:
• 0—Disabled
• 1—Enabled

Default is 0.
user_info (Phone-specific; optional) Configures the “user=” parameter in the REGISTER message. Valid values are as follows:
• none—No value is inserted.
• phone—The value user=phone is inserted in the To, From, and Contact Headers for REGISTER.
• ip—The value user=ip is inserted in the To, From, and Contact Headers for REGISTER.

Default is none.
version_stamp The version of the configuration file, used by the phone to determine when a new confguration file appears on the TFTP server.

The value is a 64-byte string. Default value is null.
voip_control_port (Optional) UDP port used for SIP messages. All SIP REQUESTS use voip_control_port as the UDP source port when nat_enable = 1.

Range is from 1025 to 65535. Default is 5060.
xml_card_dir Reserved.
xml_card_file Reserved.

Menus & Time Zones

Abbreviation GMT Offset Cities Time-Zone Names
IDL GMT-12:00 Eniwetok IDL (International Date Line),
IDLW (International Date Line West)
NT GMT-11:00 Midway BT (Bering Time), NT (Nome Time)
AHST GMT-10:00 Hawaii AHST (Alaska-Hawaii Standard Time),
HST (Hawaiian Standard Time),
CAT (Central Alaska Time)
IMT GMT-09:30 Isle Marquises Isle Marquises
YST GMT-09:00 Yukon YST (Yukon Standard Time)
PST GMT-08:00 Los Angeles PST (Pacific Standard Time)
MST GMT-07:00 Phoenix MST (Mountain Standard Time),
PDT (Pacific Daylight Time)
CST GMT-06:00 Dallas, Mexico City CST (Central Standard Time),
MDT (Mountain Daylight Time), Chicago
EST GMT-05:00 New York EST (Eastern Standard Time),
CDT (Central Daylight Time), NYC
AST GMT-04:00 La Paz AST (Atlantic Standard Time),
EDT (Eastern Daylight Time)
NST GMT-03:30 Newfoundland NST (Newfoundland Standard Time)
BST GMT-03:00 Buenos Aires BST (Brazil Standard Time),
ADT (Atlantic Daylight Time),
GST (Greenland Standard Time)
AT GMT-02:00 Mid-Atlantic AT (Azores Time)
WAT GMT-01:00 Azores WAT (West Africa Time)
GMT GMT 00:00 London GMT (Greenwich Mean Time), UT (Universal Time)
WET (Western European Time)
CET GMT+01:00 Paris CET (Central European Time),
MET (Middle European Time),
BST (British Summer Time),
MEWT (Middle European Winter Time),
SWT (Swedish Winter Time),
FWT (French Winter Time)
EET GMT+02:00 Athens, Rome EET (Eastern European Time), USSR-zone1,
MEST (Middle European Summer Time),
FST (French Summer Time)
BT GMT+03:00 Baghdad, Moscow BT (Baghdad Time), USSR-zone2
IT GMT+03:30 Tehran IT (Iran Time)
ZP4 GMT+04:00 Abu Dhabi USSR-zone3, ZP4 (GMT Plus 4 Hours)
AFG GMT+04:30 Kabul Afghanistan
ZP5 GMT+05:00 Islamabad USSR-zone4, ZP5 (GMT Plus 5 Hours)
IST GMT+05:30 Bombay, Delhi IST (Indian Standard Time)
ZP6 GMT+06:00 Colombo USSR-zone5, ZP6 (GMT Plus 6 Hours)
SUM GMT+06:30 North Sumatra NST (North Sumatra Time)
WAST GMT+07:00 Bangkok, Hanoi SST (South Sumatra Time), USSR-zone6,
WAST (West Australian Standard Time)
HST GMT+08:00 Beijing, Hong Kong CCT (China Coast Time),
HST (Hong Kong Standard Time), USSR-zone7,
WADT (West Australian Daylight Time)
JST GMT+09:00 Tokyo, Seoul JST (Japan Standard Time/Tokyo),
KST (Korean Standard Time), USSR-zone8
CAST GMT+09:30 Darwin SAST (South Australian Standard Time),
CAST (Central Australian Standard Time)
EAST GMT+10:00 Brisbane, Guam GST (Guam Standard Time), USSR-zone9,
EAST (East Australian Standard Time)
EADT GMT+11:00 Solomon Islands USSR-zone10, EADT (East Australian Daylight Time)
NZST GMT+12:00 Auckland NZT (New Zealand Time/Auckland),
NZST (New Zealand Standard Time),
IDLE (International Date Line East)

As you might notice Menus of the Different Family (79×0 and 79×1) Phones are different. Practically the only thing you can set up in 79×1 Family Cisco Phone is Network Settings.

Sample SIPDefault.cnf / SIPDEADBEEFFEED.cnf

Note: DEED.BEEF.FEED - the most frequently met MAC-Address example in different documentation.

The most of Settings can be done through the Phone Menus. But not all and you still need (minimal) configuration file on TFTP Server. The sample one is the following:

image_version: "P0S3-08-2-00"
phone_label: "Parents"
logo_url: "http://172.16.21.5/cp7960logo.bmp"

telnet_level: "2"
phone_password: "cisco"
phone_prompt: "ipph-7960"

proxy_register: "1"
timer_register_expires: "120"

voip_control_port: "5061"
start_media_port: "16384"
end_media_port: "32766"

proxy1_address: "172.16.16.9"
proxy1_port:"5060"
line1_displayname: "101"
#line1_contact:
line1_name: "101"
line1_shortname: "Parents"
line1_authname: "**********"
line1_password: "**********"

#proxy2_address:
#proxy2_port:
#line2_displayname:
#line2_contact:
#line2_name:
#line2_shortname:
#line2_authname:
#line2_password:

The most important settings are:

  • image_version: “P0S3-08-2-00” - we indicate Firmware Image. If it hasn't changed since last Phone reboot it is not taken in account. But.. We can UPGRADE, or even CHANGE the type of Firmware through this setting!
  • proxy_register: “1” - we make the Phone to REGISTER on SIP Server (here SIP-Server is CME - for SIP Phones it is “The Boss”).
  • timer_register_expires: “120” - we need to re-REGISTER faster then SIP Server forgets about us.
  • proxy1_address: “172.16.16.9” - where to knock at for Registration and where to send INVITEs.
  • proxy1_port:“5060” - this is the default setting. But, sometimes ISP changes it to non-default (e. g. 5090) to lessen the chance of attacks.
  • line1_displayname: “101” - we still can change this through Menus gut it is rather inconvinient. It is textual Caller-ID.
  • line1_name: “101” - this is the NUMBER of the Phone.
  • line1_shortname: “Parents” - the label of the Button on the right of the Phone's Screen.
  • line1_authname: “* * * * * * * * * *” - Authentication username in the CME.
  • line1_password: “* * * * * * * * * *” - Authentication password in the CME.

The other settings either appear not very interesting or it would be better to change them through the Menus. I think it is not good idea to edit SIPDefault.cnf each time you wish to change Scree Logo - it can be done easily through Menus of the Phone. On the other hand it is a very hard task to type in something like “T9” of your iPhone the DNS Domain Name of the Cisco Phone… It is much easy to type it in textual editor on a computer though you do this only once.

79x1 Configuration File

Let's consider how to complete configuration of 79×1 Phone Family. The names of the Files are slightly different than SIPDefault.cnf/SIPDEADBEEFFEED.cnf: SEPDefault.cnf.xml and SEPDEADBEEFFEED.cmf.xml accordingly. And the names are always like this - independently of SIP or SCCP Firmware is in use. Take a glance at the Sample Config:

<device xsi:type="axl:XIPPhone" ctiid="1566023366">
<sshUserId>root</sshUserId>  
<sshPassword>root</sshPassword>
<deviceProtocol>SIP</deviceProtocol>
<devicePool>
 <dateTimeSetting>
  <dateTemplate>D-M-YA</dateTemplate>
  <timeZone>UTC Standard/Daylight Time</timeZone>
 </dateTimeSetting>
 <callManagerGroup>
  <members>
   <member priority="0">
    <callManager>
     <ports>
      <ethernetPhonePort>2000</ethernetPhonePort>
      <sipPort>5060</sipPort>
      <securedSipPort>5061</securedSipPort>
     </ports>
     <processNodeName>10.10.1.1</processNodeName>
    </callManager>
   </member>
  </members>
 </callManagerGroup>
</devicePool>
<sipProfile>
 <sipProxies>
  <backupProxy></backupProxy>
  <backupProxyPort></backupProxyPort>
  <emergencyProxy></emergencyProxy>
  <emergencyProxyPort></emergencyProxyPort>
  <outboundProxy></outboundProxy>
  <outboundProxyPort></outboundProxyPort>
  <registerWithProxy>true</registerWithProxy>
 </sipProxies> 
 <sipCallFeatures>
  <cnfJoinEnabled>true</cnfJoinEnabled>
  <callForwardURI>x--serviceuri-cfwdall</callForwardURI>
  <callPickupURI>x-cisco-serviceuri-pickup</callPickupURI>
  <callPickupListURI>x-cisco-serviceuri-opickup</callPickupListURI>
  <callPickupGroupURI>x-cisco-serviceuri-gpickup</callPickupGroupURI>
  <meetMeServiceURI>x-cisco-serviceuri-meetme</meetMeServiceURI>
  <abbreviatedDialURI>x-cisco-serviceuri-abbrdial</abbreviatedDialURI>
  <rfc2543Hold>true</rfc2543Hold>
  <callHoldRingback>2</callHoldRingback>
  <localCfwdEnable>true</localCfwdEnable>
  <semiAttendedTransfer>true</semiAttendedTransfer>
  <anonymousCallBlock>2</anonymousCallBlock>
  <callerIdBlocking>2</callerIdBlocking>
  <dndControl>0</dndControl>
  <remoteCcEnable>true</remoteCcEnable>
 </sipCallFeatures>
 <sipStack>
  <sipInviteRetx>6</sipInviteRetx>
  <sipRetx>10</sipRetx>
  <timerInviteExpires>180</timerInviteExpires>
  <timerRegisterExpires>120</timerRegisterExpires>
  <timerRegisterDelta>5</timerRegisterDelta>
  <timerKeepAliveExpires>120</timerKeepAliveExpires>
  <timerSubscribeExpires>120</timerSubscribeExpires>
  <timerSubscribeDelta>5</timerSubscribeDelta>
  <timerT1>500</timerT1>
  <timerT2>4000</timerT2>
  <maxRedirects>70</maxRedirects>
  <remotePartyID>false</remotePartyID>
  <userInfo>None</userInfo>
 </sipStack>
 <autoAnswerTimer>1</autoAnswerTimer>
 <autoAnswerAltBehavior>false</autoAnswerAltBehavior>
 <autoAnswerOverride>true</autoAnswerOverride>
 <transferOnhookEnabled>false</transferOnhookEnabled>
 <enableVad>false</enableVad>
 <dtmfAvtPayload>101</dtmfAvtPayload>
 <dtmfDbLevel>3</dtmfDbLevel>
 <dtmfOutofBand>avt</dtmfOutofBand>
 <alwaysUsePrimeLine>false</alwaysUsePrimeLine>
 <alwaysUsePrimeLineVoiceMail>false</alwaysUsePrimeLineVoiceMail>
 <preferredCodec>g729a</preferredCodec>
 <kpml>3</kpml>
 <phoneLabel>sales1</phoneLabel>
 <stutterMsgWaiting>1</stutterMsgWaiting>
 <callStats>false</callStats>
 <silentPeriodBetweenCallWaitingBursts>10</silentPeriodBetweenCallWaitingBursts>
 <disableLocalSpeedDialConfig>false</disableLocalSpeedDialConfig>
 <startMediaPort>16384</startMediaPort>
 <stopMediaPort>32766</stopMediaPort>
 <sipLines>
  <line button="1">
   <featureID>9</featureID>
   <featureLabel>953690330</featureLabel>
   <proxy>80.251.131.135</proxy>
   <port>5060</port>
   <name>953690330</name> 
   <displayName>953690330</displayName>
   <autoAnswer>
    <autoAnswerEnabled>2</autoAnswerEnabled>
   </autoAnswer>
   <callWaiting>3</callWaiting>
   <authName>953690330</authName>
   <authPassword>953690330</authPassword>
   <sharedLine>false</sharedLine>
   <messageWaitingLampPolicy>1</messageWaitingLampPolicy>
   <messagesNumber>700</messagesNumber>
   <ringSettingIdle>4</ringSettingIdle>
   <ringSettingActive>5</ringSettingActive>
   <contact>953690330</contact>
   <forwardCallInfoDisplay>
    <callerName>true</callerName>
    <callerNumber>false</callerNumber>
    <redirectedNumber>false</redirectedNumber>
    <dialedNumber>true</dialedNumber>
   </forwardCallInfoDisplay>
  </line>
  <line button="2">
   <featureID>21</featureID>
   <featureLabel>VBykov</featureLabel>
   <speedDialNumber>74996540001</speedDialNumber>
  </line>
 </sipLines>
 <voipControlPort>5060</voipControlPort>
 <dscpForAudio>184</dscpForAudio>
 <ringSettingBusyStationPolicy>0</ringSettingBusyStationPolicy>
 <dialTemplate>dialplan.xml</dialTemplate>
</sipProfile>

<commonProfile>
 <phonePassword></phonePassword>
 <backgroundImageAccess>true</backgroundImageAccess>
 <callLogBlfEnabled>2</callLogBlfEnabled>
</commonProfile>

<loadInformation>SIP11.8-4-2S</loadInformation>

<vendorConfig>
 <disableSpeaker>false</disableSpeaker>
 <disableSpeakerAndHeadset>false</disableSpeakerAndHeadset>
 <enableGroupListen>true</enableGroupListen>
 <pcPort>0</pcPort>
 <settingsAccess>1</settingsAccess>
 <garp>0</garp>
 <voiceVlanAccess>0</voiceVlanAccess>
 <videoCapability>0</videoCapability>
 <autoSelectLineEnable>0</autoSelectLineEnable>
 <webAccess>1</webAccess>
 <daysDisplayNotActive>1,2,3,4,5,6,7</daysDisplayNotActive>
 <displayOnTime>00:00</displayOnTime>
 <displayOnDuration>00:00</displayOnDuration>
 <displayIdleTimeout>00:00</displayIdleTimeout>
 <spanToPCPort>1</spanToPCPort>
 <loggingDisplay>1</loggingDisplay>
 <loadServer></loadServer>
</vendorConfig>
<versionStamp>1143565489-a3cbf294-7526-4c29-8791-c4fce4ce4c37</versionStamp>

 <userLocale>
  <name>Russian_Russia</name>
  <uid>1</uid>
  <langCode>ru_RU</langCode>
  <version>8.3(4)</version>
  <winCharSet>utf-8</winCharSet>
 </userLocale>

<networkLocale>Russian_Federtion</networkLocale>
<networkLocaleInfo>
 <name>Russian_Federation</name>
 <version>4.0(2)</version>
</networkLocaleInfo>

 <deviceSecurityMode>1</deviceSecurityMode>
 <authenticationURL>http://www/ipphone/authenticate.php</authenticationURL>
 <directoryURL>http://www/ipphone/directory.xml</directoryURL>
 <idleURL></idleURL>
 <informationURL>http://www/ipphone/GetTelecasterHelpText.jsp</informationURL>
 <messagesURL></messagesURL>
 <proxyServerURL>proxy:3128</proxyServerURL>
 <servicesURL>http://www/ipphone/services.xml</servicesURL>
 <dscpForSCCPPhoneConfig>96</dscpForSCCPPhoneConfig>
 <dscpForSCCPPhoneServices>0</dscpForSCCPPhoneServices>
 <dscpForCm2Dvce>96</dscpForCm2Dvce>
 <transportLayerProtocol>4</transportLayerProtocol>
 <capfAuthMode>0</capfAuthMode>
 <capfList>
    <capf>
       <phonePort>3804</phonePort>
    </capf>
 </capfList>

 <certHash></certHash>
 <encrConfig>false</encrConfig>

</device>

There are a lot of line and nothing is understandable. :-) Well… It is only for the first time you see it. :-) First of all - you don't need to change the whole file, just several line to make the phone working. SCCP version of the one is much “lighter”:

<device xsi:type="axl:XIPPhone" ctiid="1566023366">
<sshUserId>root</sshUserId>  
<sshPassword>root</sshPassword>
<deviceProtocol>SIP</deviceProtocol>
<devicePool>
 <dateTimeSetting>
  <dateTemplate>D-M-YA</dateTemplate>
  <timeZone>Russian Standard/Daylight Time</timeZone>
   <ntps>
    <ntp>
     <name>80.251.128.131</name>
     <ntpMode>Unicast</ntpMode>
    </ntp>
   </ntps>
 </dateTimeSetting>
<callManagerGroup>
  <members>
   <member priority="0">
    <callManager>
     <ports>
      <ethernetPhonePort>2000</ethernetPhonePort>
      <sipPort>5060</sipPort>
      <securedSipPort>5061</securedSipPort>
     </ports>
     <processNodeName>80.251.131.142</processNodeName>
    </callManager>
   </member>
  </members>
 </callManagerGroup>
</devicePool>

<commonProfile>
 <phonePassword></phonePassword>
 <backgroundImageAccess>true</backgroundImageAccess>
 <callLogBlfEnabled>2</callLogBlfEnabled>
</commonProfile>

<loadInformation>SCCP41.8-0-4SR1S</loadInformation>
<addOnModules>
 <addOnModule idx="1">
  <loadInformation>S00105000400</loadInformation>
 </addOnModule>
</addOnModules>

<vendorConfig>
 <disableSpeaker>false</disableSpeaker>
 <disableSpeakerAndHeadset>false</disableSpeakerAndHeadset>
 <enableGroupListen>true</enableGroupListen>
 <pcPort>0</pcPort>
 <settingsAccess>1</settingsAccess>
 <garp>0</garp>
 <voiceVlanAccess>0</voiceVlanAccess>
 <videoCapability>0</videoCapability>
 <autoSelectLineEnable>0</autoSelectLineEnable>
 <webAccess>1</webAccess>
 <daysDisplayNotActive>1,2,3,4,5,6,7</daysDisplayNotActive>
 <displayOnTime>00:00</displayOnTime>
 <displayOnDuration>00:00</displayOnDuration>
 <displayIdleTimeout>00:00</displayIdleTimeout>
 <spanToPCPort>1</spanToPCPort>
 <loggingDisplay>1</loggingDisplay>
 <loadServer></loadServer>
</vendorConfig>
<versionStamp>1143565489-a3cbf294-7526-4c29-8791-c4fce4ce4c37</versionStamp>

 <userLocale>
  <name>Russian_Russia</name>
  <uid>1</uid>
  <langCode>ru_RU</langCode>
  <version>8.3(4)</version>
  <winCharSet>utf-8</winCharSet>
 </userLocale>

<networkLocale>Russian_Federtion</networkLocale>
<networkLocaleInfo>
 <name>Russian_Federation</name>
 <version>4.0(2)</version>
</networkLocaleInfo>

 <deviceSecurityMode>1</deviceSecurityMode>
 <authenticationURL>http://www/ipphone/authenticate.php</authenticationURL>
 <directoryURL>http://www/ipphone/directory.xml</directoryURL>
 <idleURL></idleURL>
 <informationURL>http://www/ipphone/GetTelecasterHelpText.jsp</informationURL>
 <messagesURL></messagesURL>
 <proxyServerURL>proxy:3128</proxyServerURL>
 <servicesURL>http://www/ipphone/services.xml</servicesURL>
 <dscpForSCCPPhoneConfig>96</dscpForSCCPPhoneConfig>
 <dscpForSCCPPhoneServices>0</dscpForSCCPPhoneServices>
 <dscpForCm2Dvce>96</dscpForCm2Dvce>
 <transportLayerProtocol>4</transportLayerProtocol>
 <capfAuthMode>0</capfAuthMode>
 <capfList>
    <capf>
       <phonePort>3804</phonePort>
    </capf>
 </capfList>

 <certHash></certHash>
 <encrConfig>false</encrConfig>

</device>

Let's dive into details. Here is almost comlete set of options explained (Cisco doesn't want to be bothered by documenting them - CME of CUCM genereate them automatically using Router's Config):

Tag Name Desciption
<device>

</device>
File begins wit tag ”<device>” and ends with ”</device>”. You might see previously the following
<device xsi:type="axl:XIPPhone" ctiid="1566023366">

- this speaks that this file has been generated by CUCM/CME

<device>
 <deviceProtocol>SIP</deviceProtocol>
</device>
Points out which protocol is in use.
<device>
 <sshUserId>cisco</sshUserId>
 <sshPassword>cisco</sshPassword>

</device>
This group of parameters enables an access to the Phone via SSH. Forestall I would notice that session sets up for a quite long time (it is about 10 seconds) - it's normal. And after successful authentication via SSH you unexpectedly get another Login: - the Phone itself requires “internal” username which has certain privileges. Here they are:
      • log/log - can view Phone logs
      • debug/debug - can view operational parameters, debug and remote “typing” on a phone's keyboard - you can remotely reboot the Phone:
                test open
                test key set
                test key **#**
      • default/user - entering Shell - on the Phone Unix-like OS is running, using these credentials we can look at system events
<device>
 <devicePool>
  …
 </devicePool>
</device>
This code block defines external to IP Phone devices.
<device>
 <devicePool>
  <dateTimeSetting>
   …
  </dateTimeSetting>
 </devicePool>
</device>
Defines Time/Date Parameters.
<device>
 <devicePool>
  <dateTimeSetting>
   <dateTemplate>D.M.Y</dateTemplate>
  </dateTimeSetting>
 </devicePool>
</device>
This defines the Regional Date Format (only the order of Date/Month/Year, but not the number of digits).
<device>
 <devicePool>
  <dateTimeSetting>
   <timeTemplate>HH:MM</timeTemplate>
  </dateTimeSetting>
 </devicePool>
</device>
Time Format.
<device>
 <devicePool>
  <dateTimeSetting>
   <timeZone>Russian Standard/Daylight Time</timeZone>
  </dateTimeSetting>
 </devicePool>
</device>
Time Zone. Can be the following:
           1. Dateline Standard Time                (-720 min)         28. Central Europe Standard/Daylight Time (+120 min)
           2. Samoa Standard Time                   (-660 min)         29. South Africa Standard Time            (+120 min)
           3. Hawaiian Standard Time                (-600 min)         30. Jerusalem Standard/Daylight Time      (+120 min)
           4. Alaskan Standard/Daylight Time        (-540 min)         31. Saudi Arabia Standard Time            (+180 min)
           5. Pacific Standard/Daylight Time        (-480 min)         32. Russian Standard/Daylight Time        (+180 min)
           6. Mountain Standard/Daylight Time       (-420 min)         33. Iran Standard/Daylight Time           (+210 min)
           7. US Mountain Standard Time             (-420 min)         34. Caucasus Standard/Daylight Time       (+240 min)
           8. Central Standard/Daylight Time        (-360 min)         35. Arabian Standard Time                 (+240 min)
           9. Mexico Standard/Daylight Time         (-360 min)         36. Afghanistan Standard Time             (+270 min)
           10. Canada Central Standard Time         (-360 min)         37. West Asia Standard Time               (+300 min)
           11. SA Pacific Standard Time             (-300 min)         38. Ekaterinburg Standard Time            (+300 min)
           12. Eastern Standard/Daylight Time       (-300 min)         39. India Standard Time                   (+330 min)
           13. US Eastern Standard Time             (-300 min)         40. Central Asia Standard Time            (+360 min)
           14. Atlantic Standard/Daylight Time      (-240 min)         41. SE Asia Standard Time                 (+420 min)
           15. SA Western Standard Time             (-240 min)         42. China Standard/Daylight Time          (+480 min)
           16. Newfoundland Standard/Daylight Time  (-210 min)         43. Taipei Standard Time                  (+480 min)
           17. South America Standard/Daylight Time (-180 min)         44. Tokyo Standard Time                   (+540 min)
           18. SA Eastern Standard Time             (-180 min)         45. Cen. Australia Standard/Daylight Time (+570 min)
           19. Mid-Atlantic Standard/Daylight Time  (-120 min)         46. AUS Central Standard Time             (+570 min)
           20. Azores Standard/Daylight Time        (-60 min)          47. E. Australia Standard Time            (+600 min)
           21. GMT Standard/Daylight Time           (0 min)            48. AUS Eastern Standard/Daylight Time    (+600 min)
           22. Greenwich Standard Time              (0 min)            49. West Pacific Standard Time            (+600 min)
           23. W. Europe Standard/Daylight Time     (+60 min)          50. Tasmania Standard/Daylight Time       (+600 min)
           24. GTB Standard/Daylight Time           (+60 min)          51. Central Pacific Standard Time         (+660 min)
           25. Egypt Standard/Daylight Time         (+60 min)          52. Fiji Standard Time                    (+720 min)
           26. E. Europe Standard/Daylight Time     (+60 min)          53. New Zealand Standard/Daylight Time    (+720 min) 
           27. Romance Standard/Daylight Time       (+120 min)  
<device>
 <devicePool>
  <dateTimeSetting>
   <ntps>
    …
   </ntps>
  </dateTimeSetting>
 </devicePool>
</device>
Block of NTP Servers
<device>
 <devicePool>
  <dateTimeSetting>
   <ntps>
    <ntp>
     …
    </ntp>
   </ntps>
  </dateTimeSetting>
 </devicePool>
</device>
Certain NTP Server definition
<device>
 <devicePool>
  <dateTimeSetting>
   <ntps>
    <ntp>
     <name>80.251.131.136</name>
    </ntp>
   </ntps>
  </dateTimeSetting>
 </devicePool>
</device>
FQDN DNS Name or IP Address of an NTP Server
<device>
 <devicePool>
  <dateTimeSetting>
   <ntps>
    <ntp>
     <ntpMode>Unicast</ntpMode>
    </ntp>
   </ntps>
  </dateTimeSetting>
 </devicePool>
</device>
NTP Mode, can be the following:
      • Unicast - directed NTP Session
      • Multicast - Server sends its NTP Packets to 224.0.0.1 (“All Hosts”)
      • directedBroadcast - Server sends its Packest as broadcasts for certain network - 172.16.0.255 (for 172.16.0.0/24)
<device>
 <devicePool>
  <callManagerGroup>
   <members>
     <member priority=“0”>
     <callManager>
      <ports>
       <ethernetPhone-Port>2000</ethernetPhonePort>
       <sipPort>5060</sipPort>
       <securedSip-Port>5061</securedSipPort>
      </ports>
      <processNode-Name>10.10.1.1</processNodeName>
     </callManager>
    </member>
   </members>
  </callManagerGroup>

 </devicePool>
</device>
This blosk is intended to describe Phone's behavour when it is working with CUCM/CME. It terms of Cisco “Call Processing Unit” is a Server responsible for call handling. Also here some Protocol parameters are defined here.
<device>
 <sipProfile>
  …
 </sipProfile>
</device>
Block for SIP Protocol parameters
<device>
 <sipProfile>
  <sipProxies>
   …
  </sipProxies>
 </sipProfile>
</device>
Common Proxies (for all SIP Lines)
<device>
 <sipProfile>
  <sipProxies>
   <backupProxy></backupProxy>
    <backupProxyPort></backupProxyPort>
    <emergencyProxy></emergencyProxy>
    <emergencyProxy-Port></emergencyProxyPort>
    <outboundProxy></outboundProxy>
    <outboundProxy-Port></outboundProxyPort>
    …

  </sipProxies>
 </sipProfile>
</device>
Here we can indicate IPv4 Addresses and UDP ports for:
     Backup Proxy - it is used when Primary one is not accessible,
     Emergency Proxy - this Proxy will be used for “911” calls,
     Outbound Proxy - when one SIP Server is used for REGISTERs and Incoming INVITEs and for outgoing calls this one is used.
<device>
 <sipProfile>
  <sipProxies>
   <registerWithProxy>true</registerWithProxy>
  </sipProxies>
 </sipProfile>
</device>
This is the very important parameter! If it is not TRUE the Phone will not attempt to REGISTER! Don't miss it!
<device>
 <sipProfile>
  <sipCallFeatures>
   …
  </sipCallFeatures>
 </sipProfile>
</device>
Block for Call Handling Features definition.
<device>
 <sipProfile>
  <sipCallFeatures>
   <callForwardURI>x–serviceuri-cfwdall</callForwardURI>
    <callPickupURI>x–serviceuri-зшслгз</callPickupURI>
    <callPickupListURI>x-cisco-serviceuri-opickup</callPickupListURI>
    <callPickupGroupURI>x-cisco-serviceuri-gpickup</callPickupGroupURI>
    <meetMeServiceURI>x-cisco-serviceuri-meetme</meetMeServiceURI>
    <abbreviatedDialURI>x-cisco-serviceuri-abbrdial</abbreviatedDialURI>
    …

  </sipCallFeatures>
 </sipProfile>
</device>
These are CME features.
<device>
 <sipProfile>
  <sipCallFeatures>
   <rfc2543Hold>true</rfc2543Hold>
  </sipCallFeatures>
 </sipProfile>
</device>
This option defines how to process Call Hold: according either to RFC2543 (true) or to Cisco's Skinny Protocol (false).
<device>
 <sipProfile>
  <sipProxies>
   <callHoldRingback>1</callHoldRingback>
  </sipCallFeatures>
 </sipProfile>
</device>
This option determines the following: when a call which has been put into Hold State and then new call has been completed successfully whether the Phone should inform a User about the call still held. Values:
     0 - no, but this option can be changed through Menus
     1 - yes, but this option can be changed through Menus
     2 - no, and this option cannot be changed through Menus
     3 - yes, and this option cannot be changed through Menus
<device>
 <sipProfile>
  <sipCallFeatures>
   <localCfwdEnable>true</localCfwdEnable>
  </sipCallFeatures>
 </sipProfile>
</device>
Defines whether the Call Forward is allowed on this Phone or not:
     false - feature is disabled (and SoftKey CfwdAll is hidden from the Phone's Screen)
     true - feature is enabled.
<device>
 <sipProfile>
  <sipCallFeatures>
    <semiAttendedTrans-fer>true</semiAttendedTransfer>
  </sipCallFeatures>
 </sipProfile>
</device>
Enables or disables semi-attended transfer of the call. Together with transferOnHook=true changes the transfer mode: if previously it has been necessary to complete transfer with pressing Transfer after changing the option you can just hung down a handset.
      false - option is disabled
      true options is enabled
<device>
 <sipProfile>
  <sipCallFeatures>
   <anonymousCallBlock>2</anonymousCallBlock>
  </sipCallFeatures>
 </sipProfile>
</device>
Determins wether to suppress calls with incorrect Caller-Id or not.
     0 – Not, but can be changes through Menus
     1 – Yes, but can be changed through Menus
     2 – No, and cannot be changed through Menus
     3 – Yes, and connot be changed through Menus
<device>
 <sipProfile>
  <sipCallFeatures>
   <callerIdBlocking>2</callerIdBlocking>
  </sipCallFeatures>
 </sipProfile>
</device>
Defines whether it is necessary to suppress our own Caller-ID.
     0 – Not, but can be changes through Menus
     1 – Yes, but can be changed through Menus
     2 – No, and cannot be changed through Menus
     3 – Yes, and connot be changed through Menus

Reverting Cisco IP Phone between SIP and SCCP

Well.. Now we consider how to change Firmware on Cisco IP Phone to make it working via SIP or Skinny (Cisco Propreitary =SCCP) Protocols. Skinny offers much more opportunities while working with CME. For example the BLF (Busy Line Field) - monitoring other lines status (”on-hook/idle”, ”called”', or ”talking”) simultaneousely giving an ability to intercept unanswered call or speed-dial the monitored number.

You need Firmware files like:

  • For SIP (corresponding Cisco IP Phone model name(s) can be found in the filename)
    • cmterm-7911_7906-sip.9-0-3.zip
    • P0S3-08-8-00.zip
    • cmterm-7941_7961-sip.8-5-4.zip
    • cmterm-7942_7962-sip.8-5-4.zip
    • cmterm-7945_7965-sip.8-5-4.zip
    • cmterm-7970_7971-sip.8-5-4.zip
  • For SCCP (corresponding Cisco IP Phone modelname(s) can be found in the filename)
    • cmterm-7911_7906-sccp.8-4-2.zip
    • cmterm-7940-7960-sccp.8-1-2.zip
    • cmterm-7941_7961-sccp.8-4-2.zip
    • and so on…

Contents of the above files are as follows:
For SIP       in terms of 79×1 series:                      in terms of 79×0 series:

              apps11.8-4-1-23.sbn               OS79XX.TXT
              cnu11.8-4-1-23.sbn                P003-08-8-00.bin
              cvm11sip.8-4-1-23.sbn             P003-08-8-00.sbn
              dsp11.8-4-1-23.sbn                P0S3-08-8-00.loads
              jar11sip.8-4-1-23.sbn             P0S3-08-8-00.sb2
              SIP11.8-4-2S.loads
              term06.default.loads
              term11.default.loads

For SCCP       in terms of 79×1 series:                      in terms of 79×0 series:

              apps11.8-4-1-23.sbn                P00308010200.bin
              cnu11.8-4-1-23.sbn                 P00308010200.loads
              cvm11sccp.8-4-1-23.sbn             P00308010200.sb2
              dsp11.8-4-1-23.sbn                 P00308010200.sbn
              jar11sccp.8-4-1-23.sbn
              SCCP11.8-4-2S.loads
              term06.default.loads
              term11.default.loads
voipworx.txt · Last modified: 2016/12/27 14:20 by root_dokuwiki
 
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki