Navigation :

SIP EDRs (Base)

Introduction

The n2sip package supplies three N-Squared SIP control agents which perform the SIP transaction and dialog control. These three applications are:

SrpSipApp - The N2SRP “Specialised Resource Platform” which performs SIP IVR interaction as directed by INAP/CAMEL.
LhoSipApp - The “Logic Hand-Off” app which performs SIP control as direct by Lua scripts.

All three of these n2svcd applications are based on a shared SipApp base class, and they all generate some (or all) of the base SIP EDRs documented here. In addition, they may also generate their own component-specific higher-layer EDRs.

The base SIP EDR Event Types are:

SHUTDOWN
IN-REGISTER
IN-INVITE-ALEG
IN-CANCEL-ALEG
IN-REINVITE-ALEG
IN-REINVITE-BLEG
IN-BYE-ALEG
IN-BYE-BLEG
IN-BYE
OUT-INVITE-ALEG
OUT-INVITE-BLEG
OUT-CANCEL-ALEG
OUT-CANCEL-BLEG
OUT-REINVITE-ALEG
OUT-REINVITE-BLEG
OUT-BYE-ALEG
OUT-BYE-BLEG

Also:

IN-ACK-ALEG
IN-ACK-BLEG
IN-PRACK-ALEG
IN-PRACK-BLEG
OUT-ACK-ALEG
OUT-ACK-BLEG
OUT-PRACK-ALEG
OUT-PRACK-BLEG

Each application built on this framework will typically generate additional service-specific Event Data Records which may be merged into the same EDR stream, or may be written to an independent EDR stream.

Not all applications will use all event types.

Common Format

The configuration parameters for configuring EDR output including filename structure and location is defined in the configuration documentation for the EdrApp which is a base component provided by the n2svcd package.

All EDRs are written by the EdrApp application using its file and record formatting rules.

Refer to the n2svcd base documentation for more details on configuring and managing EDR streams, and on the syntax/encoding details for N-Squared EDRs.

Note: Some SIP headers may be repeated in the SIP Request or Response in which case they will also be repeated in the EDR. Refer to the common format documentation for details on the encoding of repeated fields – specifically the distinction between the comma , which is used to separate repeated field values, and the encoded %2C comma used to represent a comma within one field value.

SIP Merged EDRs

Note: All SIP Event EDRs have distinct behavior according to whether sip_edr_merge is enabled in the application configuration.

If sip_edr_merge is not enabled, then each SIP interaction will generate two separate EDRs. The first EDR is for the SIP request and records the request fields. Then subsequently there is one EDR for each SIP response which contains the final SIP Status Code (in the range 200-699) in the CODE field, each with its own primary timestamp.

If sip_edr_merge is enabled, then each SIP interaction will generate one EDR (except for ACK).
The request EDR will be delayed until the first SIP response is generated, and the single EDR will contain the SIP request fields as well as containing the SIP response Status Code as CODE.
The primary timestamp on the EDR is the time of the response, and the timestamp of the original request is given separately in a regular field named REQUEST_AT.

Provisional SIP 100 Responses associated with an INVITE are (when present) recorded in the (merged or separate) EDR which contains the final SIP response CODE. They are listed in the PCODES field as a comma-separated array of provisional code values.

EDRs for ACK (if enabled) are always written separately.

SHUTDOWN EDR

The SHUTDOWN EDR Event indicates that a SIP instance ended with an internal processing error. This EDR is generated independently of any other SIP EDRs associated with the EDR. In most cases, there will be other SIP EDRs associated with this instance containing additional protocol information.

Example:

2018-05-22 03:44:30.181<2771>SHUTDOWN
→ |EXCEPTION=Inbound service handle "OTP-Outcall" does not map to any known script.

Field	Type	Description
`EXCEPTION`	String	[Required] Description of the reason for the unexpected SIP call control instance shutdown.

SIP Request EDR Fields

The following fields are applicable to one or more EDRs associated with a SIP Request. i.e.

When sip_edr_merge is enabled there will be a single EDR for the combined Request/Response, which will contain these fields.
Where sip_edr_merge is disabled, these fields will be in the first EDR, and the Response fields will appear in a second, separate EDR.

Note that these fields do not apply to ACK Requests.

The common SIP Request fields are:

Field	Type	Description
`REQUEST_AT`	Timestamp	[Required] Timestamp of original Request.
`RETRY`	Integer	This field is present if one or more retry attempts were made for this Request.
`TIMEOUT`	`1`	This field is present if and only if the retry timer was exceeded for Request send attempts. E.g. if SIP Timer `B` or `F` has expired. In this case, there will almost certainly be a `RETRY` count present in the EDR.
`CALL_ID`	String	[Required] SIP Request `Call-ID` header value.
`REQUIRE`	String	SIP Request `Require` header value (if present).
`CSEQ`	Integer	[Required] SIP Request `CSeq` number.
`FROM_URI`	String	SIP Request `From` URI (if present).
`TO_URI`	String	SIP Request `To` URI (if present).
`TRANSPORT`	`UDP`	[Required] Transport over which the SIP request was received or sent.
`VIA_HOST`	String	[Required] The `Via` Sent-By Host in the SIP Request. Only the top-most `Via` header details are recorded in the EDR.
`VIA_PORT`	Integer	The `Via` Sent-By Port Number in the SIP Request (if present). If not present, the default port `5060` was assumed. Only the top-most `Via` header details are recorded in the EDR.
`VIA_BRANCH`	String	[Required] The `Via` Branch in the SIP Request. Begins with `z9hG4bK`. Only the top-most `Via` header details are recorded in the EDR.
`VIA_RECEIVED`	Numeric IP	[Inbound Request Only] The numeric dot-notation IP address from which we received this request. Present only when the inbound Request contains the `received` or `rport` parameter of the `Via` header. In this case, we have set this value as the `received` parameter of the `Via` header in the Response. Only the top-most `Via` header details are recorded in the EDR.
`VIA_RPORT`	Integer	[Inbound Request Only] The numeric port number from which we received this request. Present only when the inbound Request contains the `rport` parameter of the `Via` header. In this case, we have set this value as the `rport` parameter of the `Via` header in the Response. Only the top-most `Via` header details are recorded in the EDR.
`REMOTE_IP`	Numeric IP	[Required, Outbound Request Only] The numeric dot-notation IP address to which we attempted to send this request.
`REMOTE_PORT`	Integer	[Required, Outbound Request Only] The numeric port number to which we attempted to send this request.
`PCV`	Integer	The value of the `P-Charging-Vector` header, if present in the request.

The following fields are common (when applicable) to all EDRs associated with a SIP Response. i.e.

When sip_edr_merge is enabled there will be a single EDR for the combined request/response, which may contain these fields.
Where sip_edr_merge is disabled, these fields will be in the second, separate EDR.

The common fields in the response EDR for an inbound SIP request fields are:

`RESPONSE_AT`	Timestamp	[Required in Response] Timestamp of first `200` - `699` response.
`CODE`	Integer	[Required] SIP Response code returned by the SIP application. Contained in a standalone EDR if `sip_edr_merge` is enabled.
`PCODES`	Array of Integer	Codes (in the range 100-199) for any Provisional Responses associated with this transaction. This is applicable only for `INVITE` and `REINVITE` EDRs.
`NPRACK`	Integer	The number of Reliable Provisional SIP Responses which we consider to be confirmed for this transaction at the time the EDR is generated, which is the time at which the INVITE transaction becomes Completed/Confirmed/Terminated. This field can be present only when `100rel` Reliable Provisional Response is used for this INVITE or re-INVITE transaction. A Reliable Provisional Response is counted as "confirmed" when we receive the relevant `PRACK` Request or successful `PRACK` Response. This is applicable only for `INVITE` and `REINVITE` EDRs.

The following fields are applicable to either SIP Request or SIP Response EDRs according to direction:

`LCONTACT`	String	SIP Request or SIP Response `Contact` header value (if present) as sent out by us.
`LTAG`	String	The local SIP Dialog tag extracted from the relevant `From`/`To` header as applicable. This is our local tag, sent in outbound Request or Response.
`RCONTACT`	String	SIP Request or SIP Response `Contact` header value (if present) as sent by the far end.
`RTAG`	String	The remote SIP Dialog tag extracted from the relevant `From`/`To` header as applicable. This is the far-end tag, received in outbound Request or Response.
`SDP_IN`	`1`	This field is present with value `1` iff the Request/Response contained SDP in the inbound direction.
`SDP_OUT`	`1`	This field is present with value `1` iff the Request/Response contained SDP in the outbound direction.
`ISUP_IN`	String	This field is a comma-separated list of ISUP message type abbreviations that have been received inbound as part of the SIP transaction. Supported codes at this time are IAM, ACM, CON, ANM, REL, RLC, CPG. Repeated received messages (e.g. repeated received CPG messages) will be represented by repeated values. Unknown message codes may be represented by the decimal integer message type value.
`ISUP_OUT`	`1`	This field is a comma-separated list of ISUP message type abbreviations that have been sent outbound as part of the SIP transaction. Supported codes at this time are IAM, ACM, CON, ANM, REL, RLC, CPG. Repeated sent messages (e.g. repeated sent CPG messages) will be represented by repeated values. Unknown message codes will never be sent.

