aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/doc/src/diameter_codec.xml
blob: 4a77d5435b061bf382f035daf3c99d405172b7b6 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
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
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
<?xml version="1.0" encoding="latin1" ?>
<!DOCTYPE erlref SYSTEM "erlref.dtd" [
  <!ENTITY records
  '<seealso marker="diameter_dict#MESSAGE_RECORDS">diameter_dict(4)</seealso>'>
  <!ENTITY types
  '<seealso marker="diameter_dict#DATA_TYPES">diameter_dict(4)</seealso>'>
  <!ENTITY % also SYSTEM "seealso.ent" >
  <!ENTITY % here SYSTEM "seehere.ent" >
  %also;
  %here;
]>

<erlref>
<header>
<copyright>
<year>2012</year>
<holder>Ericsson AB. All Rights Reserved.</holder>
</copyright>
<legalnotice>
The contents of this file are subject to the Erlang Public License,
Version 1.1, (the "License"); you may not use this file except in
compliance with the License. You should have received a copy of the
Erlang Public License along with this software. If not, it can be
retrieved online at http://www.erlang.org/.

Software distributed under the License is distributed on an "AS IS"
basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
the License for the specific language governing rights and limitations
under the License.

</legalnotice>

<title>diameter_codec(3)</title>
<prepared>Anders Svensson</prepared>
<responsible></responsible>
<docno></docno>
<approved></approved>
<checked></checked>
<date></date>
<rev></rev>
<file>diameter_codec.xml</file>
</header>

<module>diameter_codec</module>
<modulesummary>Decode and encode of Diameter messages.</modulesummary>

<description>

<p>
Incoming Diameter messages are decoded from binary() before being
communicated to &man_app; callbacks.
Similarly, outgoing Diameter messages are encoded into binary() before
being passed to the appropriate &man_transport; module for
transmission.
The functions in this module implement this encode/decode.</p>

<note>
<p>
Calls to this module are made by diameter itself as a consequence of
configuration passed to &mod_start_service;.
The encode/decode functions may also be useful for other purposes (eg.
test) but the diameter user does not need to call them explicitly when
sending and receiving messages using &mod_call; and the callback
interface documented in &man_app;.</p>
</note>

<p>
The &header; and &packet; records below
are defined in diameter.hrl, which can be included as follows.</p>

<pre>
-include_lib("diameter/include/diameter.hrl").
</pre>

<p>
Application-specific records are definied in the hrl
files resulting from dictionary file compilation.</p>

</description>

<!-- ===================================================================== -->

<section>
<title>DATA TYPES</title>

<p></p>

<taglist>

<marker id="integers"/>

<tag><c>uint8()&nbsp; = 0..255</c></tag>
<tag><c>uint24() = 0..16777215</c></tag>
<tag><c>uint32() = 0..4294967295</c></tag>
<item>
<p>
8-bit, 24-bit and 32-bit integers occurring in Diameter and AVP
headers.</p>
</item>

<marker id="avp"/>

<tag><c>avp() = #diameter_avp{}</c></tag>
<item>
<p>
The application-neutral representation of an AVP.
Primarily intended for use by relay applications that need to handle
arbitrary Diameter applications.
A service implementing a specific Diameter application
(for which it configures a dictionary) can manipulate values of type
&message; instead.</p>

<p>
Fields have the following types.</p>

<taglist>

<tag><c>code = uint32()</c></tag>
<tag><c>is_mandatory = boolean()</c></tag>
<tag><c>need_encryption = boolean()</c></tag>
<tag><c>vendor_id = uint32() | undefined</c></tag>
<item>
<p>
Values in the AVP header, corresponding to AVP Code, the M flag, P
flags and Vendor-ID respectivelty.
A Vendor-ID other than <c>undefined</c> implies a set V flag.</p>
</item>

<tag><c>data = iolist()</c></tag>
<item>
<p>
The data bytes of the AVP.</p>
</item>

<tag><c>name = atom()</c></tag>
<item>
<p>
The name of the AVP as defined in the dictionary file in question, or
<c>undefined</c> if the AVP is unknown to the dictionary file in
question.</p>
</item>

<tag><c>value = term()</c></tag>
<item>
<p>
The decoded value of an AVP.
Will be <c>undefined</c> on decode if the data bytes could
not be decoded or the AVP is unknown.
The type of a decoded value is as document in &types;.</p>
</item>

<tag><c>type = atom()</c></tag>
<item>
<p>
The type of the AVP as specified in the dictionary file in question
(or one it inherits).
Possible types are <c>undefined</c> and the Diameter types:
<c>OctetString</c>, <c>Integer32</c>, <c>Integer64</c>,
<c>Unsigned32</c>, <c>Unsigned64</c>, <c>Float32</c>, <c>Float64</c>,
<c>Grouped</c>, <c>Enumerated</c>, <c>Address</c>, <c>Time</c>,
<c>UTF8String</c>, <c>DiameterIdentity</c>, <c>DiameterURI</c>,
<c>IPFilterRule</c> and <c>QoSFilterRule</c>.</p>
</item>

</taglist>

</item>

<marker id="dictionary"/>

<tag><c>dictionary() = module()</c></tag>
<item>

<p>
The name of a generated dictionary module as generated by &man_compile;
or &make_codec;.
The interface provided by a dictionary module is an
implementation detail that may change.</p>
</item>

<marker id="header"/>

