Browse code

more foobar added

Jiri Kuthan authored on 11/01/2003 00:31:01
Showing 3 changed files
... ...
@@ -1,7 +1,7 @@
1 1
 This directory contains short technical memos documenting 
2
-technical decisions made or planned to be made in ser or 
3
-accompanying applications. The memos serve as requests
4
-for comments in the literal sense (not to be confused
2
+best practices and technical decisions made or proposed
3
+for ser or accompanying applications. The memos serve as 
4
+requests for comments in the literal sense (not to be confused
5 5
 with IETF's RFCs).
6 6
 
7 7
 The documents here are drafts, for whose technical maturity
... ...
@@ -17,3 +17,7 @@ in plain ASCII. Their filenames consists of
17 17
 For example: tmemo-johndoe-backtobackua.txt
18 18
 No version numbers are used in filename -- these are displayed 
19 19
 in text and assigned by CVS server. 
20
+
21
+--
22
+TODO: reasonable topics which I would like to be addressed here
23
+include NAT traversal and multidomain management. -jiri
... ...
@@ -1,7 +1,7 @@
1 1
 $Id$
2 2
 
3
-Building Prepaid Scenarios Using SIP/SER
4
-========================================
3
+Draft Design Options for Building Prepaid Scenarios Using SIP/SER
4
+==================================================================
5 5
 
6 6
 Jiri Kuthan, iptel.org, January 2003
7 7
 
... ...
@@ -67,13 +67,16 @@ end-devices.
67 67
 The behaviour of the session-timer-based construct is as follows:
68 68
 a caller intiates a call through a proxy server. The proxy server
69 69
 determines maximum acceptable call length and inidiacates it using
70
-the session timer mechanisms. The timer is then propagates to
70
+the session timer mechanisms. The timer is then propagated to
71 71
 the end-device using SIP. If it actually hits, the terminating 
72 72
 gateway will try to revitalize the session using a re-INVITE. 
73 73
 The proxy server then can recalculate available credit, and if too 
74 74
 low, deny the re-invitation. The end-device is then supposed 
75 75
 to terminate the call using a BYE.
76 76
 
77
+  Note: a similar technique can be used to keep firewall
78
+  pinholes alive.
79
+
77 80
 We have never experimented with the session-timer-based solution.
78 81
 We do not know if some session timer negotiation troubles can
79 82
 occur. We do not know how widely support of session timer is
... ...
@@ -82,13 +85,45 @@ effort for session-timer will result in some changes and when
82 85
 it will complete. Nevertheless, we think it is worth trying.
83 86
 Its appeal is it leaves call-termination, a call-stateful
84 87
 feature, down in the end-devices and does not pose too big
85
-burden on server developers and especially operators.
88
+burden on server developers and especially operators. The
89
+scenario is mentioned in [ccframework], section 7.2.12.
86 90
 
87 91
 WE THUS ENCOURAGE VOLUNTEERS TO EXPERIMENT WITH THIS OPTION.
88 92
 TAKE THE GATEWAY YOU HAVE, LOOK AT IT IF IT SUPPORTS ST,
89 93
 ADD ST TO SER PROXY AND CHECK IF THINGS WORK.
90 94
 
91
-
95
+If end-devices do not make the job of call cut-off well, someone
96
+else, a third-party, will have to. That is where B2BUA comes
97
+in. It is a singaling entity that terminates signaling dialog
98
+with both call parties and keeps dialog state during the whole
99
+conversation time. Acting as a UA allows it to generate SIP
100
+messages on its own (as opposed to just realying someone 
101
+else's messages, as proxy do). Because it appears as a simple
102
+UA to each party in the call, it works with any phone without
103
+need for support for any extensions. Problems with use of
104
+B2BUA are described in the next section.
105
+
106
+One could perhaps make the cut-off component easier to
107
+implement than a whole B2BUA. Well, as long as the implementation
108
+is expected to be 100% conform, there is no way around it.
109
+The BYE initiator needs to be aware of current dialog state,
110
+it will not be able to do its job otherwise. Obvisouly,
111
+it needs to remember initial constant information such as
112
+call-id. However, it needs to keep information that changes
113
+too. Particularly, it must know current CSeq -- Cseq gets
114
+updated with in-dialog transactions and failure to send
115
+a proper CSeq would result in denied BYE. An implementer
116
+wishing to make his life easier and avoid the B2BUA
117
+machinery could feel tempted just to "spoof" dialog state
118
+in a proxy, (i.e., not to translate one into another one) and
119
+if it decides to cut-off, send a BYE using the current
120
+status. That introduced race conditions, however, as
121
+another transaction may show up in middle of the cut-off
122
+process, increase remote party's CSeq and disqualify the
123
+delayed cut-off BYE.
124
+
125
+So design choices are either B2BUA, or a "dialog spoofer"
126
+with a risk of race conditions.
92 127
 
93 128
 2. What Are B2BUA limitations?
94 129
 ------------------------------
... ...
@@ -112,7 +147,9 @@ c) e2e security does not work -- implementations willing to
112 147
    SIP message bodies. B2BUA breaks the e2e security if
113 148
    it needs to change the body.
114 149
 d) economical aspects: it is simply yet another piece of
115
-   software you need to purchase or develop
150
+   non-trivial software you need to purchase or develop and
151
+   operate. that's maybe the strongest argument: it is
152
+   expensive.
116 153
 
117 154
 Lot of this conversation has taken place on IETF SIP
118 155
 and SIPPING mailing lists. Few messages from these
... ...
@@ -122,138 +159,24 @@ discussions are referred from
122 159
 3. How to Implement a B2BUA Using ser
123 160
 -------------------------------------
124 161
 
162
+One of the design decisions is whether to make B2BUA work
163
+as a module or an external application bound to ser via some
164
+of its interfaces. 
125 165
 
166
+You will have to keep dialog table keyed by callid and tags,
167
+update it on INVITE complition, remove on BYE, updated on
168
+e.g. INFO changing dialog state.
126 169
 
127
-At 10:00 AM 1/6/2003, chang hui wrote:
128
->Jiri,
129
->
130
->Thanks for your explanation, and let me know the architecture drawback of the B2BUA.
131
-
132
-
133
-I've already done so in my previous email. If something was not clear
134
-enough, let me know.
135
-
136
-
137
->Since we have no way to choose other means to implement pre-paid, we have to go along with B2BUA in a short term.
138
->Could you give me any advise how to implement B2BUA based on SER and estimate the work we should do?
139
->Could you give me a performance estimate?
140
-
141
-
142
-A hand-waving guestimate is performance degrades by 50%.
143
-(We currently achieve up to 3-5 kCPS on a PC -- fair capacity
144
- to slice off from.).
145
-
146
-
147
-a B2BUA does a lot of things:
148
-- first, it keeps dialog state -- it rememembers cseq,  callid, 
149
-  route set, etc. for the whole time of a call (i.e., it eats 
150
-  memory). All this information is needed when you later wish 
151
-  to initiate correct BYEs.
152
-- it translates UAC to UAS transactions and vice versa
153
-- you probably want to save the dialog state on some persistence
154
-  storage (mysql) -- signaling would not work on reboot otherwise
155
-
156
-
157
-That would take quite some development work. I think the amount
158
-of work can be somewhat lowered if normal (record-routed) proxy 
159
-processing is used, as opposed to a full B2BUA which terminats
160
-all UAS transactions and translates them to UAC transactions.
161
-You then still need to do the following:
162
-- keeping a dialog table (keyed by callid and local/remote tags)
163
-- updating the dialog table (new items on INVITE completion, remove 
164
-  dialogs on BYE, update dialog state, such as CSeq, on any other 
165
-  request).
166
-- starting a timer on beginning of a dialog that -- when expired,
167
-  subject to balance and charging plans --  sends BYEs to all call  
168
-  parties using dialog context.
169
-
170
-
171
-That could be implemented as a new ser module, which registers
172
-TM-module callbacks to be updated on transactions completions.
173
-One could also move the dialog maintenance out of ser to some
174
-shell scripts to make programming easier. That would however
175
-very likely degrade performance noticeably.
176
-
170
+The cut-off timer needs to be started too.
177 171
 
178 172
 Also note, that these scenarios are based only on signaling -- there
179 173
 are no PSTN-prepaid-style anouncement "you can call 5 minutes"
180 174
 and "your call will be cut off in 20 seconds". It is doable too,
181
-but it is probably more meaningful to start with the signaling
182
-part.
183
-
184
-
185
--Jiri
175
+but it is probably more meaningful to start with the signaling.
176
+See [tmemo_media] for more on that.
186 177
 
178
+Appendix: References
179
+--------------------
180
+[ccframework] http://www.iptel.org/ietf/callprocessing/#draft-ietf-sipping-cc-framework
187 181
 
188 182
 
189
->Best Regards and Thanks.
190
->
191
->
192
->Chang Hui
193
->-----Original Message-----
194
->From: Jiri Kuthan [mailto:jiri@iptel.org]
195
->Sent: Saturday, January 04, 2003 8:29 PM
196
->To: chang hui; serusers@iptel.org
197
->Subject: RE: [Serusers] About B2BUA
198
->
199
->Hello,
200
->
201
->I see -- prepaid scenarios are indeed difficult without a B2BUA.
202
->There has been a proposal few times to use session timer (a proxy
203
->looks at ballance and attaches a hint to SIP requests indicating
204
->when a call should terminate), but the work has not been pursued.
205
->
206
->You may find a discussion of B2BUA architectural drawbacks on the
207
->SIP mailing list, selected postings are at http://www.iptel.org/info/trends/#b2bua.
208
->imho, the most compelling issue is that of robustness and scalability.
209
->A b2bua needs to keep track of all current calls. A broken b2bua affects
210
->signaling for all existing calls.
211
->
212
->Basically, a B2BUA is simply two UAs glued together. It accepts
213
->transactions as a server, and initiates client transactions
214
->based on them. It keeps dialog state (callid, cseqs, etc.) and
215
->may initiate in-dialog transactions on its own (like the BYE
216
->transaction in which you are interested).
217
->
218
->It is doable to implement a B2BUA on top of ser, but it would
219
->cost quite some development effort. Particularly, it would take
220
->dialog maintenance (better with persistency so that signaling
221
->does not get broken on reboot). We  can provide guidanance to
222
->volunteers willing to go through this exercise.
223
->
224
->-Jiri
225
->
226
->At 02:28 AM 1/4/2003, chang hui wrote:
227
->>Jiri,
228
->>
229
->>Thanks for your prompt response.
230
->>We want to implement a pre-paid system in which once subscriber's balance is depleted, the dialog could be torn in time. However other Proxy or other elements could not take part in the call, they could not send a BYE to caller directly. It's the why we consider B2BUA.
231
->>We project to build a B2BUA to support voice/video/IM at first stage, and support other SIP based services as they emerged.
232
->>However, I just noticed the definition of B2BUA in 2543-bis04 in several sentences,  there has no other analysis on performance, reliability, limitations and how to implement it. So, I hope to get help from the society.
233
->>Thanks for your help again.
234
->>
235
->>Koalas
236
->>
237
->>-----Original Message-----
238
->>From: Jiri Kuthan [mailto:jiri@iptel.org]
239
->>Sent: Friday, January 03, 2003 11:06 PM
240
->>To: chang hui; serusers@iptel.org
241
->>Subject: Re: [Serusers] About B2BUA
242
->>
243
->>Hello,
244
->>
245
->>ser is not a B2BUA -- it can act as proxy, redirect, transactional UAS
246
->>or registrar. These modes make a vast majority of network scenarios
247
->>happy without a need to use a B2BUA. Which is good, because B2BUAs
248
->>inherently have certain scalability, reliability and security limitations.
249
->>
250
->>Is there a particular reason why you would like to use a B2BUA?
251
->>
252
->>-Jiri
253
->>
254
->>At 08:00 AM 1/3/2003, chang hui wrote:
255
->>>Hi All,
256
->>>
257
->>>I am newbie of this field, thanks everyone help me.
258
->>>I am interesting in B2BUA, however, except some brief defination in 3261, I could not find any further defination or how to implement about B2BUA, I noticed that SER could be implemented as a B2BUA, where can I find some implementation? or where can I get any description?
259
->>>
... ...
@@ -16,7 +16,8 @@ media server is to bind voice to SIP applications with optional
16 16
 support of other tools (SIP SUB/NOT, mysql, TTS, etc.) It has
17 17
 to be configurable in such a way it can act in different component
18 18
 roles: click-to-dial server, voicemail server, conferencing server, 
19
-text-to-speech anouncement server, etc.
19
+text-to-speech anouncement server, etc. (see [ccframework] for
20
+a longer listing of related applications)
20 21
 
21 22
 TOC
22 23
 ---
... ...
@@ -31,6 +32,11 @@ SIP components without a need for a B2BUA, a technology we consider
31 32
 suboptimal.  (This network architecture puts only very little addition
32 33
 requirements on the media server.)
33 34
 
35
+Note that this section tends to focus on specific design choices.
36
+A nice review of the whole spolution space for composing services
37
+is provided by Mahy at al in [ccframework]. This document is 
38
+referred to many times throughout this memo -- it is a really
39
+nice piece of work. 
34 40
 
35 41
 Section 2, Media Server Requirements, explains basic requirements
36 42
 a media server needs to fulful to make a good job in the component
... ...
@@ -40,8 +46,6 @@ script, are explained in section 3.
40 46
 Related work, references and example scripts are attached in
41 47
 appendices.
42 48
 
43
-
44
-
45 49
 1) Targeted Scenarios and Component Model
