diff options
author | Fredrik Gustafsson <[email protected]> | 2012-12-03 10:22:40 +0100 |
---|---|---|
committer | Fredrik Gustafsson <[email protected]> | 2012-12-03 10:22:40 +0100 |
commit | c228ceb941e26a04317bd2f66a2ee64687f0f869 (patch) | |
tree | fb019fce335b6db5b92ce300ee707496a9fe759b /lib/diameter/doc/src/diameter_codec.xml | |
parent | f78daeeccbf6de61b9e5dae4dd70f12fba03a2ff (diff) | |
parent | 26dffbeec17226a25c00d4072cb0f5c29ed48cea (diff) | |
download | otp-c228ceb941e26a04317bd2f66a2ee64687f0f869.tar.gz otp-c228ceb941e26a04317bd2f66a2ee64687f0f869.tar.bz2 otp-c228ceb941e26a04317bd2f66a2ee64687f0f869.zip |
Merge branch 'fredrik/ssh/fix-idle-tests' into fredrik/ssh/rekeying
* fredrik/ssh/fix-idle-tests: (50 commits)
Modifications to idle_time testcase
Teach Win installer to handle redist on w2012/w8
ssl: Receive port EXIT-message so that it does not get mixed up with the protocol-error message we are expecting
ssl: Add and enhance tests
ssl: Consider new server options when resuming a session
Prepare release
ssl: Add dependencies to Makefile
Simplify the code for the generated info/0 function
Don't try to work around a non-loadable NIF library
Fix BER encoding when multiple levels of typedefs are used
Update megaco documentation
Update documentation for the asn1 application
Fix other applications
Fix use of asn1 in megaco
Remove the unused asn1ct_gen_ber module
Fix erroneous skipping for jinterface, erl_interface and ic
kernel: Heart port needs to be unregistered
Update preloaded modules
Update primary bootstrap
Update copyright years
...
Diffstat (limited to 'lib/diameter/doc/src/diameter_codec.xml')
-rw-r--r-- | lib/diameter/doc/src/diameter_codec.xml | 389 |
1 files changed, 389 insertions, 0 deletions
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() = 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> |