<tag><c>header() = #diameter_header{}</c></tag>
<item>
<p>
The record representation of the Diameter header.
Values in a &packet; returned by &decode; are as extracted from the
incoming message.
Values set in an &packet; passed to &encode; are preserved in the
encoded binary(), with the exception of <c>length</c>, <c>cmd_code</c>
and <c>application_id</c>, all of which are determined by the
&dictionary; in question.</p>

<note>
<p>
It is not necessary to set header fields explicitly in outgoing
messages as diameter itself will set appropriate values.
Setting inappropriate values can be useful for test purposes.</p>
</note>

<p>
Fields have the following types.</p>

<taglist>

<tag><c>version = uint8()</c></tag>
<tag><c>length = uint24()</c></tag>
<tag><c>cmd_code = uint24()</c></tag>
<tag><c>application_id = uint32()</c></tag>
<tag><c>hop_by_hop_id = uint32()</c></tag>
<tag><c>end_to_end_id = uint32()</c></tag>
<item>
<p>
Values of the Version, Message Length, Command-Code, Application-ID,
Hop-by-Hop Identifier and End-to-End Identifier fields of the Diameter
header.</p>
</item>

<tag><c>is_request = boolean()</c></tag>
<tag><c>is_proxiable = boolean()</c></tag>
<tag><c>is_error = boolean()</c></tag>
<tag><c>is_retransmitted = boolean()</c></tag>
<item>
<p>
Values correspoding to the R(equest), P(roxiable), E(rror)
and T(Potentially re-transmitted message) flags of the Diameter
header.</p>
</item>

</taglist>

</item>

<marker id="message"/>

<tag><c>message() = record() | list()</c></tag>
<item>
<p>
The representation of a Diameter message as passed to
&mod_call; or returned from a &app_handle_request; callback.
The record representation is as outlined in &records;:
a message as defined in a dictionary file is encoded as a record with
one field for each component AVP.
Equivalently, a message can also be encoded as a list whose head is
the atom-valued message name (as specified in the relevant dictionary
file) and whose tail is a list of <c>{AvpName, AvpValue}</c> pairs.</p>

<p>
Another list-valued representation allows a message to be specified
as a list whose head is a &header; and whose tail is an &avp; list.
This representation is used by diameter itself when relaying requests
as directed by the return value of a &app_handle_request; callback.
It differs from the other other two in that it bypasses the checks for
messages that do not agree with their definitions in the dictionary in
question: messages are sent exactly as specified.</p>

</item>

<marker id="packet"/>

<tag><c>packet() = #diameter_packet{}</c></tag>
<item>
<p>
A container for incoming and outgoing Diameter messages.
Fields have the following types.</p>

<taglist>

<tag><c>header = &header; | undefined</c></tag>
<item>
<p>
The Diameter header of the message.
Can be (and typically should be) <c>undefined</c> for an outgoing
message in a non-relay application, in which case diameter provides
appropriate values.</p>
</item>

<tag><c>avps = [&avp;] | undefined</c></tag>
<item>
<p>
The AVPs of the message.
Ignored for an outgoing message if the <c>msg</c> field is set to a
value other than <c>undefined</c>.</p>
</item>

<tag><c>msg = &message; | undefined</c></tag>
<item>
<p>
The incoming/outgoing message.
For an incoming message, a record if the message can be
decoded in a non-relay application, <c>undefined</c> otherwise.
For an outgoing message, setting a <c>[&header; | &avp;]</c> list is
equivalent to setting the <c>header</c> and <c>avps</c> fields to the
corresponding values.</p>

<warning>
<p>
A record-valued <c>msg</c> field does <b>not</b> imply an absence of
decode errors.
The <c>errors</c> field should also be examined.</p>
</warning>

</item>

<tag><c>bin = binary()</c></tag>
<item>
<p>
The incoming message prior to encode or the outgoing message after
encode.</p>
</item>

<tag><c>errors = [5000..5999 | {5000..5999, avp()}]</c></tag>
<item>
<p>
Errors detected at decode of an incoming message, as identified by
a corresponding 5xxx series Result-Code (Permanent Failures).
For an incoming request, these should be used to formulate an
appropriate answer as documented for the &app_handle_request;
callback in &man_app;.
For an incoming answer, the &mod_application_opt;
<c>answer_errors</c> determines the behaviour.</p>
</item>

<tag><c>transport_data = term()</c></tag>
<item>
<p>
An arbitrary term of meaning only to the transport process in
question, as documented in &man_transport;.</p>
</item>

</taglist>

</item>

</taglist>

</section>

<!-- ===================================================================== -->

<funcs>

<func>
<name>decode(Mod, Bin) -> Pkt</name>
<fsummary>Decode a Diameter message.</fsummary>
<type>
<v>Mod = &dictionary;</v>
<v>Bin = binary()</v>
<v>Pkt = &packet;</v>
</type>
<desc>

<p>
Decode a Diameter message.</p>

</desc>
</func>

<func>
<name>encode(Mod, Msg) -> Pkt</name>
<fsummary>Encode a Diameter message.</fsummary>
<type>
<v>Mod = &dictionary;</v>
<v>Msg = &message; | &packet;</v>
<v>Pkt = &packet;</v>
</type>
<desc>

<p>
Encode a Diameter message.
</p>

</desc>
</func>

</funcs>

<!-- ===================================================================== -->
<!-- ===================================================================== -->

<section>
<title>SEE ALSO</title>

<p>
&man_compile;, &man_app;, &man_dict;, &man_make;</p>

</section>

</erlref>