46 50
 --------------------------------------
47 51
 Many application scenarios can provide a pleasant experience to users 
... ...
@@ -71,15 +75,17 @@ On success, the controller can then hand-off the call to a PSTN gateway.
71 75
 This architecture is extremelly good in that it introduces distributed 
72 76
 components. Decomposition, an imporant design principle, is performed 
73 77
 in a fair, peer-2-peer manner that allows linking SIP devices in
74
-a very flexible way.
78
+a very flexible way. No additional mechanisms (except perhaps HTTP
79
+reporting) like CTI are needed -- SIP is the service glue.
75 80
 
76 81
 The biggest shortcoming of this architecture is imho its central piece, 
77 82
 the controller. It is simply too central. A B2BUA design  inherently causes 
78 83
 many concerns: security, scalability, and reliability ones. B2BUA solutions 
79 84
 proposed in 3pcc draft [3pcc] by Rosenberg have several signaling drawbacks 
80 85
 too: tricky media matching (flow III), backwards compatibility
81
-(flow IV), etc. There is also the economical aspect: a B2BUA
82
-costs money or development effort.
86
+(flow IV), etc. There is also the economical aspect, which is possibly
87
+the biggest one: a B2BUA costs money or development effort, and the
88
+aforementioned issues cost more operational overhead too.
83 89
 