IN-REGISTER EDR(s)

The IN-REGISTER merged EDR Event (or split EDR pair) indicates that an inbound SIP REGISTER has been received by the SIP application.

Example (merged):

2021-10-19 04:49:44.585<LHO-1634618974-65e01e56>IN-REGISTER|CALL_ID=TZA7aPiZz8|CODE=200
→ |LCONTACT=%3Csip:665566@192.168.1.5:5062;transport%3Dudp%3E;%2Bsip.instance%3D%22%3Curn:uuid:27b843f9-d300-49fb-b108-fff03a6369e3%3E%22
→ |CSEQ=20|FROM_URI=sip:665566@192.168.1.5
→ |RCONTACT=%3Csip:665566@192.168.1.5:5062;transport%3Dudp%3E;%2Bsip.instance%3D%22%3Curn:uuid:27b843f9-d300-49fb-b108-fff03a6369e3%3E%22;expires%3D3600
→ |REQUEST_AT=2021-10-19 04:49:44.584|RESPONSE_AT=2021-10-19 04:49:44.584
→ |TO_URI=sip:665566@192.168.1.5|TRANSPORT=UDP|VIA_BRANCH=z9hG4bK.HP47xPjxo|VIA_HOST=192.168.1.5|VIA_RECEIVED=192.168.1.5|VIA_RPORT=5062

Note: For IN-REGISTER, the TO_URI and FROM_URI EDR fields should be identical.

Note: Only a single Contact header may be present. Multi-Contact registrations are not supported.

IN-INVITE-ALEG EDR(s)

The IN-INVITE-ALEG merged EDR Event (or split EDR pair) indicates that an inbound SIP INVITE has been received by the SIP application.

An inbound SIP INVITE is only supported for the initial A-Leg. There is no IN-INVITE-BLEG.

Example:

The PCODES field may be present for this EDR.

The LTAG and RTAG fields should be present for this EDR.

In addition the following fields may be present:

Field	Type	Description
`PRIVACY`	String	The value of the received `Privacy` header, if present.
`PAI`	String	The value of the top-most received `P-Asserted-Identity` header, if present.
`PPI`	String	The value of the top-most received `P-Preferred-Identity` header, if present.

In addition, this EDR may contain fields for any extra SIP INVITE Header fields defined using the <invite_header> configuration which is part of the Common SIP Application Configuration.

IN-CANCEL-ALEG EDR(s)

The IN-CANCEL-ALEG merged EDR Event (or split EDR pair) indicates that an inbound SIP CANCEL has been received by the SIP application during initial set-up of the first A-Leg.

An inbound SIP CANCEL is only supported for the initial A-Leg. There is no IN-BLEG-CANCEL.

Example:

IN-REINVITE-ALEG EDR(s)

The IN-REINVITE-ALEG merged EDR Event (or split EDR pair) indicates that an inbound SIP re-INVITE has been received by the SIP application.

This might have an empty content (i.e. a Activity Test “ping”), or it might contain an SDP body to re-negotiate the stream attributes.

Example:

The PCODES field may be present for this EDR.

The LTAG and RTAG fields will be present for this EDR since the dialog is already established.

The LCONTACT and RCONTACT fields should not be present for this EDR since the dialog is already established.

In addition, this EDR may contain fields for any extra SIP INVITE Header fields defined using the <invite_header> configuration which is part of the Common SIP Application Configuration.

IN-REINVITE-BLEG EDR(s)

The IN-REINVITE-BLEG merged EDR Event (or split EDR pair) indicates that an inbound SIP re-INVITE has been received by the SIP application.

This might have an empty content (i.e. a Activity Test “ping”), or it might contain an SDP body to re-negotiate the stream attributes.

Example:

The PCODES field may be present for this EDR.

The LTAG and RTAG fields will be present for this EDR since the dialog is already established.

The LCONTACT and RCONTACT fields should not be present for this EDR since the dialog is already established.

In addition, this EDR may contain fields for any extra SIP INVITE Header fields defined using the <invite_header> configuration which is part of the Common SIP Application Configuration.

IN-BYE-ALEG EDR(s)

The IN-BYE-ALEG merged EDR Event (or split EDR pair) indicates that an inbound SIP BYE has been received by the SIP application for the established A-Leg.

In all services this will be followed by an immediate OUT-BYE-BLEG, since the SIP call model as currently implemented does not support call-control after the loss of the A-Leg.

Example:

IN-BYE-BLEG EDR(s)

