An alternative approach would be to show
these values by placing them into a relationship pointing to the next element.
One reason favoring this choice would be to support reuse of switches as then
condition values that depend on the case would not be reused, just the switch
condition. This was abandoned because other switches would behave
differently during modeling. For example, the Language switch, discussed
next, has just one value for comparison and would then be empty.
. A Language switch speci?¬?es the communication language the caller wants to
use. In the modeling language, this was implemented by adding a property type
for entering the preferred language. This property was de?¬?ned as a string,
although prede?¬?ned values could be added to speed up modeling. If the value
entered is matched during call processing, execution of the speci?¬?ed language
FIGURE 5.3 A speci?¬?cation describing a choice expressed with a switch
104 IP TELEPHONY AND CALL PROCESSING
choice is made. If a match is made (True), a choice speci?¬?ed using a Default
relationship path is followed. See Fig. 5.3 for an illustration.
. The string switch is needed to specify decisions based on free-form strings
present in a call request. It has one property to give the string value and two
additional ?¬?elds to specify in more detail how the string matching is done and
what protocol is used (e.
Pages:
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218