84 90
 We believe it is beneficial to avoid such B2BUA constructs. The mechanism
85 91
 we are advocating is distributing the service state machine accross 
... ...
@@ -128,7 +134,8 @@ eliminates a need for the "HTTP reporting hack" in jdr's architecture.
128 134
 Session status is reported in SIP URIs. Cooperating components just 
129 135
 need to agree on a scheme for URI usage. That should be easy for SIP 
130 136
 servers as URI processing is a primary SIP ability.
131
-(A similar proposal for such use of URIs was stated in [msuri].)
137
+(A similar proposal for such use of URIs was stated in [msuri]
138
+ and [ccframework].)
132 139
 
133 140
 A simple application of this more distributed approach is REFER-based 
134 141
 "click-to-dial" service. In this scenario, a media component gets somehow 
... ...
@@ -141,10 +148,26 @@ The "pre-paid verification component" referred to in this section is another
141 148
 example use of this model. It establishes a call with caller, looks at 
142 149
 desired destination, processes PIN in media stream, and makes a decision 
143 150
 to hand-over to a gateway. It than disappears from the conversation.
151
+(See the [b2bua] tmemo for how to implement call cut-off, a feature
152
+ esential to operation of prepaid scenarios. the memo explains how
153
+ to achieve cut-off without a B2BUA.)
144 154
 
