aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/doc/src
diff options
context:
space:
mode:
Diffstat (limited to 'lib/diameter/doc/src')
-rw-r--r--lib/diameter/doc/src/diameter.xml34
-rw-r--r--lib/diameter/doc/src/diameter_app.xml39
-rw-r--r--lib/diameter/doc/src/diameter_codec.xml389
-rw-r--r--lib/diameter/doc/src/diameter_compile.xml55
-rw-r--r--lib/diameter/doc/src/diameter_dict.xml85
-rw-r--r--lib/diameter/doc/src/diameter_intro.xml11
-rw-r--r--lib/diameter/doc/src/diameter_make.xml144
-rw-r--r--lib/diameter/doc/src/diameter_sctp.xml27
-rw-r--r--lib/diameter/doc/src/diameter_soc.xml30
-rw-r--r--lib/diameter/doc/src/diameter_tcp.xml46
-rw-r--r--lib/diameter/doc/src/diameter_transport.xml82
-rw-r--r--lib/diameter/doc/src/files.mk2
-rw-r--r--lib/diameter/doc/src/notes.xml161
-rw-r--r--lib/diameter/doc/src/ref_man.xml3
-rw-r--r--lib/diameter/doc/src/seealso.ent28
15 files changed, 942 insertions, 194 deletions
diff --git a/lib/diameter/doc/src/diameter.xml b/lib/diameter/doc/src/diameter.xml
index bc42b75c7a..b7669b760b 100644
--- a/lib/diameter/doc/src/diameter.xml
+++ b/lib/diameter/doc/src/diameter.xml
@@ -1,5 +1,11 @@
<?xml version="1.0" encoding="latin1" ?>
<!DOCTYPE erlref SYSTEM "erlref.dtd" [
+ <!ENTITY make_ref
+ '<seealso marker="erts:erlang#make_ref-0">erlang:make_ref/0</seealso>'>
+ <!ENTITY transport_module
+ '<seealso marker="diameter_transport">transport module</seealso>'>
+ <!ENTITY dictionary
+ '<seealso marker="diameter_dict">dictionary</seealso>'>
<!ENTITY % also SYSTEM "seealso.ent" >
<!ENTITY % here SYSTEM "seehere.ent" >
%also;
@@ -50,7 +56,7 @@ under the License.
<p>
This module provides the interface with which a user can
implement a Diameter node that sends and receives messages using the
-Diameter protocol as defined in RFC 3588.</p>
+Diameter protocol as defined in &the_rfc;.</p>
<p>
Basic usage consists of creating a representation of a
@@ -67,7 +73,7 @@ Beware the difference between <em>diameter</em> (not capitalised) and
<em>Diameter</em> (capitalised).
The former refers to the Erlang application named diameter whose main
api is defined here, the latter to Diameter protocol in the sense of
-RFC 3588.</p>
+&the_rfc;.</p>
<p>
The diameter application must be started before calling most functions
@@ -91,7 +97,7 @@ in this module.</p>
<tag><c>UTF8String()</c></tag>
<item>
<p>
-Types corresponding to RFC 3588 AVP Data Formats.
+Types corresponding to &the_rfc; AVP Data Formats.
Defined in &dict_data_types;.</p>
<marker id="application_alias"/>
@@ -298,7 +304,7 @@ Has one of the following types.</p>
<item>
<p>
An address list is available to the start function of a
-<seealso marker="diameter_transport">transport module</seealso>, which
+&transport_module;, which
can return a new list for use in the subsequent CER or CEA.
Host-IP-Address need not be specified if the transport start function
returns an address list.</p>
@@ -312,7 +318,7 @@ returns an address list.</p>
Origin-State-Id is optional but will be included in outgoing messages
sent by diameter itself: CER/CEA, DWR/DWA and DPR/DPA.
Setting a value of <c>0</c> (zero) is equivalent to not setting a
-value as documented in RFC 3588.
+value as documented in &the_rfc;.
The function &origin_state_id;
can be used as to retrieve a value that is computed when the diameter
application is started.</p>
@@ -464,7 +470,7 @@ that matches no peer.</p>
<p>
The <c>host</c> and <c>realm</c> filters examine the
outgoing request as passed to &call;,
-assuming that this is a record- or list-valued <c>&app_message;</c>,
+assuming that this is a record- or list-valued <c>&codec_message;</c>,
and that the message contains at most one of each AVP.
If this is not the case then the <c>{host|realm, &dict_DiameterIdentity;}</c>
filters must be used to achieve the desired result.
@@ -529,8 +535,7 @@ connectivity.</p>
<p>
Note that a single <c>up</c>/<c>down</c> event for a given peer
-corresponds to one
-<seealso marker="diameter_app#Mod:peer_up-3">peer_up/peer_down</seealso>
+corresponds to one &app_peer_up;/&app_peer_down;
callback for each of the Diameter applications negotiated during
capablilities exchange.
That is, the event communicates connectivity with the
@@ -677,7 +682,7 @@ info fields of forms other than the above.</p>
The name of a service as passed to &start_service; and with which the
service is identified.
There can be at most one service with a given name on a given node.
-Note that <seealso marker="erts:erlang#make_ref-0">erlang:make_ref/0</seealso>
+Note that &make_ref;
can be used to generate a service name that is somewhat unique.</p>
<marker id="service_opt"/>
@@ -703,8 +708,7 @@ For an outgoing Diameter request, the relevant <c>&application_alias;</c> is
passed to &call;, while for an
incoming request the application identifier in the message
header determines the application, the identifier being specified in
-the application's <seealso marker="diameter_dict">dictionary</seealso>
-file.</p>
+the application's &dictionary; file.</p>
</item>
<tag><c>{restrict_connections, false
@@ -749,7 +753,7 @@ as follows.</p>
(H bsl N) bor (Id band ((1 bsl N) - 1))
</pre>
<p>
-Note that RFC 3588 requires that End-to-End identifiers remain unique
+Note that &the_rfc; requires that End-to-End identifiers remain unique
for a period of at least 4 minutes and that this and the call rate
places a lower bound on the appropriate values of <c>N</c>:
at a rate of <c>R</c> requests per second an <c>N</c>-bit counter
@@ -951,7 +955,7 @@ Tc = &dict_Unsigned32;
</pre>
<p>
-For a connecting transport, the RFC 3588 Tc timer, in milliseconds.
+For a connecting transport, the &the_rfc; Tc timer, in milliseconds.
Note that this timer determines the frequency with which a transport
will attempt to establish a connection with its peer only <em>before</em>
an initial connection is established: once there is an initial
@@ -1125,7 +1129,7 @@ its transports.</p>
<type>
<v>SvcName = &service_name;</v>
<v>App = &application_alias;</v>
-<v>Request = &app_message;</v>
+<v>Request = &codec_message;</v>
<v>Answer = term()</v>
<v>Opt = &call_opt;</v>
</type>
@@ -1618,7 +1622,7 @@ Return the list of started services.</p>
Return a value for a Session-Id AVP.</p>
<p>
-The value has the form required by section 8.8 of RFC 3588.
+The value has the form required by section 8.8 of &the_rfc;.
Ident should be the Origin-Host of the peer from which
the message containing the returned value will be sent.</p>
diff --git a/lib/diameter/doc/src/diameter_app.xml b/lib/diameter/doc/src/diameter_app.xml
index 304c69ebda..f4db625c71 100644
--- a/lib/diameter/doc/src/diameter_app.xml
+++ b/lib/diameter/doc/src/diameter_app.xml
@@ -1,5 +1,8 @@
<?xml version="1.0" encoding="latin1" ?>
<!DOCTYPE erlref SYSTEM "erlref.dtd" [
+ <!ENTITY message '<seealso marker="#message">message()</seealso>'>
+ <!ENTITY dict
+ '<seealso marker="diameter_dict#MESSAGE_RECORDS">diameter_dict(4)</seealso>'>
<!ENTITY % also SYSTEM "seealso.ent" >
<!ENTITY % here SYSTEM "seehere.ent" >
%also;
@@ -124,39 +127,17 @@ mandatory values as the bare value.</p>
<marker id="message"/>
-<tag><c>message() = record() | list()</c></tag>
+<tag><c>message() = &codec_message;</c></tag>
<item>
<p>
The representation of a Diameter message as passed to
-&mod_call;.
-The record representation is as outlined in
-<seealso
-marker="diameter_dict#MESSAGE_RECORDS">diameter_dict(4)</seealso>:
-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 (the record name minus any
-prefix specified in the relevant dictionary file) and whose tail is a
-list of <c>{FieldName, FieldValue}</c> pairs.</p>
-
-<p>
-A third representation allows a message to be specified as a list
-whose head is a <c>#diameter_header{}</c> record and whose tail is a list
-of <c>#diameter_avp{}</c> records.
-This representation is used by diameter itself when relaying requests
-as directed by the return value of a
-&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 (since relays agents must handle arbitrary request): messages
-are sent exactly as specified.</p>
+&mod_call; or returned from a &handle_request; callback.</p>
</item>
<marker id="packet"/>
-<tag><c>packet() = #diameter_packet{}</c></tag>
+<tag><c>packet() = &codec_packet;</c></tag>
<item>
<p>
A container for incoming and outgoing Diameter messages that's passed
@@ -505,8 +486,7 @@ The application in which the callback takes place (that is, the
callback module as configured with &mod_start_service;)
is determined by the Application Identifier in the header of the
incoming request message, the selected module being the one
-whose corresponding <seealso
-marker="diameter_dict#MESSAGE_RECORDS">dictionary</seealso> declares
+whose corresponding dictionary declares
itself as defining either the application in question or the Relay
application.</p>
@@ -526,8 +506,7 @@ The argument &packet; has the following signature.</p>
The <c>msg</c> field will be <c>undefined</c> in case the request has
been received in the relay application.
Otherwise it contains the record representing the request as outlined
-in <seealso
-marker="diameter_dict#MESSAGE_RECORDS">diameter_dict(4)</seealso>.</p>
+in &dict;.</p>
<p>
The <c>errors</c> field specifies any Result-Code's identifying errors
@@ -579,7 +558,7 @@ where <c>Avps</c> sets the Origin-Host, Origin-Realm, the specified
Result-Code and (if the request sent one) Session-Id AVP's.</p>
<p>
-Note that RFC 3588 mandates that only answers with a 3xxx series
+Note that &the_rfc; mandates that only answers with a 3xxx series
Result-Code (protocol errors) may set the E bit.
Returning a non-3xxx value in a <c>protocol_error</c> tuple
will cause the request process in question to fail.</p>
diff --git a/lib/diameter/doc/src/diameter_codec.xml b/lib/diameter/doc/src/diameter_codec.xml
new file mode 100644
index 0000000000..4a77d5435b
--- /dev/null
+++ b/lib/diameter/doc/src/diameter_codec.xml
@@ -0,0 +1,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>
diff --git a/lib/diameter/doc/src/diameter_compile.xml b/lib/diameter/doc/src/diameter_compile.xml
index eb6de80c11..0bd7ad1789 100644
--- a/lib/diameter/doc/src/diameter_compile.xml
+++ b/lib/diameter/doc/src/diameter_compile.xml
@@ -1,5 +1,7 @@
<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE comref SYSTEM "comref.dtd" [
+ <!ENTITY dictionary
+ '<seealso marker="diameter_dict">dictionary file</seealso>'>
<!ENTITY % also SYSTEM "seealso.ent" >
<!ENTITY % here SYSTEM "seehere.ent" >
%also;
@@ -36,12 +38,14 @@ supplied.
<description>
<p>
-The diameterc utility is used to compile diameter
-<seealso marker="diameter_dict">dictionary files</seealso>
-into Erlang source.
-The resulting source implements the interface diameter requires
+The diameterc utility is used to compile a diameter
+&dictionary; into Erlang source.
+The resulting source implements the interface diameter required
to encode and decode the dictionary's messages and AVP's.</p>
+<p>
+The module &man_make; provides an alternate compilation interface.</p>
+
</description>
<section>
@@ -52,53 +56,52 @@ to encode and decode the dictionary's messages and AVP's.</p>
<tag><![CDATA[diameterc [<options>] <file>]]></tag>
<item>
<p>
-Compiles a single dictionary file. Valid options are as follows.</p>
-
-<!-- Leave -h/d/v undocumented, except for the usage message from the
- utility itself. -->
-
-<taglist>
-<tag><![CDATA[-o <dir>]]></tag>
-<item>
-<p>
-Specifies the directory into which the generated source should be written.
-Defaults to the current working directory.</p>
-</item>
+Compile a single dictionary file to Erlang source.
+Valid options are as follows.</p>
<tag><![CDATA[-i <dir>]]></tag>
<item>
<p>
-Specifies a directory to add to the code path.
+Prepend the specified directory to the code path.
Use to point at beam files compiled from inherited dictionaries,
-<c>@inherits</c> in a dictionary file creating a beam dependency, not
-an erl/hrl dependency.</p>
+<c>&dict_inherits;</c> in a dictionary file creating a beam
+dependency, not an erl/hrl dependency.</p>
<p>
Multiple <c>-i</c> options can be specified.</p>
</item>
+<taglist>
+<tag><![CDATA[-o <dir>]]></tag>
+<item>
+<p>
+Write generated source to the specified directory.
+Defaults to the current working directory.</p>
+</item>
+
<tag><![CDATA[-E]]></tag>
<tag><![CDATA[-H]]></tag>
<item>
<p>
-Supresses erl and hrl generation, respectively.</p>
+Supress erl and hrl generation, respectively.</p>
</item>
<tag><![CDATA[--name <name>]]></tag>
<tag><![CDATA[--prefix <prefix>]]></tag>
<item>
<p>
-Set <c>@name</c> and <c>@prefix</c> in the dictionary,
-respectively.
+Set <c>&dict_name;</c> or <c>&dict_prefix;</c> to the specified
+string.
Overrides any setting in the file itself.</p>
</item>
<tag><![CDATA[--inherits <dict>]]></tag>
<item>
<p>
-Append an <c>@inherits</c> to the dictionary before compiling.
-Specifying <c>'-'</c> as the dictionary has the effect of clearing any
-previous inherits, causing them to be ignored.</p>
+Append &dict_inherits; of the specified module.
+Specifying <c>"-"</c> has the effect of discarding clearing any
+previous inherits, both in the dictionary file and on the options
+list.</p>
<p>
Multiple <c>--inherits</c> options can be specified.</p>
@@ -127,7 +130,7 @@ Returns 0 on success, non-zero on failure.</p>
<title>SEE ALSO</title>
<p>
-&man_dict;</p>
+&man_make;, &man_dict;</p>
</section>
diff --git a/lib/diameter/doc/src/diameter_dict.xml b/lib/diameter/doc/src/diameter_dict.xml
index 4a6cccc276..8b0687a22e 100644
--- a/lib/diameter/doc/src/diameter_dict.xml
+++ b/lib/diameter/doc/src/diameter_dict.xml
@@ -1,5 +1,11 @@
<?xml version="1.0" encoding="latin1" ?>
<!DOCTYPE erlref SYSTEM "fileref.dtd" [
+ <!ENTITY format
+ '<seealso marker="#FILE_FORMAT">FILE FORMAT</seealso>'>
+ <!ENTITY records
+ '<seealso marker="#MESSAGE_RECORDS">MESSAGE RECORDS</seealso>'>
+ <!ENTITY types
+ '<seealso marker="#DATA_TYPES">DATA TYPES</seealso>'>
<!ENTITY % also SYSTEM "seealso.ent" >
<!ENTITY % here SYSTEM "seehere.ent" >
%also;
@@ -45,34 +51,33 @@ under the License.
<description>
<p>
-A diameter service as configured with &mod_start_service;
+A diameter service, as configured with &mod_start_service;,
specifies one or more supported Diameter applications.
Each Diameter application specifies a dictionary module that knows how
to encode and decode its messages and AVPs.
The dictionary module is in turn generated from a file that defines
these messages and AVPs.
-The format of such a file is defined in
-<seealso marker="#FILE_FORMAT">FILE FORMAT</seealso> below.
+The format of such a file is defined in &format; below.
Users add support for their specific applications by creating
dictionary files, compiling them to Erlang modules using
-<seealso marker="diameterc">diameterc</seealso> and configuring the
+either &man_compile; or &man_make; and configuring the
resulting dictionaries modules on a service.</p>
<p>
-The codec generation also results in a hrl file that defines records
-for the messages and grouped AVPs defined for the application, these
-records being what a user of the diameter application sends and receives.
-(Modulo other available formats as discussed in &man_app;.)
+Dictionary module generation also results in a hrl file that defines
+records for the messages and Grouped AVPs defined by the
+dictionary, these records being what a user of the diameter
+application sends and receives, modulo other possible formats as
+discussed in &man_app;.
These records and the underlying Erlang data types corresponding to
-Diameter data formats are discussed in <seealso
-marker="#MESSAGE_RECORDS">MESSAGE RECORDS</seealso> and <seealso
-marker="#DATA_TYPES">DATA TYPES</seealso> respectively.
-The generated hrl also contains defines for the possible values of
+Diameter data formats are discussed in &records; and &types;
+respectively.
+The generated hrl also contains macro definitions for the possible values of
AVPs of type Enumerated.</p>
<p>
The diameter application includes three dictionary modules
-corresponding to applications defined in section 2.4 of RFC 3588:
+corresponding to applications defined in section 2.4 of &the_rfc;:
<c>diameter_gen_base_rfc3588</c> for the Diameter Common Messages
application with application identifier 0,
<c>diameter_gen_accounting</c> for the Diameter Base Accounting
@@ -111,6 +116,8 @@ The order in which sections are specified is unimportant.</p>
<taglist>
+<marker id="id"/>
+
<tag><c>@id Number</c></tag>
<item>
<p>
@@ -134,6 +141,8 @@ Example:</p>
</item>
+<marker id="name"/>
+
<tag><c>@name Mod</c></tag>
<item>
<p>
@@ -155,6 +164,8 @@ Example:</p>
</item>
+<marker id="prefix"/>
+
<tag><c>@prefix Name</c></tag>
<item>
<p>
@@ -178,6 +189,8 @@ Example:</p>
</item>
+<marker id="vendor"/>
+
<tag><c>@vendor Number Name</c></tag>
<item>
<p>
@@ -198,6 +211,8 @@ Example:</p>
</item>
+<marker id="avp_vendor_id"/>
+
<tag><c>@avp_vendor_id Number</c></tag>
<item>
<p>
@@ -218,6 +233,8 @@ Region-Set
</item>
+<marker id="inherits"/>
+
<tag><c>@inherits Mod</c></tag>
<item>
<p>
@@ -241,7 +258,7 @@ is equivalent to using <c>@avp_vendor_id</c> with a copy of the
dictionary's definitions but the former makes for easier reuse.</p>
<p>
-All dictionaries should typically inherit RFC3588 AVPs from
+All dictionaries should typically inherit &the_rfc; AVPs from
<c>diameter_gen_base_rfc3588</c>.</p>
<p>
@@ -253,6 +270,8 @@ Example:</p>
</item>
+<marker id="avp_types"/>
+
<tag><c>@avp_types</c></tag>
<item>
<p>
@@ -263,7 +282,7 @@ The section consists of definitions of the form</p>
<p>
where Code is the integer AVP code, Type identifies an AVP Data Format
-as defined in <seealso marker="#DATA_TYPES">DATA TYPES</seealso> below,
+as defined in section &types; below,
and Flags is a string of V, M and P characters indicating the flags to be
set on an outgoing AVP or a single <c>'-'</c> (minus) character if
none are to be set.</p>
@@ -280,13 +299,13 @@ Requested-Information 353 Enumerated V
<warning>
<p>
-The P flag has been deprecated by the Diameter Maintenance
-and Extensions Working Group of the IETF and should be omitted
-to conform to the current draft standard.</p>
+The P flag has been deprecated by &the_rfc;.</p>
</warning>
</item>
+<marker id="custom_types"/>
+
<tag><c>@custom_types Mod</c></tag>
<item>
<p>
@@ -308,6 +327,8 @@ Framed-IP-Address
</pre>
</item>
+<marker id="codecs"/>
+
<tag><c>@codecs Mod</c></tag>
<item>
<p>
@@ -325,12 +346,14 @@ Framed-IP-Address
</pre>
</item>
+<marker id="messages"/>
+
<tag><c>@messages</c></tag>
<item>
<p>
Defines the messages of the application.
The section content consists of definitions of the form specified in
-section 3.2 of RFC 3588, "Command Code ABNF specification".</p>
+section 3.2 of &the_rfc;, "Command Code Format Specification".</p>
<!-- RFC 4740 RTR/RTA -->
<pre>
@@ -370,13 +393,15 @@ RTA ::= &lt; Diameter Header: 287, PXY >
</item>
+<marker id="grouped"/>
+
<tag><c>@grouped</c></tag>
<item>
<p>
Defines the contents of the AVPs of the application having type
Grouped.
The section content consists of definitions of the form specified in
-section 4.4 of RFC 3588, "Grouped AVP Values".</p>
+section 4.4 of &the_rfc;, "Grouped AVP Values".</p>
<p>
Example:</p>
@@ -395,6 +420,8 @@ Specifying a Vendor-Id in the definition of a grouped AVP is
equivalent to specifying it with <c>@avp_vendor_id</c>.</p>
</item>
+<marker id="enum"/>
+
<tag><c>@enum Name</c></tag>
<item>
<p>
@@ -421,6 +448,8 @@ REMOVE_SIP_SERVER 3
</pre>
</item>
+<marker id="end"/>
+
<tag><c>@end</c></tag>
<item>
<p>
@@ -447,8 +476,8 @@ The hrl generated from a dictionary specification defines records for the
messages and grouped AVPs defined in <c>@messages</c> and
<c>@grouped</c> sections.
For each message or grouped AVP definition, a record is defined whose
-name is the message or AVP name prefixed with any dictionary prefix
-defined with <c>@prefix</c> and whose fields are the names of the AVPs
+name is the message or AVP name, prefixed with any dictionary prefix
+defined with <c>@prefix</c>, and whose fields are the names of the AVPs
contained in the message or grouped AVP in the order specified in the
definition in question.
For example, the grouped AVP</p>
@@ -476,7 +505,7 @@ type and number of times the AVP can occur.
In particular, an AVP which is specified as occurring exactly once is
encoded as a value of the AVP's type while an AVP with any other
specification is encoded as a list of values of the AVP's type.
-The AVP's type is as specified in the AVP definition, the RFC 3588
+The AVP's type is as specified in the AVP definition, the &the_rfc;
types being described below.</p>
<marker id="DATA_TYPES"/>
@@ -489,7 +518,7 @@ types being described below.</p>
<p>
The data formats defined in sections 4.2 ("Basic AVP Data
-Formats") and 4.3 ("Derived AVP Data Formats") of RFC 3588 are encoded
+Formats") and 4.3 ("Derived AVP Data Formats") of &the_rfc; are encoded
as values of the types defined here.
Values are passed to &mod_call;
in a request record when sending a request, returned in a resulting
@@ -564,8 +593,8 @@ where
<p>
Additionally, values that can be encoded are
-limited by way of their encoding as four octets as required by RFC
-3588 with the required extension from RFC 2030.
+limited by way of their encoding as four octets as required by
+&the_rfc; with the required extension from RFC 2030.
In particular, only values between <c>{{1968,1,20},{3,14,8}}</c>
and <c>{{2104,2,26},{9,42,23}}</c> (both inclusive) can be encoded.</p>
@@ -609,7 +638,7 @@ where
On encode, fields port, transport and protocol default to 3868, sctp
and diameter respectively.
The grammar of an OctetString-valued DiameterURI() is as specified in
-section 4.3 of RFC 3588.
+section 4.3 of &the_rfc;.
The record representation is used on decode.</p>
<marker id="Enumerated"/>
@@ -640,7 +669,7 @@ Values of these types are not currently parsed by diameter.</p>
<title>SEE ALSO</title>
<p>
-&man_compile;, &man_main;, &man_app;</p>
+&man_compile;, &man_main;, &man_app;, &man_codec;, &man_make;</p>
</section>
diff --git a/lib/diameter/doc/src/diameter_intro.xml b/lib/diameter/doc/src/diameter_intro.xml
index bc2afbd453..fd578ccf45 100644
--- a/lib/diameter/doc/src/diameter_intro.xml
+++ b/lib/diameter/doc/src/diameter_intro.xml
@@ -1,5 +1,8 @@
<?xml version="1.0" encoding="latin1" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
+<!DOCTYPE chapter SYSTEM "chapter.dtd" [
+ <!ENTITY % also SYSTEM "seealso.ent">
+ %also;
+]>
<chapter>
<header>
@@ -35,7 +38,7 @@ under the License.
<p>
The diameter application is an implementation of the Diameter protocol
-as defined by RFC 3588.
+as defined by &the_rfc;.
It supports arbitrary Diameter applications by way of a
<em>dictionary</em> interface that allows messages and AVP's to be
defined and input into diameter as configuration.
@@ -86,9 +89,9 @@ dictionary module
that provide encode/decode functionality for outgoing/incoming
Diameter messages belonging to the application.
A dictionary module is generated from a <seealso
-marker="diameter_dict">specification file</seealso> using the <seealso
+marker="diameter_dict">dictionary file</seealso> using the <seealso
marker="diameterc">diameterc</seealso> utility.
-Dictionaries for the RFC 3588 Diameter Common Messages, Base
+Dictionaries for the &the_rfc; Diameter Common Messages, Base
Accounting and Relay applications are provided with the diameter
application.</p>
diff --git a/lib/diameter/doc/src/diameter_make.xml b/lib/diameter/doc/src/diameter_make.xml
new file mode 100644
index 0000000000..da6124310e
--- /dev/null
+++ b/lib/diameter/doc/src/diameter_make.xml
@@ -0,0 +1,144 @@
+<?xml version="1.0" encoding="latin1" ?>
+<!DOCTYPE erlref SYSTEM "erlref.dtd" [
+ <!ENTITY filename
+ '<seealso marker="kernel:file#type-name">file:name()</seealso>'>
+ <!ENTITY dictionary
+ '<seealso marker="diameter_dict">dictionary file</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_make(3)</title>
+<prepared>Anders Svensson</prepared>
+<responsible></responsible>
+<docno></docno>
+<approved></approved>
+<checked></checked>
+<date></date>
+<rev></rev>
+<file>diameter_make.xml</file>
+</header>
+
+<module>diameter_make</module>
+<modulesummary>Diameter dictionary compilation.</modulesummary>
+
+<description>
+
+<p>
+The function &codec; is used to compile a diameter
+&dictionary; into Erlang source.
+The resulting source implements the interface diameter required
+to encode and decode the dictionary's messages and AVP's.</p>
+
+<p>
+The utility &man_compile; provides an alternate compilation
+interface.</p>
+
+</description>
+
+<!-- ===================================================================== -->
+
+<funcs>
+
+<func>
+<name>codec(Path::string(), [Opt]) -> ok | {error, Reason}</name>
+<fsummary>Compile a dictionary file into Erlang source.</fsummary>
+<desc>
+
+<p>
+Compile a single dictionary file to Erlang source.
+<c>Opt</c> can have the following types.</p>
+
+<taglist>
+
+<tag><c>{include, Dir::string()}</c></tag>
+<item>
+<p>
+Prepend the specified directory to the code path.
+Use to point at beam files compiled from inherited dictionaries,
+<c>&dict_inherits;</c> in a dictionary file creating a beam
+dependency, not an erl/hrl dependency.</p>
+
+<p>
+Multiple <c>include</c> options can be specified.</p>
+</item>
+
+<tag><c>{outdir, Dir::string()}</c></tag>
+<item>
+<p>
+Write generated source to the specified directory.
+Defaults to the current working directory.</p>
+</item>
+
+<tag><c>{name|prefix, string()}</c></tag>
+<item>
+<p>
+Set <c>&dict_name;</c> or <c>&dict_prefix;</c> to the specified
+string.
+Overrides any setting in the file itself.</p>
+</item>
+
+<tag><c>{inherits, Mod::string()}</c></tag>
+<item>
+<p>
+Append &dict_inherits; of the specified module.
+Specifying <c>"-"</c> has the effect of discarding clearing any
+previous inherits, both in the dictionary file and on the options
+list.</p>
+
+<p>
+Multiple <c>inherits</c> options can be specified.</p>
+</item>
+
+</taglist>
+
+</desc>
+</func>
+
+</funcs>
+
+<!-- ===================================================================== -->
+
+<section>
+<title>BUGS</title>
+
+<p>
+All options are string-valued.
+In particular, it is not currently possible to
+an &dict_inherits; module as an atom() or a path as a &filename;</p>
+
+</section>
+
+<!-- ===================================================================== -->
+
+<section>
+<title>SEE ALSO</title>
+
+<p>
+&man_compile;, &man_dict;</p>
+
+</section>
+
+</erlref>
diff --git a/lib/diameter/doc/src/diameter_sctp.xml b/lib/diameter/doc/src/diameter_sctp.xml
index a023a9bc08..5e3fd5eaf1 100644
--- a/lib/diameter/doc/src/diameter_sctp.xml
+++ b/lib/diameter/doc/src/diameter_sctp.xml
@@ -1,5 +1,11 @@
<?xml version="1.0" encoding="latin1" ?>
<!DOCTYPE erlref SYSTEM "erlref.dtd" [
+ <!ENTITY gen_sctp '<seealso marker="kernel:gen_sctp">gen_sctp(3)</seealso>'>
+ <!ENTITY gen_sctp_open1
+ '<seealso marker="kernel:gen_sctp#open-1">gen_sctp:open/1</seealso>'>
+ <!ENTITY ip_address
+ '<seealso marker="kernel:inet#type-ip_address">inet:ip_address()</seealso>'>
+ <!ENTITY inet '<seealso marker="kernel:inet">inet(3)</seealso>'>
<!ENTITY % also SYSTEM "seealso.ent" >
<!ENTITY % here SYSTEM "seehere.ent" >
%also;
@@ -43,8 +49,7 @@ under the License.
<description>
<p>
-This module implements diameter transport over SCTP using <seealso
-marker="kernel:gen_sctp">gen_sctp</seealso>.
+This module implements diameter transport over SCTP using &gen_sctp;.
It can be specified as the value of a transport_module option to
&mod_add_transport;
and implements the behaviour documented in
@@ -65,9 +70,9 @@ and implements the behaviour documented in
<v>Type = connect | accept</v>
<v>Ref = &mod_transport_ref;</v>
<v>Svc = #diameter_service{}</v>
-<v>Opt = {raddr, <seealso marker="kernel:inet#type-ip_address">inet:ip_address()</seealso>} | {rport, integer()} | term()</v>
+<v>Opt = {raddr, &ip_address;} | {rport, integer()} | term()</v>
<v>Pid = pid()</v>
-<v>LAddr = <seealso marker="kernel:inet#type-ip_address">inet:ip_address()</seealso></v>
+<v>LAddr = &ip_address;</v>
<v>Reason = term()</v>
</type>
<desc>
@@ -84,8 +89,7 @@ unspecified.
More than one <c>raddr</c> option can be specified, in which case the
connecting transport in question attempts each in sequence until
an association is established.
-Remaining options are any accepted by <seealso
-marker="kernel:gen_sctp#open-1">gen_sctp:open/1</seealso>, with the exception
+Remaining options are any accepted by &gen_sctp_open1;, with the exception
of options <c>mode</c>, <c>binary</c>, <c>list</c>, <c>active</c>
and <c>sctp_events</c>.
Note that options <c>ip</c> and <c>port</c> specify the local address
@@ -102,14 +106,12 @@ connecting transport.</p>
<warning>
<p>
An insufficiently large receive buffer may result in a peer having to
-resend incoming messages: set the <seealso
-marker="kernel:inet">inet(3)</seealso> option <c>recbuf</c> to increase
+resend incoming messages: set the &inet; option <c>recbuf</c> to increase
the buffer size.</p>
<p>
An insufficiently large send buffer may result in outgoing messages
-being discarded: set the <seealso
-marker="kernel:inet">inet(3)</seealso> option <c>sndbuf</c> to increase
+being discarded: set the &inet; option <c>sndbuf</c> to increase
the buffer size.</p>
</warning>
@@ -145,10 +147,7 @@ outbound streams.</p>
<title>SEE ALSO</title>
<p>
-&man_main;,
-&man_transport;,
-<seealso marker="kernel:gen_sctp">gen_sctp(3)</seealso>,
-<seealso marker="kernel:inet">inet(3)</seealso></p>
+&man_main;, &man_transport;, &gen_sctp;, &inet;</p>
</section>
diff --git a/lib/diameter/doc/src/diameter_soc.xml b/lib/diameter/doc/src/diameter_soc.xml
index 6b9ef9f756..16f6b9d5bb 100644
--- a/lib/diameter/doc/src/diameter_soc.xml
+++ b/lib/diameter/doc/src/diameter_soc.xml
@@ -1,11 +1,15 @@
<?xml version="1.0" encoding="latin1" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
+<!DOCTYPE chapter SYSTEM "chapter.dtd" [
+ <!ENTITY % also SYSTEM "seealso.ent" >
+ %also;
+]>
<chapter>
<header>
<copyright>
<year>2011</year>
+<year>2012</year>
<holder>Ericsson AB. All Rights Reserved.</holder>
</copyright>
@@ -41,38 +45,20 @@ Known points of questionable or non-compliance.</p>
<!-- ===================================================================== -->
<section>
-<title>RFC 3588</title>
+<title>&the_rfc;</title>
<list>
<item>
<p>
-The End-to-End Security framework (section 2.9) isn't implemented
-since it is largely unspecified.
-The document that was to describe it
-(reference [AAACMS]) was abandoned in an uncompleted state several
-years ago and the current draft RFC deprecates the framework,
-including the P Flag in the AVP header.</p>
-</item>
-
-<item>
-<p>
-There is no TLS support over SCTP.
-RFC 3588 requires that a Diameter server support TLS but in
-practise this seems to mean TLS over SCTP since there are limitations
-with running over SCTP: see RFC 6083 (DTLS over SCTP), which is a
-response to RFC 3436 (TLS over SCTP).
-The current RFC 3588 draft acknowledges this by equating
-TLS with TLS/TCP and DTLS/SCTP but we do not yet support DTLS.</p>
+There is no support for DTLS over SCTP.</p>
</item>
<item>
<p>
There is no explicit support for peer discovery (section 5.2).
It can possibly be implemented on top of diameter as is but this is
-probably something that diameter should do.
-The current draft deprecates portions of the original RFC's mechanisms
-however.</p>
+probably something that diameter should do.</p>
</item>
<item>
diff --git a/lib/diameter/doc/src/diameter_tcp.xml b/lib/diameter/doc/src/diameter_tcp.xml
index be8a938115..e3b8c733b7 100644
--- a/lib/diameter/doc/src/diameter_tcp.xml
+++ b/lib/diameter/doc/src/diameter_tcp.xml
@@ -1,5 +1,22 @@
<?xml version="1.0" encoding="latin1" ?>
<!DOCTYPE erlref SYSTEM "erlref.dtd" [
+ <!ENTITY gen_tcp_connect3
+ '<seealso marker="kernel:gen_tcp#connect-3">gen_tcp:connect/3</seealso>'>
+ <!ENTITY gen_tcp_listen2
+ '<seealso marker="kernel:gen_tcp#listen-2">gen_tcp:listen/2</seealso>'>
+ <!ENTITY ip_address
+ '<seealso marker="kernel:inet#type-ip_address">inet:ip_address()</seealso>'>
+ <!ENTITY ssl_connect2
+ '<seealso marker="ssl:ssl#connect-2">ssl:connect/2</seealso>'>
+ <!ENTITY ssl_connect3
+ '<seealso marker="ssl:ssl#connect-3">ssl:connect/3</seealso>'>
+ <!ENTITY ssl_accept2
+ '<seealso marker="ssl:ssl#ssl_accept-2">ssl:ssl_accept/2</seealso>'>
+ <!ENTITY ssl_listen2
+ '<seealso marker="ssl:ssl#listen-2">ssl:listen/2</seealso>'>
+ <!ENTITY gen_tcp '<seealso marker="kernel:gen_tcp">gen_tcp(3)</seealso>'>
+ <!ENTITY inet '<seealso marker="kernel:inet">inet(3)</seealso>'>
+ <!ENTITY ssl '<seealso marker="ssl:ssl">ssl(3)</seealso>'>
<!ENTITY % also SYSTEM "seealso.ent" >
<!ENTITY % here SYSTEM "seehere.ent" >
%also;
@@ -43,14 +60,13 @@ under the License.
<description>
<p>
-This module implements diameter transport over TCP using <seealso
-marker="kernel:gen_tcp">gen_tcp</seealso>.
+This module implements diameter transport over TCP using &gen_tcp;.
It can be specified as the value of a <c>transport_module</c> option to
&mod_add_transport;
and implements the behaviour documented in
&man_transport;.
TLS security is supported, both as an upgrade following
-capabilities exchange as specified by RFC 3588 and
+capabilities exchange as specified by &the_rfc; and
at connection establishment as in the current draft standard.</p>
<p>
@@ -74,9 +90,9 @@ before configuring TLS capability on diameter transports.</p>
<v>Svc = #diameter_service{}</v>
<v>Opt = OwnOpt | SslOpt | TcpOpt</v>
<v>Pid = pid()</v>
-<v>LAddr = <seealso marker="kernel:inet#type-ip_address">inet:ip_address()</seealso></v>
+<v>LAddr = &ip_address;</v>
<v>Reason = term()</v>
-<v>OwnOpt = {raddr, <seealso marker="kernel:inet#type-ip_address">inet:ip_address()</seealso>}
+<v>OwnOpt = {raddr, &ip_address;}
| {rport, integer()}
| {port, integer()}</v>
<v>SslOpt = {ssl_options, true | list()}</v>
@@ -95,16 +111,12 @@ transport.
Option <c>ssl_options</c> must be specified for a transport
that should support TLS: a value of <c>true</c> results in a
TLS handshake immediately upon connection establishment while
-<c>list()</c> specifies options to be passed to <seealso
-marker="ssl:ssl#connect-2">ssl:connect/2</seealso> or
-<seealso marker="ssl:ssl#ssl_accept-2">ssl:ssl_accept/2</seealso>
+<c>list()</c> specifies options to be passed to &ssl_connect2; or
+&ssl_accept2;
after capabilities exchange if TLS is negotiated.
-Remaining options are any accepted by <seealso
-marker="ssl:ssl#connect-3">ssl:connect/3</seealso> or <seealso
-marker="kernel:gen_tcp#connect-3">gen_tcp:connect/3</seealso> for
-a connecting transport, or <seealso
-marker="ssl:ssl#listen-2">ssl:listen/2</seealso> or <seealso
-marker="kernel:gen_tcp#listen-2">gen_tcp:listen/2</seealso> for
+Remaining options are any accepted by &ssl_connect3; or
+&gen_tcp_connect3; for
+a connecting transport, or &ssl_listen2; or &gen_tcp_listen2; for
a listening transport, depending on whether or not <c>{ssl_options, true}</c>
has been specified.
Options <c>binary</c>,
@@ -150,11 +162,7 @@ The returned local address list has length one.</p>
<title>SEE ALSO</title>
<p>
-&man_main;,
-&man_transport;,
-<seealso marker="kernel:gen_tcp">gen_tcp(3)</seealso>,
-<seealso marker="kernel:inet">inet(3)</seealso>,
-<seealso marker="ssl:ssl">ssl(3)</seealso></p>
+&man_main;, &man_transport;, &gen_tcp;, &inet;, &ssl;</p>
</section>
diff --git a/lib/diameter/doc/src/diameter_transport.xml b/lib/diameter/doc/src/diameter_transport.xml
index 0507af63a8..55b531155f 100644
--- a/lib/diameter/doc/src/diameter_transport.xml
+++ b/lib/diameter/doc/src/diameter_transport.xml
@@ -1,5 +1,8 @@
<?xml version="1.0" encoding="latin1" ?>
<!DOCTYPE erlref SYSTEM "erlref.dtd" [
+ <!ENTITY message '<seealso marker="#message">message()</seealso>'>
+ <!ENTITY ip_address
+ '<seealso marker="kernel:inet#type-ip_address">inet:ip_address()</seealso>'>
<!ENTITY % also SYSTEM "seealso.ent" >
<!ENTITY % here SYSTEM "seehere.ent" >
%also;
@@ -50,16 +53,49 @@ diameter starts a transport process and a message interface with which
the transport process communicates with the process that starts it (aka its
parent).</p>
-<marker id="start"/>
</description>
<!-- ===================================================================== -->
+<section>
+<title>DATA TYPES</title>
+
+<taglist>
+
+<marker id="message"/>
+
+<tag><c>message() = binary() | &codec_packet;</c></tag>
+<item>
+<p>
+A Diameter message as passed over the transport interface.</p>
+
+<p>
+For an inbound message from a transport process, a &codec_packet; must
+contain the received message in its <c>bin</c> field.
+In the case of an inbound request, any value set in the
+<c>transport_data</c> field will passed back to the transport module
+in the corresponding answer message, unless the sender supplies
+another value.</p>
+
+<p>
+For an outbound message to a transport process, a &codec_packet; has a
+value other than <c>undefined</c> in its <c>transport_data</c> field
+and has the binary() to send in its <c>bin</c> field.</p>
+</item>
+
+</taglist>
+
+</section>
+
+<!-- ===================================================================== -->
+
<funcs>
<func>
<name>Mod:start({Type, Ref}, Svc, Config)
- -> {ok, Pid} | {ok, Pid, LAddrs} | {error, Reason}</name>
+ -> {ok, Pid}
+ | {ok, Pid, LAddrs}
+ | {error, Reason}</name>
<fsummary>Start a transport process.</fsummary>
<type>
<v>Type = connect | accept</v>
@@ -67,7 +103,7 @@ parent).</p>
<v>Svc = #diameter_service{}</v>
<v>Config = term()</v>
<v>Pid = pid()</v>
-<v>LAddrs = [<seealso marker="kernel:inet#type-ip_address">inet:ip_address()</seealso>]</v>
+<v>LAddrs = [&ip_address;]</v>
<v>Reason = term()</v>
</type>
<desc>
@@ -79,8 +115,8 @@ A transport process maintains a connection with a single remote peer.</p>
<p>
<c>Type</c> indicates whether the transport process in question
-is being started for a connecting (<c>connect</c>) or listening
-(<c>accept</c>) transport.
+is being started for a connecting (<c>Type=connect</c>) or listening
+(<c>Type=accept</c>) transport.
In the latter case, transport processes are started as required to
accept connections from multiple peers.</p>
@@ -90,13 +126,12 @@ that has lead to starting of a transport process.</p>
<p>
<c>Svc</c> contains the capabilities passed to &mod_start_service; and
-&mod_add_transport;,
-values passed to the latter overriding those passed to the former.</p>
+&mod_add_transport;, values passed to the latter overriding those
+passed to the former.</p>
<p>
<c>Config</c> is as passed in <c>transport_config</c> tuple in the
-&mod_transport_opt;
-list passed to &mod_add_transport;.</p>
+&mod_transport_opt; list passed to &mod_add_transport;.</p>
<p>
The start function should use the <c>Host-IP-Address</c> list and/or
@@ -114,13 +149,13 @@ it dies.
It should not link to the parent.
It should exit if its transport connection with its peer is lost.</p>
-<marker id="MESSAGES"/>
</desc>
</func>
</funcs>
<!-- ===================================================================== -->
+<marker id="MESSAGES"/>
<section>
<title>MESSAGES</title>
@@ -130,19 +165,15 @@ All messages sent over the transport interface are of the
form <c>{diameter, term()}</c>.</p>
<p>
-A transport process can expect the following messages from
-diameter.</p>
+A transport process can expect messages of the following types from
+its parent.</p>
<taglist>
-<tag><c>{diameter, {send, Packet}}</c></tag>
+<tag><c>{diameter, {send, &message;}}</c></tag>
<item>
<p>
-An outbound Diameter message.
-<c>Packet</c> can be either binary() (the message to be sent)
-or a <c>#diameter_packet{}</c> record whose <c>transport_data</c>
-field contains a value other than undefined and whose <c>bin</c> field
-contains the binary to send.</p>
+An outbound Diameter message.</p>
</item>
<tag><c>{diameter, {close, Pid}}</c></tag>
@@ -185,7 +216,7 @@ TLS.</p>
</taglist>
<p>
-A transport process should send the following messages
+A transport process should send messages of the following types
to its parent.</p>
<taglist>
@@ -208,19 +239,10 @@ Not sent if the transport process has <c>Type=accept</c>.
endpoint to which the transport has connected.</p>
</item>
-<tag><c>{diameter, {recv, Packet}}</c></tag>
+<tag><c>{diameter, {recv, &message;}}</c></tag>
<item>
<p>
-An inbound Diameter message.
-<c>Packet</c> can be either binary() (the received message)
-or a <c>#diameter_packet{}</c> record
-whose <c>bin</c> field contains the received binary().
-Any value (other than <c>undefined</c>) set in
-the <c>transport_data</c> field will be passed back with a
-corresponding answer message in the case that the inbound message is a
-request unless the sender sets another value.
-How <c>transport_data</c> is used/interpreted is up to the
-transport module.</p>
+An inbound Diameter message.</p>
</item>
<tag><c>{diameter, {tls, Ref}}</c></tag>
diff --git a/lib/diameter/doc/src/files.mk b/lib/diameter/doc/src/files.mk
index 89ec1031e6..00ced3d91e 100644
--- a/lib/diameter/doc/src/files.mk
+++ b/lib/diameter/doc/src/files.mk
@@ -26,6 +26,8 @@ XML_REF1_FILES = \
XML_REF3_FILES = \
diameter.xml \
diameter_app.xml \
+ diameter_codec.xml \
+ diameter_make.xml \
diameter_transport.xml \
diameter_tcp.xml \
diameter_sctp.xml
diff --git a/lib/diameter/doc/src/notes.xml b/lib/diameter/doc/src/notes.xml
index b89d84a4f6..d448b01eba 100644
--- a/lib/diameter/doc/src/notes.xml
+++ b/lib/diameter/doc/src/notes.xml
@@ -42,6 +42,163 @@ first.</p>
<!-- ===================================================================== -->
+<section><title>Diameter 1.3</title>
+
+ <section><title>Fixed Bugs and Malfunctions</title>
+ <list>
+ <item>
+ <p>
+ Fix faulty handling of Origin-State-Id and faulty config
+ values.</p>
+ <p>
+ The former was expected in a list despite the
+ documentation requiring (correctly) an integer. A bare
+ value for a list-valued capability was not handled.</p>
+ <p>
+ Own Id: OTP-10440</p>
+ </item>
+ <item>
+ <p>
+ Fix timing of up/down events.</p>
+ <p>
+ Previously, a call to diameter:call/4 following a peer_up
+ callback might incorrectly return {error, no_connection},
+ depending on timing. Both events now follow the
+ corresponding callbacks.</p>
+ <p>
+ Own Id: OTP-10459</p>
+ </item>
+ <item>
+ <p>
+ Make diameter:service_info/2 usable in peer_up, peer_down
+ and pick_peer callbacks.</p>
+ <p>
+ Except for in pick_peer when {call_mutates_state, false},
+ it would previously hang indefinitely.</p>
+ <p>
+ Own Id: OTP-10460</p>
+ </item>
+ <item>
+ <p>
+ Verify that End-to-End and Hop-by-Hop Identifiers in an
+ incoming CEA/DPA match those sent in the corresponding
+ CER/DPR.</p>
+ <p>
+ The values were previously ignored. Answers whose
+ identifiers do not match are handled as unexpected.</p>
+ <p>
+ Own Id: OTP-10565</p>
+ </item>
+ <item>
+ <p>
+ Fix formatting problems in PDF documentation.</p>
+ <p>
+ In particular, text corresponding to links in HTML was
+ omitted in preformatted blocks. There are still issues
+ with indentation but this is not diameter-specific.</p>
+ <p>
+ Own Id: OTP-10583</p>
+ </item>
+ </list>
+ </section>
+
+
+ <section><title>Improvements and New Features</title>
+ <list>
+ <item>
+ <p>
+ Let prepare_request, prepare_retransmit and
+ handle_request callbacks return a function to be invoked
+ on outgoing messages after encode.</p>
+ <p>
+ This allows encoded messages to be logged for example.</p>
+ <p>
+ Own Id: OTP-10441</p>
+ </item>
+ <item>
+ <p>
+ Add service_opt() 'restrict_connections' to allow
+ multiple transport connections with the same peer.</p>
+ <p>
+ Own Id: OTP-10443</p>
+ </item>
+ <item>
+ <p>
+ Add service_opt() 'sequence' to allow the masking of a
+ constant onto the topmost bits of End-to-End and
+ Hop-by-Hop identifiers.</p>
+ <p>
+ This allows the same service on different nodes to use
+ distinct values in outgoing request messages.</p>
+ <p>
+ Own Id: OTP-10445</p>
+ </item>
+ <item>
+ <p>
+ Add diameter:service_info(PeerRef) to return the
+ transport_ref() and transport_opt() list of the
+ corresponding transport.</p>
+ <p>
+ This allows easy access to these from diameter_app
+ callbacks that only get peer_ref() as an argument.</p>
+ <p>
+ Own Id: OTP-10470</p>
+ </item>
+ <item>
+ <p>
+ Add reference pages diameter_codec(3) and
+ diameter_make(3).</p>
+ <p>
+ Own Id: OTP-10471</p>
+ </item>
+ <item>
+ <p>
+ Add events for service start and stop.</p>
+ <p>
+ Own Id: OTP-10492</p>
+ </item>
+ <item>
+ <p>
+ Add transport_opt() 'disconnect_cb' to make the sending
+ of DPR configurable.</p>
+ <p>
+ Whether or not DPR should be sent at application stop,
+ service stop or transport removal is determined by the
+ value returned by the callback, as is the
+ Disconnect-Cause and timeout if DPA is not received.</p>
+ <p>
+ Own Id: OTP-10493</p>
+ </item>
+ <item>
+ <p>
+ Add transport_opt() 'capx_timeout' for the timeout
+ associated with non-reception of CER/CEA.</p>
+ <p>
+ Own Id: OTP-10554</p>
+ </item>
+ <item>
+ <p>
+ Allow a handle_request callback to return a
+ #diameter_packet{}.</p>
+ <p>
+ This allows an answer to set transport_data and header
+ fields.</p>
+ <p>
+ Own Id: OTP-10566</p>
+ </item>
+ <item>
+ <p>
+ Update documentation for RFC 6733.</p>
+ <p>
+ RFC 3588 is now obsolete.</p>
+ <p>
+ Own Id: OTP-10568</p>
+ </item>
+ </list>
+ </section>
+
+</section>
+
<section><title>Diameter 1.2</title>
<section><title>Fixed Bugs and Malfunctions</title>
@@ -428,7 +585,7 @@ Known issues or limitations:</p>
Some agent-related functionality is not entirely complete.
In particular, support for proxy agents, that advertise specific
Diameter applications but otherwise relay messages in much the same
-way as relay agents (for which a &handle_request;
+way as relay agents (for which a handle_request
callback can return a <c>relay</c> tuple), will be completed in an
upcoming release.
There may also be more explicit support for redirect agents, although
@@ -460,7 +617,7 @@ could likely be expanded upon.</p>
<item>
<p>
-The function &service_info;
+The function diameter:service_info/2
can be used to retrieve information about a started service
(statistics, information about connected peers, etc) but
this is not yet documented and both the input and output may change
diff --git a/lib/diameter/doc/src/ref_man.xml b/lib/diameter/doc/src/ref_man.xml
index 137ce79094..4b99fe716d 100644
--- a/lib/diameter/doc/src/ref_man.xml
+++ b/lib/diameter/doc/src/ref_man.xml
@@ -6,6 +6,7 @@
<header>
<copyright>
<year>2011</year>
+<year>2012</year>
<holder>Ericsson AB. All Rights Reserved.</holder>
</copyright>
<legalnotice>
@@ -40,7 +41,9 @@ applications on top of the Diameter protocol. </p>
<xi:include href="diameter.xml"/>
<xi:include href="diameter_compile.xml"/>
<xi:include href="diameter_app.xml"/>
+<xi:include href="diameter_codec.xml"/>
<xi:include href="diameter_dict.xml"/>
+<xi:include href="diameter_make.xml"/>
<xi:include href="diameter_transport.xml"/>
<xi:include href="diameter_tcp.xml"/>
<xi:include href="diameter_sctp.xml"/>
diff --git a/lib/diameter/doc/src/seealso.ent b/lib/diameter/doc/src/seealso.ent
index 6f67630220..4647c42f85 100644
--- a/lib/diameter/doc/src/seealso.ent
+++ b/lib/diameter/doc/src/seealso.ent
@@ -32,6 +32,8 @@ significant.
-->
+<!ENTITY the_rfc 'RFC 6733'>
+
<!-- diameter -->
<!ENTITY mod_add_transport '<seealso marker="diameter#add_transport-2">diameter:add_transport/2</seealso>'>
@@ -77,12 +79,21 @@ significant.
<!ENTITY app_prepare_request '<seealso marker="diameter_app#Mod:prepare_request-3">prepare_request/3</seealso>'>
<!ENTITY app_capabilities '<seealso marker="diameter_app#capabilities">diameter_app:capabilities()</seealso>'>
-<!ENTITY app_message '<seealso marker="diameter_app#message">diameter_app:message()</seealso>'>
-<!ENTITY app_packet '<seealso marker="diameter_app#packet">diameter_app:packet()</seealso>'>
<!ENTITY app_peer '<seealso marker="diameter_app#peer">diameter_app:peer()</seealso>'>
<!ENTITY app_peer_ref '<seealso marker="diameter_app#peer_ref">diameter_app:peer_ref()</seealso>'>
<!ENTITY app_state '<seealso marker="diameter_app#state">diameter_app:state()</seealso>'>
+<!-- diameter_codec -->
+
+<!ENTITY codec_encode '<seealso marker="diameter_codec#encode-2">diameter_codec:encode/2</seealso>'>
+<!ENTITY codec_decode '<seealso marker="diameter_codec#decode-2">diameter_codec:decode/2</seealso>'>
+
+<!ENTITY codec_avp '<seealso marker="diameter_codec#avp">diameter_codec:avp()</seealso>'>
+<!ENTITY codec_header '<seealso marker="diameter_codec#header">diameter_codec:header()</seealso>'>
+<!ENTITY codec_dictionary '<seealso marker="diameter_codec#dictionary">diameter_codec:dictionary()</seealso>'>
+<!ENTITY codec_message '<seealso marker="diameter_codec#message">diameter_codec:message()</seealso>'>
+<!ENTITY codec_packet '<seealso marker="diameter_codec#packet">diameter_codec:packet()</seealso>'>
+
<!-- diameter_dict -->
<!ENTITY dict_data_types '<seealso marker="diameter_dict#DATA_TYPES">diameter_dict(4)</seealso>'>
@@ -95,6 +106,14 @@ significant.
<!ENTITY dict_UTF8String '<seealso marker="diameter_dict#DATA_TYPES">UTF8String()</seealso>'>
<!ENTITY dict_Unsigned32 '<seealso marker="diameter_dict#DATA_TYPES">Unsigned32()</seealso>'>
+<!ENTITY dict_name '<seealso marker="diameter_dict#name">@name</seealso>'>
+<!ENTITY dict_prefix '<seealso marker="diameter_dict#prefix">@prefix</seealso>'>
+<!ENTITY dict_inherits '<seealso marker="diameter_dict#inherits">@inherits</seealso>'>
+
+<!-- diameter_make -->
+
+<!ENTITY make_codec '<seealso marker="diameter_make#codec-2">diameter_make:codec/2</seealso>'>
+
<!-- diameter_transport -->
<!ENTITY transport_start
@@ -105,8 +124,9 @@ significant.
<!ENTITY man_compile '<seealso marker="diameterc">diameterc(1)</seealso>'>
<!ENTITY man_main '<seealso marker="diameter">diameter(3)</seealso>'>
<!ENTITY man_app '<seealso marker="diameter_app">diameter_app(3)</seealso>'>
+<!ENTITY man_codec '<seealso marker="diameter_codec">diameter_codec(3)</seealso>'>
<!ENTITY man_dict '<seealso marker="diameter_dict">diameter_dict(4)</seealso>'>
-<!ENTITY man_transport
- '<seealso marker="diameter_transport">diameter_transport(3)</seealso>'>
+<!ENTITY man_make '<seealso marker="diameter_make">diameter_make(3)</seealso>'>
+<!ENTITY man_transport '<seealso marker="diameter_transport">diameter_transport(3)</seealso>'>
<!ENTITY man_sctp '<seealso marker="diameter_sctp">diameter_sctp(3)</seealso>'>
<!ENTITY man_tcp '<seealso marker="diameter_tcp">diameter_tcp(3)</seealso>'>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-03 07:07:26 +0000