SIP EDRs (Base)
Introduction
All N-Squared SIP call processing solutions 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:
2021-10-28 05:43:54.488<LHO-1635397733-065f8e02>IN-INVITE-ALEG|CALL_ID=uLwv1FiKor|CODE=200
→ |LCONTACT=%3Csip:665566@192.168.1.5:5063;transport%3Dudp%3E;expires%3D3600|CSEQ=20
→ |FROM_URI=sip:665566@192.168.1.5|LTAG=106756493|PCODES=100,180|RCONTACT=%3Csip:5000@192.168.1.5:5061%3E
→ |REQUEST_AT=2021-10-28 05:43:54.478|RESPONSE_AT=2021-10-28 05:43:54.488
→ |RTAG=wv1FiNGT|TO_URI=sip:5000@192.168.1.5
→ |TRANSPORT=UDP|VIA_BRANCH=z9hG4bK.Lwv1FiHsu|VIA_HOST=192.168.1.5|VIA_PORT=5063|VIA_RECEIVED=192.168.1.5|VIA_RPORT=5063
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:
2021-10-20 06:18:27.830<LHO-1634710643-4737875f>IN-CANCEL-ALEG|CALL_ID=1194431843@192.168.1.5|CODE=200
→ |CSEQ=1|FROM_URI=sip:665566@192.168.1.5
→ |REQUEST_AT=2021-10-20 06:18:27.829|RESPONSE_AT=2021-10-20 06:18:27.830
→ |TO_URI=sip:4003@192.168.1.5:5061
→ |TRANSPORT=UDP|VIA_BRANCH=z9hG4bK1194637012|VIA_HOST=192.168.1.5|VIA_RECEIVED=|VIA_RPORT=
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:
2022-08-16 23:07:05.329<vagabond~LHO~1660690948~205e010f>IN-REINVITE-ALEG|CALL_ID=541501044@172.18.0.1|CODE=200
→ |CSEQ=3|FROM_URI=sip:665566@172.18.0.1|LTAG=|RCONTACT=sip:665566@172.18.0.1:5061
→ |REQUEST_AT=2022-08-16 23:07:05.327|RESPONSE_AT=2022-08-16 23:07:05.329|RTAG=542123848
→ |TO_URI=sip:4006@172.18.0.1:5061|TRANSPORT=udp|VIA_BRANCH=|VIA_HOST=|VIA_RECEIVED=10.42.2.244
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:
2022-08-16 23:07:05.329<vagabond~LHO~1660690948~205e010f>IN-REINVITE-ALEG|CALL_ID=541501044@172.18.0.1|CODE=200
→ |CSEQ=3|FROM_URI=sip:665566@172.18.0.1|LTAG=|RCONTACT=sip:665566@172.18.0.1:5061
→ |REQUEST_AT=2022-08-16 23:07:05.327|RESPONSE_AT=2022-08-16 23:07:05.329|RTAG=542123848
→ |TO_URI=sip:4006@172.18.0.1:5061|TRANSPORT=udp|VIA_BRANCH=|VIA_HOST=|VIA_RECEIVED=10.42.2.244
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:
2021-10-20 06:45:26.285<IVR-1634712319-2ff34afe>IN-BYE-ALEG|CALL_ID=804457721@192.168.1.5|CODE=200
→ |CSEQ=2|FROM_URI=sip:665577@192.168.1.5
→ |REQUEST_AT=2021-10-20 06:45:26.284|RESPONSE_AT=2021-10-20 06:45:26.285
→ |TO_URI=sip:9991884@192.168.1.5:5064
→ |TRANSPORT=UDP|VIA_BRANCH=z9hG4bK804576805|VIA_HOST=192.168.1.5|VIA_RECEIVED=|VIA_RPORT=
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:
2021-10-20 06:18:40.921<LHO-1634710643-47378763>IN-BYE-BLEG|CALL_ID=1194431845@192.168.1.5|CODE=200
→ |CSEQ=1|FROM_URI=sip:4000@192.168.1.5:5061
→ |REQUEST_AT=2021-10-20 06:18:40.920|RESPONSE_AT=2021-10-20 06:18:40.921
→ |TO_URI=sip:666666@192.168.1.5
→ |TRANSPORT=UDP|VIA_BRANCH=z9hG4bK1194637022|VIA_HOST=192.168.1.5|VIA_RECEIVED=|VIA_RPORT=
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:
2021-10-21 00:45:04.262<LHO-1634712319-2ff5a60c>IN-BYE|CALL_ID=GFJun2nXg3X|CODE=481
→ |CSEQ=21|FROM_URI=sip:665566@192.168.1.5
→ |REQUEST_AT=2021-10-21 00:45:04.261|RESPONSE_AT=2021-10-21 00:45:04.262
→ |TO_URI=sip:400000@192.168.1.5
→ |TRANSPORT=UDP|VIA_BRANCH=z9hG4bK.FJun2n62V|VIA_HOST=192.168.1.5|VIA_RECEIVED=|VIA_RPORT=
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:
2021-10-28 05:09:08.342<LHO-1635397733-065f8de0>OUT-INVITE-BLEG|CALL_ID=106134765@192.168.1.5
→ |CODE=200|LCONTACT=sip:666666@192.168.1.5:5061|CSEQ=1|FROM_URI=sip:666666@192.168.1.5|LTAG=106756454
→ |PCODES=100,180|REMOTE_IP=192.168.1.5|REMOTE_PORT=5061|REQUEST_AT=2021-10-28 05:09:06.317|RESPONSE_AT=2021-10-28 05:09:08.342
→ |RTAG=106756455|TO_URI=sip:4000@192.168.1.5:5061|TRANSPORT=UDP|VIA_BRANCH=z9hG4bK106929399|VIA_HOST=192.168.1.5|VIA_PORT=5061
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:
2021-10-29 04:06:23.957<LHO-1635477112-67979f23>OUT-CANCEL-ALEG|CALL_ID=fdL1w2Eybd
→ |CODE=200|CSEQ=1|FROM_URI=sip:400000@192.168.1.5
→ |REMOTE_IP=192.168.1.5|REMOTE_PORT=5063
→ |REQUEST_AT=2021-10-29 04:06:23.938|RESPONSE_AT=2021-10-29 04:06:23.957|TO_URI=sip:666666@192.168.1.5
→ |TRANSPORT=UDP|VIA_BRANCH=z9hG4bK1738317227|VIA_HOST=192.168.1.5|VIA_PORT=5061
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:
2021-10-29 05:09:42.025<LHO-1635483207-647f4d27>OUT-CANCEL-BLEG|CALL_ID=1685885281@192.168.1.5
→ |CODE=200|CSEQ=1|FROM_URI=sip:665566@192.168.1.5
→ |REMOTE_IP=192.168.1.5|REMOTE_PORT=5061
→ |REQUEST_AT=2021-10-29 05:09:42.022|RESPONSE_AT=2021-10-29 05:09:42.025|TO_URI=sip:4003@192.168.1.5:5061
→ |TRANSPORT=UDP|VIA_BRANCH=z9hG4bK1686106201|VIA_HOST=192.168.1.5|VIA_PORT=5061
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:
2022-08-17 03:40:56.327<vagabond~LHO~1660707646~33ea50d0>OUT-REINVITE-ALEG|CALL_ID=Z84XKmmpmn|CODE=200
→ |CSEQ=1|FROM_URI=sip:400006@172.18.0.1|LCONTACT=sip:400006@172.18.0.1:5061|LTAG=871646399|REMOTE_IP=172.18.0.1|REMOTE_PORT=5063
→ |REQUEST_AT=2022-08-17 03:40:55.824|RESPONSE_AT=2022-08-17 03:40:56.327|RETRY=1|RTAG=4XKmmgPk
→ |TO_URI=sip:665566@172.18.0.1|TRANSPORT=udp|VIA_BRANCH=z9hG4bK870518931|VIA_HOST=172.18.0.1|VIA_PORT=5061
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:
2022-08-17 03:44:03.342<vagabond~LHO~1660707646~33ea50f0>OUT-REINVITE-BLEG|CALL_ID=871828884@172.18.0.1|CODE=200
→ |CSEQ=2|FROM_URI=sip:665566@172.18.0.1|LCONTACT=sip:665566@172.18.0.1:5061|LTAG=871646439|REMOTE_IP=172.18.0.1|REMOTE_PORT=5061
→ |REQUEST_AT=2022-08-17 03:44:03.335|RESPONSE_AT=2022-08-17 03:44:03.342|RTAG=871646440
→ |TO_URI=sip:4006@172.18.0.1:5061|TRANSPORT=udp|VIA_BRANCH=z9hG4bK870519040|VIA_HOST=172.18.0.1|VIA_PORT=5061
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:
2021-10-29 05:11:54.936<LHO-1635483207-647f4d36>OUT-BYE-ALEG|CALL_ID=mGI87hGaVX
→ |CODE=200|CSEQ=1|FROM_URI=sip:5000@192.168.1.5
→ |REMOTE_IP=192.168.1.5|REMOTE_PORT=5063
→ |REQUEST_AT=2021-10-29 05:11:54.928|RESPONSE_AT=2021-10-29 05:11:54.936
→ |TO_URI=sip:665577@192.168.1.5|TRANSPORT=UDP|VIA_BRANCH=z9hG4bK1686106231|VIA_HOST=192.168.1.5|VIA_PORT=5061
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:
2021-10-29 05:11:54.935<LHO-1635483207-647f4d36>OUT-BYE-BLEG|CALL_ID=1685885286@192.168.1.5
→ |CODE=200|CSEQ=2|FROM_URI=sip:665577@192.168.1.5
→ |REMOTE_IP=192.168.1.5|REMOTE_PORT=5064
→ |REQUEST_AT=2021-10-29 05:11:54.928|RESPONSE_AT=2021-10-29 05:11:54.935
→ |TO_URI=sip:9991578@192.168.1.5:5064|TRANSPORT=UDP|VIA_BRANCH=z9hG4bK1686106230|VIA_HOST=192.168.1.5|VIA_PORT=5061
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:
2021-12-24 00:32:41.020<LHO-1640305092-1c467418>OUT-ACK-ALEG|CALL_ID=GFJun2nXg3X
→ |CSEQ=21|FROM_URI=sip:665566@192.168.1.5
→ |REMOTE_IP=192.168.1.5|REMOTE_PORT=5064
→ |TO_URI=sip:400000@192.168.1.5|TRANSPORT=UDP|VIA_BRANCH=z9hG4bK.FJun2n62V|VIA_HOST=192.168.1.5|VIA_PORT=5061
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:
2021-12-24 00:32:41.020<LHO-1640305092-1c467418>OUT-ACK-BLEG|CALL_ID=GFJun2nXg3X
→ |CSEQ=21|FROM_URI=sip:665566@192.168.1.5
→ |REMOTE_IP=192.168.1.5|REMOTE_PORT=5064
→ |TO_URI=sip:400000@192.168.1.5|TRANSPORT=UDP|VIA_BRANCH=z9hG4bK.FJun2n62V|VIA_HOST=192.168.1.5|VIA_PORT=5061
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:
2024-01-24 21:10:29.187<kirby~LHO~1706130606~4aebda6a>OUT-PRACK-ALEG|CALL_ID=1257548815@192.168.68.7
→ |CODE=200|CSEQ=1|FROM_URI=sip:666666@192.168.68.7|REMOTE_IP=192.168.68.7|REMOTE_PORT=5061|
→ REQUEST_AT=2024-01-24 21:10:29.184|RESPONSE_AT=2024-01-24 21:10:29.187|RTAG=1256812568|TO_URI=sip:4000@192.168.68.7:5061
→ |TRANSPORT=udp|VIA_BRANCH=z9hG4bK1256763236|VIA_HOST=192.168.68.7|VIA_PORT=5061
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:
2024-01-24 21:10:29.187<kirby~LHO~1706130606~4aebda6a>OUT-PRACK-BLEG|CALL_ID=1257548815@192.168.68.7
→ |CODE=200|CSEQ=1|FROM_URI=sip:666666@192.168.68.7|REMOTE_IP=192.168.68.7|REMOTE_PORT=5061|
→ REQUEST_AT=2024-01-24 21:10:29.184|RESPONSE_AT=2024-01-24 21:10:29.187|RTAG=1256812568|TO_URI=sip:4000@192.168.68.7:5061
→ |TRANSPORT=udp|VIA_BRANCH=z9hG4bK1256763236|VIA_HOST=192.168.68.7|VIA_PORT=5061