145 155
 Note that the application call-control framework [ccframework] by Mahy et al. 
146 156
 explicitely mentions a more peer-2-peer oriented approach based on REFER as 
147
-a good alternative to a centralized B2BUA approach. 
157
+a good alternative to a centralized B2BUA approach and gives some more
158
+details.
159
+
160
+  Quicknote: this multi-stage conversation model based on REFER use has
161
+  some appeals for charging too -- in case separate stages need to be
162
+  charged in a different manner (like initial anouncement "this
163
+  800 number is free only from US" for free, and then the real
164
+  IVR for whatever charges apply). It clearly separates these
165
+  stages in terms of calls and transactions. We think that is a clean
166
+  way of doing things as opposed to breaking transaction model
167
+  by some 18x provisional "half-talk"  constructs. (Which raise
168
+  unclarity like "is the call established or not", "how long does
169
+  a proxy server need to keep provisional transactional state",
170
+  "when should I charge for 18x", and whatsoever.)
148 171
 
149 172
 
150 173
 
... ...
@@ -181,6 +204,11 @@ speech software  [cmuspeech] (!!!) including Sphinx, festvox,
181 204
 openvxi are examples of other pieces of work worth intergrating
182 205
 with.
183 206
 
207
+Another important example of what should be achievable with
208
+the externsibility framework is updating SUB/NOT state. Whatever
209
+the udpate mechanism is, it must be doable to allow things such as 
210
+message waiting indication [mwi].
211
+
184 212
 3) On Scripting Language