The IN-BYE-BLEG merged EDR Event (or split EDR pair) indicates that an inbound SIP BYE has been received by the SIP application for the established B-Leg.

The subsequent behavior is service-dependent. The call may continue, for example by attempting to construct a new B-Leg.

Example:

IN-BYE EDR(s)

The IN-BYE merged EDR Event (or split EDR pair) indicates that an inbound SIP BYE has been received by the SIP application, however the BYE could not be correlated to any in-progress dialog, and was declined.

The subsequent behavior is service-dependent. The call may continue, for example by attempting to construct a new B-Leg.

Example:

The CODE in this case will always be 481, indicating “Call/Transaction Does Not Exist”.

IN-ACK-ALEG EDR(s)

The IN-ACK-ALEG is generated when the first inbound ACK is received for the SIP Final Response that we previously sent for an inbound A-Leg INVITE or re-INVITE. Any received re-transmissions of this ACK will not generate an additional EDR.

This EDR is optional, controlled by an application flag.

Example:

2021-12-24 00:32:41.020<LHO-1640305092-1c467418>IN-ACK-ALEG|TRANSPORT=UDP|REMOTE_IP=192.168.1.5|REMOTE_PORT=5064

IN-ACK-BLEG EDR(s)

The IN-ACK-BLEG is generated when the first inbound ACK is received for the SIP Final Response that we previously sent for an inbound B-Leg re-INVITE. Any received re-transmissions of this ACK will not generate an additional EDR.

This EDR is optional, controlled by an application flag.

Example:

2021-12-24 00:32:41.020<LHO-1640305092-1c467418>IN-ACK-BLEG|TRANSPORT=UDP|REMOTE_IP=192.168.1.5|REMOTE_PORT=5064

IN-PRACK-ALEG EDR(s)

The IN-PRACK-ALEG is generated for each first inbound PRACK received for each SIP Provisional Response that we previously sent for an inbound A-Leg INVITE or re-INVITE in the case where Reliable Provisional Response 100rel has been negotiated. Any received re-transmissions of this PRACK will not generate an additional EDR.

This EDR is optional, controlled by an application flag.

Example:

2024-01-24 21:37:30.849<kirby~LHO~1706132249~319554a8>IN-PRACK-ALEG|REMOTE_IP=192.168.68.7|REMOTE_PORT=5063|RSEQ=966864470|TRANSPORT=udp

IN-PRACK-BLEG EDR(s)

The IN-PRACK-BLEG is generated for each first inbound PRACK received for each SIP Provisional Response that we previously sent for an inbound B-Leg re-INVITE in the case where reliable provisional response 100rel has been negotiated. Any received re-transmissions of this PRACK will not generate an additional EDR.

This EDR is optional, controlled by an application flag.

Example:

2024-01-24 21:37:30.849<kirby~LHO~1706132249~319554a8>IN-PRACK-BLEG|REMOTE_IP=192.168.68.7|REMOTE_PORT=5063|RSEQ=966864470|TRANSPORT=udp

OUT-INVITE-ALEG EDR(s)

The OUT-INVITE-ALEG merged EDR Event (or split EDR pair) indicates that a SIP application has attempted to set-up a new A-Leg for the call.

A new A-Leg may be created by using the SIP outcall agent. A new A-Leg is a network-originated call, e.g. a wake-up call, network-initiated services announcement, a voice call to deliver a 2FA OTP, etc.

The PCODES field may be present for this EDR.

The RETRY and TIMEOUT fields may be present for this EDR.

In addition the following fields may be present:

Field	Type	Description
`PRIVACY`	String	The value of the sent `Privacy` header, if present.
`PAI`	String	The value of the sent `P-Asserted-Identity` header, if present.
`PPI`	String	The value of the sent `P-Preferred-Identity` header, if present.

OUT-INVITE-BLEG EDR(s)

The OUT-INVITE-BLEG merged EDR Event (or split EDR pair) indicates that a SIP application has attempted to set-up a B-Leg for the call. This may be a temporary B-Leg established for the purpose of performing interaction on an external media server, or it might be a termination B-Leg for the purposes of connecting a voice call.

The PCODES field may be present for this EDR.

The RETRY and TIMEOUT fields may be present for this EDR.

In addition the following fields may be present:

Field	Type	Description
`PRIVACY`	String	The value of the received `Privacy` header, if present.
`PAI`	String	The value of the sent `P-Asserted-Identity` header, if present.
`PPI`	String	The value of the sent `P-Preferred-Identity` header, if present.

Example:

OUT-CANCEL-ALEG EDR(s)