185 213
 ---------------------
186 214
 
... ...
@@ -200,8 +228,9 @@ abstraction and simplicity are the key for application programming.
200 228
 
201 229
 The primary living space of the media server programming language
202 230
 should be calls. Scripts should be able to deal with calls:
203
-initiate, terminate and transfer them. ([ccframework] coins
204
-"replace", "join", "fork").
231
+initiate, terminate and transfer them. [ccframework] coins
232
+additional ones: "replace", "join", "fork". It also well explains
233
+how to compose some well-known services using these features.
205 234
 
206 235
 An important lower-level escape way should be the ability to initiate
207 236
 in-call (in-dialogue) transaction. That is what allows the server
... ...
@@ -223,29 +252,93 @@ The sources include but are not limited to SIP messsages, timers
223 252
 recording), external events from local apps (perhaps via FIFO), 
224 253
 media events (DTMF), SIP notifications.
225 254
 
226
-There was a proposal too, to introduce notion of SUB/NOT and presence
227
-to the language. Examples of use are "initiate a conference call when all 
228
-invited  users are on-line", "repeat a call when called party is
229
-no longer busy" [dialogpackage], "query participant list in a multi-party
230
-conversation", etc. We haven't discussed yet whether, and if so
231
-how such scenarios should be reflected in the language.
255
+The SIP notifications should be easy to map to the the event
256
+system. Scripts can subscribe to event, and when they occur,
257
+SIP NOTIFIes are translates to the script's event system.
258
+It can be used for implementing things such as "retry
259
+when a user is no longer busy" [dialogpackage], or keep
260
+updated on list of participants in a conversation.
261
+
262
+I think a great simplification of event processing is to guarantee their 
263
+processing in series. It avoids all sorts of nasty issues which pop up 
264
+when events related to a call are processed in parallel. The synchronization 
265
+issues will reduce to event queue maintenance and execution logic will be 
266
+easier to understand. I think we can happily trade it for some - probably 
267
+marginal - performance decrease.
268
+
269
+That would imply an event queue associated with each call. Its filled in from 
270
+all sort of event sources (Web, FIFO, media, timers, etc.). Events are picked 
271
+up from the queue in order of arrival. On call termination, the queue is 
272
+destroyed, empty or not.
273
+
274
+A question is how to deal with some long jobs -- such as recording or playing
275
+media. Waiting until they complete may take infinitely, and result in blocking
276
+such event like incoming BYE, which should actually stop a recording.
277
+
278
+I suggest that well-known long jobs, such as playing or recording
279
+are simply sent to background and then script processing continues.
280
+The question is what qualifies as "long job" -- I think quite few
281
+things which may potentially take infinite time. Recording and playing
282
+are important examples, call set-up (time until callee answers) or
283
+NOTIFY during call transfer other ones. When such background
284
+"infinite" jobs complete, user can be notified via the event system.
285
+
286
+  An alternative would be to introduce a background operator
287
+  like & in shells. However I suspect that unwise users could
288
+  forget to use it and cause infinite blocks. Defining in a 
289
+  case-by-case way that certain operations are blocking seems
290
+  safer to me.
291
+
292
+
293
+Most other jobs are transaction-related and are short enough,
294
+so that processing of other events can wait until they complete.
295
+BYE/REFERR, whateverver, takes in the worst case of an error
296
+time until final response timer hits -- delay which should be 
297
+tolerable to any other signaling. If I for example initate
298
+an INFO transaction and BYE arrives in the meantime, it is
299
+imho not so bad to let the BYE wait until INFO completes.
300
+
232 301
 
233 302
 requriement summary)
234 303
 
235 304
 So far, we have identified the following requirements:
236
-    - programming effectivity (easy and intutitive to use)
305
+    - programming effectivity (easy and intutitive to use); abstraction
306
+	  from protocol details, focusing on calls and primitives about
307
+	  them (initiate, terminate, transfer, perhaps join, fork
308
+	  and replace too); some simple in-dialog transaction processing
309
+	  should be an escape for other signaling things
237 310
     - parallelism (mutltiple scripts processed at the same time, 
238 311
       multiple calls refered from a single script)     
239 312
     - variables (refering to multiple calls)
240
-    - event processing
313
+    - event processing -- ability to map a variety of events
314
+	  to the event system (SIP NOTIFIes, FIFO requests, 
315
+	  call-related SIP requests such as INVITE/BYE, timers,
316
+	  media events, etc.); events processed in series
317
+    - services described in [ccframework] should be verified
318
+      to be doable with the language
241 319
     - ability to change script without rebooting the server
320
+	- uri processing is an absolute must to be able to implement
321
+	  the component model as described above
322
+	- textual processing -- one should be able to compose new
323
+	  transactions out of parts of existing requests (there should 
324
+	  be some automated request->var casting, e.g., $Request.from) and
325
+	  dialog state. 
326
+           ret=$call.new_transaction("INFO", 
327
+               "headerfield: value\n\hf2: ".$Request.from."\n", "two USD");
242 328
     - extensibility (i.e., the ability of the environment to link 
243
-      external binary libs and refer to them from scripts)
329
+      external binary libs and refer to them from scripts); particular
330
+      items of interest are mysql support, http support, tts,
331
+	  support for updating SUB/NOT status (such as for [mwi])
244 332
 
245 333
 Some design options mentioned so far (nice but not required)
246 334
     - have some casting from input to variables (e.g, $request.header.callid)
247 335
     - use OO -- there are many people for whom OO is easier
248 336
     - exceptions to group error processing
337
+	- variable scope and context -- it would be imho nice if
338
+	  all variables related to a call would be tightened to
339
+	  it, so that they are accessible whenever another
340
+	  call-related event occurs, and they are not accessible
341
+	  from anywhere else
249 342
 
250 343
 main-loop language)
251 344
 
... ...
@@ -263,16 +356,23 @@ the scripting languages with code libraries. Other cons are
263 356
 bigger image size and dependency on third-party software.
264 357
 However, risks of bugs and unability to tweak things are rather 
265 358
 low with well-established open-source software like python.
266
-Possibly, syntax of an own language might better capture
267
-semantics of the media server.
268 359
 
269
-As said, no determination has been made yet. Author of this
270
-memo is little a bit uncomfortable with current amount of
271
-development work put on ser team and hopes that use of an
272
-off-the-shelve language would save work cycles. (Hopefuly,
273
-this hope will not be broken by tremendous effort spent
274
-in integration with supporting libraries.)
360
+Also, a new language would have the benefit of making the
361
+syntax more visibly tied to the semantics model.
275 362
 
363
+As said, no determination has been made yet. Author of this
364
+memo changes his opinion on this issue in hourly intervals.
365
+The amount of work to be done with a new language is
366
+scaring and may become an overkill. On the other hand
367
+making sure that the language well expresses the
368
+nature of the server is appealing. Perhaps one could
369
+reuse some API for linking external libraries like 
370
+those used in PHP or python, so than getting access to
371
+the libraries would be easy.
372
+
373
+BEFORE ANY DECISION IS MADE, WE SHOULD BEST GO THROUGH
374
+FEW MORE EXAMPLES ([ccframework]) AND SHOW HOW THEY CAN
375
+BE ACHIEVED USING THE DESIGNED ENVIRONMENT.
276 376
 
277 377
 see more )
278 378
 
... ...
@@ -307,6 +407,7 @@ B) References
307 407
 [festival] http://www.cstr.ed.ac.uk/projects/festival
308 408
 [mscml] http://www.iptel.org/ietf/callprocessing/apps/#draft-vandyke-mscml
309 409
 [msuri] http://www.iptel.org/info/players/ietf/allsipdir/draft-burger-sipping-msuri-01.txt
410
+[mwi] http://www.iptel.org/info/players/ietf/callprocessing/#draft-ietf-sipping-mwi
310 411
 [kpml] http://www.iptel.org/ietf/callprocessing/apps/#draft-burger-sipping-kpml
311 412
 [nv] http://www.naturalvoices.att.com/
312 413
 [refer] http://www.iptel.org/ietf/callprocessing/refer/#draft-ietf-sip-refer