The OUT-CANCEL-ALEG merged EDR Event (or split EDR pair) indicates that a SIP application has given up attempting to set-up or modify (via re-INVITE) an A-Leg for the call.

The RETRY and TIMEOUT fields may be present for this EDR.

Example:

OUT-CANCEL-BLEG EDR(s)

The OUT-CANCEL-BLEG merged EDR Event (or split EDR pair) indicates that a SIP application has given up attempting to set-up or modify (via re-INVITE) a B-Leg for the call.

The RETRY and TIMEOUT fields may be present for this EDR.

Example:

OUT-REINVITE-ALEG EDR(s)

The OUT-REINVITE-ALEG merged EDR Event (or split EDR pair) indicates that an inbound SIP re-INVITE has been sent by the SIP application, associated with the A-Leg dialog.

This might have an empty content (i.e. a Activity Test “ping”), or it might contain an SDP body to re-negotiate the stream attributes, either for the purposes of playing an internal RTP streamed announcement, or as a pass-through proxy of an associated IN-REINVITE-BLEG.

Example:

The PCODES field may be present for this EDR.

The LTAG and RTAG fields will be present for this EDR since the dialog is already established.

The LCONTACT and RCONTACT fields should not be present for this EDR since the dialog is already established.

In addition, this EDR may contain fields for any extra SIP INVITE Header fields defined using the <invite_header> configuration which is part of the Common SIP Application Configuration.

OUT-REINVITE-BLEG EDR(s)

The OUT-REINVITE-BLEG merged EDR Event (or split EDR pair) indicates that an inbound SIP re-INVITE has been sent by the SIP application, associated with the B-Leg dialog.

This might have an empty content (i.e. a Activity Test “ping”), or it might contain an SDP body to re-negotiate the stream attributes, as a pass-through proxy of an associated IN-REINVITE-ALEG.

Note: The N2SIP framework does not support RTP streaming to the B-Leg, hence any SDP sent out on a B-Leg re-INVITE must be a pass-through of a received inbound A-Leg re-INVITE.

Example:

The PCODES field may be present for this EDR.

The LTAG and RTAG fields will be present for this EDR since the dialog is already established.

The LCONTACT and RCONTACT fields should not be present for this EDR since the dialog is already established.

In addition, this EDR may contain fields for any extra SIP INVITE Header fields defined using the <invite_header> configuration which is part of the Common SIP Application Configuration.

OUT-BYE-ALEG EDR(s)

The OUT-BYE-ALEG merged EDR Event (or split EDR pair) indicates that the N2SIP application is ending an in-progress A-Leg. This is the standard call teardown where the A-party did not hang up. It applies for example:

Back-to-Back teardown after a connected B-Party hangs up (i.e. following IN-BYE-BLEG).
Hangup at the end of an internal or external announcement (not using Early Media).

Example:

OUT-BYE-BLEG EDR(s)

The OUT-BYE-BLEG merged EDR Event (or split EDR pair) indicates that the N2SIP application is ending an in-progress B-Leg. This is the standard call teardown where the B-party did not hang up. It applies for example:

Back-to-Back teardown after a connected A-Party hangs up (i.e. following IN-BYE-ALEG).

Note: The N2SIP does not currently support any B-Party announcement scenarios.

Example:

OUT-ACK-ALEG EDR(s)

The OUT-ACK-ALEG is generated when the first outbound ACK is sent for the SIP Response that we received for an outbound A-Leg INVITE or re-INVITE. Any sent re-transmissions of this ACK will not generate an EDR.

This EDR is optional, controlled by an application flag.

Example:

OUT-ACK-BLEG EDR(s)

The OUT-ACK-BLEG is generated when the first outbound ACK is sent for the SIP Response that we received for an outbound B-Leg INVITE or re-INVITE. Any sent re-transmissions of this ACK will not generate an EDR.

This EDR is optional, controlled by an application flag.

Example:

OUT-PRACK-ALEG EDR(s)

The OUT-PRACK-ALEG is generated for each first outbound PRACK sent for each SIP Provisional Response that we received for an outbound A-Leg INVITE or re-INVITE in the case where reliable provisional response 100rel has been negotiated. Any sent re-transmissions of this PRACK will not generate an additional EDR.

This EDR is optional, controlled by an application flag.

Example:

OUT-PRACK-BLEG EDR(s)

The OUT-PRACK-BLEG is generated for each first outbound PRACK sent for the SIP Provisional Response that we received for an outbound B-Leg INVITE or re-INVITE in the case where reliable provisional response 100rel has been negotiated. Any sent re-transmissions of this PRACK will not generate an additional EDR.

This EDR is optional, controlled by an application flag.

Example: