sip media · published

Troubleshooting SIP 408 Request Timeout and calls that get no response

Verified 2026-10-02 · 53 sources · tier 1–3

Also known as SIP 408 Request Timeout, SIP INVITE timeout.

SIP 408 Request Timeout can come from a SIP transaction that gives up after a timer expires, and it can also come from a gateway that maps PSTN cause 18 (no user responding) to 408 1038. Microsoft Teams Direct Routing and Twilio Elastic SIP Trunking each document 408 failures in which a peer did not respond within the allotted time 1653.

How transaction timers produce a timeout

The INVITE client transaction state machine, as redrawn in RFC 6026, shows what happens in the Calling state when Timer B fires or a transport error occurs: the transaction informs the transaction user and terminates 48.

For a non-INVITE client transaction in the Trying state, Timer E starts at T1 and doubles each time it fires, up to a cap of T2 46. After a provisional response, Timer E retransmits every T2 46. The non-INVITE transaction timeout, Timer F, is 64*T1, which is 32 seconds with default timers 47.

RFC 4320 forbids a transaction-stateful SIP element from sending a 408 response to a non-INVITE request 43. The RFC gives this reason: a 408 to a non-INVITE request always arrives after the requester's own Timer F has expired, so the requester gains nothing from it 42. RFC 4321 observed that most endpoints sent a 408 for a non-INVITE request 64*T1 after receiving it if they had not already sent a final response 45. RFC 4321 also observed that such a 408 reaches the upstream element too late to be useful 45.

408 and 504 from PSTN interworking

RFC 3398 maps ISUP cause 18 (no user responding) received from the PSTN to SIP 408 Request Timeout 38. A different rule applies when ISUP timer T7 expires before an ACM or CON is received: RFC 3398 says the gateway should then send 504 Server Timeout to the SIP side, not 408 39.

Responses that are sent but never arrive

Without rport, a SIP server sends UDP responses to the source address of the request but to the port in the top Via 41. That port does not match the NAT binding the request created, so the response may never reach a client behind NAT 41. With rport, the server records the source port of the request in rport and its source IP in received 40. The server then sends the UDP response to that address and port, from the address and port on which the request arrived 40.

Under RFC 3263, if a client finds no NAPTR or SRV records and no transport is specified, it should use UDP for a sip URI and TCP for a sips URI 36.

Overload, delay, and unresponsive next hops

Over UDP, SIP retransmits messages that an overloaded server dropped or delayed, which increases the offered load on that server 51. RFC 6357 notes that a significant increase in delay at an overloaded SIP server can cause time-outs and retransmissions that make the overload worse 50. RFC 6357 also states that the built-in 503 Service Unavailable mechanism cannot prevent SIP server overload or congestion collapse, and that it may shift load between servers 49.

RFC 4321 notes that a SIP proxy cannot reliably tell a failed element from one that is only slow to respond, which complicates blacklisting of unresponsive next hops 44.

Failover after a timeout

RFC 3263 directs a SIP client to try the next server from its DNS-derived list in three cases: a transaction timeout, a transport failure, or a received 503 37. When failing over, the client should send a new request that is identical to the previous one except for a new Via branch ID, which makes it a new SIP transaction 35.

Teams Direct Routing retries an outbound call on another SBC in the route when it receives a SIP final response listed in FailoverResponseCodes 18. The default FailoverResponseCodes values are 408, 503 and 504 18. This response-code failover happens only if the SBC has not sent a non-100 provisional response, which avoids double ringing 22. A trunk may also fail to connect because of a refused connection, a TLS timeout, or another network-level issue 21. In that case Microsoft retries the same trunk from a different Microsoft datacenter, which may be in another region 21. Microsoft's example of a trunk connection failure is an SBC access control list that omits the IP addresses of some Microsoft Direct Routing datacenters 23.

Platform differences

Microsoft Teams Direct Routing

Microsoft code with SIP 408	Meaning
1106	The callee answered, but the SBC did not acknowledge Microsoft's 200 OK in the allotted time 14
500001	The SBC did not respond to the INVITE within the gateway failover timer 16
560408	The SBC itself returned 408 (user did not respond) 17
0	Establishment timeout, which indicates a client error 13

The gateway failover timer is set by the FailoverTimeSeconds parameter of Set-CsOnlinePSTNGateway, and its default is 10 seconds 19. Microsoft says 500001/408 usually occurs in regions with long PSTN setup times 20. For those cases, Microsoft suggests raising the failover timer to 20 seconds, either in the affected regions or on all Direct Routing trunks 20.

Twilio Elastic SIP Trunking

Twilio states that an origination call failing with 408 (or 504) Request Timeout means Twilio is getting no response from the customer's SIP infrastructure 53.

Cisco IOS/IOS XE voice gateways and CUBE

The sip-ua timers trying command sets how long the SIP UA waits for a 100 response to an INVITE 5. Its default is 500 ms and its range is 100 to 1000 ms 5.

The sip-ua retry invite command sets how many INVITE retransmissions are sent before the call is considered failed 2. Its range is 1 to 10 and its default is 6 2.

The timers expires command sets how long an INVITE is valid 4. Its default is 180000 ms and its range is 60000 to 300000 ms 4.

On CUBE, show sip-ua timers displays the current SIP UA timer values, such as trying, expires, connect and disconnect 3.

Oracle Communications SBC

The global trans-expire parameter is the transaction expire timeout (Timer B) 26. The same parameter is used for Timers D, F, H and J, and its default is 32 seconds 26.

The invite-expire parameter (Timer C) defaults to 180 seconds after a provisional response 25. If no final response arrives before it expires, the INVITE is cancelled 25. The timer restarts on each further provisional response 25.

The init-timer parameter corresponds to RFC 3261 T1, with a default of 500 ms 24. The max-timer parameter corresponds to T2, with a default of 4000 ms 24. The UDP retransmission interval doubles after each retransmission 24.

Kamailio tm module

If no reply at all is received for a request before fr_timer expires, the transaction is terminated with a 408 that is handled in failure route 10. The default for fr_timer is 30000 ms 10.

The fr_inv_timer parameter bounds the wait for a final INVITE reply after a provisional reply 9. Its default is 120000 ms, and by default it restarts on each provisional reply 9.

The noisy_ctimer parameter, enabled by default, makes INVITE transactions that time out on the FR INV timer always be replied to 11.

Retransmissions start at retr_timer1 (default 500 ms) and increase up to retr_timer2 (default 4000 ms) 12. The max_noninv_lifetime parameter defaults to 32000 ms, and max_inv_lifetime defaults to 180000 ms 12.

Asterisk res_pjsip

The res_pjsip system object exposes two timers 1. The timer_t1 option is the initial SIP retransmission timer in ms, and timer_b is the SIP INVITE transaction timeout in ms 1.

Diagnosing it

Twilio origination 408s: Confirm the trunk's Origination SIP URI, and check that the firewall and PBX allow Twilio's IP addresses and ports 52.
Teams 560408: Microsoft advises reviewing call records with CallEndSubReason 560408 for trends by called number or destination country, to find a downstream problem 17.
Teams code 0 with 408: Microsoft advises checking the network connection between the client and the Teams service 13.
Clients behind NAT that get no response: Check whether the server returns UDP responses to the port in the top Via instead of the request's source port, because that response may never reach the client 41.
Gateway timeouts: Check whether the 408 maps from ISUP cause 18 38. Under RFC 3398, an ISUP T7 expiry should produce 504 instead 39.

Applicability

Applies to: Microsoft Teams Direct Routing, Cisco Unified Border Element, Oracle Communications Session Border Controller, Kamailio, Sangoma Asterisk, and Twilio Elastic SIP Trunking. Deployments: on-premises, multi-tenant, and any. Sources checked 2026-10-02. Microsoft's SIP 408 response-code guidance applies to Teams Direct Routing PSTN calls, not to Calling Plan or Operator Connect deployments 15. The Twilio guidance covers Elastic SIP Trunking origination calls 53.

What remains uncertain

How to tell, from a signaling trace, a 408 mapped from a PSTN cause from a 408 generated by a local transaction timer is not covered by the sources below. Whether firewall or router SIP ALG behavior contributes to 408 timeouts is not covered by the sources below. Recommended timer values for platforms other than Teams Direct Routing are not covered by the sources below.

Sources

1
In Asterisk res_pjsip, the system object exposes timer_t1 (initial SIP retransmission timer in ms) and timer_b (SIP INVITE transaction timeout in ms).
res_pjsip - Asterisk Documentation · Configuration object 'system', options timer_t1 and timer_b · Checked 2026-10-02
2
On Cisco IOS/IOS XE voice gateways and CUBE, the sip-ua 'retry invite' command sets how many INVITE retransmissions are sent before the call is considered failed; range 1 to 10, default 6.
Cisco IOS Voice Command Reference - K through R - R · Command entry 'retry invite' · Checked 2026-10-02
3
On CUBE, 'show sip-ua timers' displays the current SIP UA timer values such as trying, expires, connect and disconnect.
Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Basic SIP Configuration · Basic SIP Configuration chapter, SIP UA timer verification example · Checked 2026-10-02
4
On Cisco IOS/IOS XE voice gateways and CUBE, 'timers expires' sets how long an INVITE is valid; default 180000 ms, range 60000 to 300000 ms.
Cisco IOS Voice Command Reference - T through Z - timeouts call-disconnect through timing clear-wait · Command entry 'timers expires' · Checked 2026-10-02
5
On Cisco IOS/IOS XE voice gateways and CUBE, the sip-ua 'timers trying' command sets how long the SIP UA waits for a 100 response to an INVITE; default 500 ms, range 100 to 1000 ms.
Cisco IOS Voice Command Reference - T through Z - timeouts call-disconnect through timing clear-wait · Command entry 'timers trying' · Checked 2026-10-02
6
A 408 that the caller's own UA or proxy reports after a run of retransmitted INVITEs with no response in the trace was most likely generated locally on transaction timeout, so the trace point where responses stop, not the 408, locates the fault.inferred
RFC 3261 — SIP: Session Initiation Protocol · Section 8.1.3.1 (timeout treated as 408); see also Kamailio tm fr_timer · Checked 2026-10-02
7
Because the Teams Direct Routing failover timer defaults to 10 seconds, an SBC that answers slowly can see Microsoft abandon or fail over the INVITE well before the 32-second RFC Timer B would expire.inferred
SIP 408 and Microsoft response codes - Microsoft Teams · Section '500001 408 Gateway (SBC) failover timer expired' compared with RFC 3261 17.1.1.2 · Checked 2026-10-02
8
With RFC 3261 defaults over UDP, an unanswered INVITE is expected to be retransmitted at roughly 0.5, 1.5, 3.5, 7.5, 15.5 and 31.5 seconds after the first send (seven transmissions) before Timer B ends the transaction at 32 seconds; Cisco's default 'retry invite 6' with 'timers trying 500' produces the same count.inferred
RFC 3261 — SIP: Session Initiation Protocol · Section 17.1.1.2 (Timer A doubling, Timer B 64*T1), combined with Cisco 'retry invite' and 'timers trying' entries · Checked 2026-10-02
9
In Kamailio's tm module, fr_inv_timer (default 120000 ms) bounds the wait for a final INVITE reply after a provisional reply and by default restarts on each provisional reply.
TM Module · Parameters fr_inv_timer and restart_fr_on_each_reply · Checked 2026-10-02
10
In Kamailio's tm module, if no reply at all is received for a request before fr_timer expires (default 30000 ms), the transaction is terminated with a 408 handled in failure route.
TM Module · Parameter fr_timer · Checked 2026-10-02
11
In Kamailio's tm module, noisy_ctimer (default enabled) makes INVITE transactions that time out on the FR INV timer always be replied to.
TM Module · Parameter noisy_ctimer · Checked 2026-10-02
12
In Kamailio's tm module, retransmissions start at retr_timer1 (default 500 ms) and increase up to retr_timer2 (default 4000 ms); max_noninv_lifetime defaults to 32000 ms and max_inv_lifetime to 180000 ms.
TM Module · Parameters retr_timer1, retr_timer2, max_noninv_lifetime, max_inv_lifetime · Checked 2026-10-02
13
In Teams Direct Routing, Microsoft code 0 with SIP 408 (establishment timeout) indicates a client error, and Microsoft advises checking the network connection between the client and the Teams service.
SIP 408 and Microsoft response codes - Microsoft Teams · Section '0 408 Establishment timeout' · Checked 2026-10-02
14
In Teams Direct Routing, Microsoft response code 1106 with SIP 408 means the callee answered but the SBC did not acknowledge Microsoft's 200 OK in the allotted time.
SIP 408 and Microsoft response codes - Microsoft Teams · Section '1106 408 An acknowledgement was not received for the call acceptance in the allotted time' · Checked 2026-10-02
15
Microsoft's SIP 408 response-code guidance applies to Teams Direct Routing PSTN calls and not to Calling Plan or Operator Connect deployments.
SIP 408 and Microsoft response codes - Microsoft Teams · Opening note · Checked 2026-10-02
16
In Teams Direct Routing, Microsoft response code 500001 with SIP 408 means the SBC did not respond to the INVITE within the gateway failover timer.
SIP 408 and Microsoft response codes - Microsoft Teams · Section '500001 408 Gateway (SBC) failover timer expired' · Checked 2026-10-02
17
In Teams Direct Routing, code 560408 means the SBC itself returned 408 (user did not respond); Microsoft advises reviewing call records with CallEndSubReason 560408 for trends by called number or destination country to find a downstream problem.
SIP 408 and Microsoft response codes - Microsoft Teams · Section '560408 408 SBC indicated that the user did not respond (request timeout)' · Checked 2026-10-02
18
Teams Direct Routing retries an outbound call on another SBC in the route for SIP final responses listed in FailoverResponseCodes, whose default values are 408, 503 and 504.
Trunk failover on outbound calls - Microsoft Teams · Section 'Failover of specific SIP codes received from the Session Border Controller (SBC)' · Checked 2026-10-02
19
The Teams Direct Routing gateway failover timer is set by the FailoverTimeSeconds parameter of Set-CsOnlinePSTNGateway and defaults to 10 seconds.
SIP 408 and Microsoft response codes - Microsoft Teams · Section '500001 408 Gateway (SBC) failover timer expired' · Checked 2026-10-02
20
Microsoft says 500001/408 usually occurs in regions with long PSTN setup times and suggests raising the failover timer to 20 seconds in those regions or on all Direct Routing trunks.
SIP 408 and Microsoft response codes - Microsoft Teams · Section '500001 408 Gateway (SBC) failover timer expired' · Checked 2026-10-02
21
If a Direct Routing trunk cannot be connected (refused connection, TLS timeout or other network-level issue), Microsoft retries the same trunk from a different Microsoft datacenter, possibly in another region.
Trunk failover on outbound calls - Microsoft Teams · Section 'Failover on network errors' · Checked 2026-10-02
22
Teams Direct Routing response-code failover happens only if the SBC has not sent a non-100 provisional response, to avoid double ringing.
Trunk failover on outbound calls - Microsoft Teams · Section 'Failover of specific SIP codes received from the Session Border Controller (SBC)', first paragraph · Checked 2026-10-02
23
Microsoft gives as an example of trunk connection failure an SBC access control list that omits the IP addresses of some Microsoft Direct Routing datacenters.
Trunk failover on outbound calls - Microsoft Teams · Section 'Failover on network errors', second paragraph · Checked 2026-10-02
24
On the Oracle Communications SBC, init-timer corresponds to RFC 3261 T1 (default 500 ms) and max-timer to T2 (default 4000 ms); the UDP retransmission interval doubles after each retransmission.
Global SIP Timers · Global SIP Timers, parameters init-timer and max-timer · Checked 2026-10-02
25
On the Oracle Communications SBC, invite-expire (Timer C) defaults to 180 seconds after a provisional response; if no final response arrives the INVITE is cancelled, and the timer restarts on each further provisional response.
Global SIP Timers · Global SIP Timers, parameter invite-expire · Checked 2026-10-02
26
On the Oracle Communications SBC, the global trans-expire parameter is the transaction expire timeout (Timer B), also used for Timers D, F, H and J, with a default of 32 seconds.
Global SIP Timers · Global SIP Timers, parameter trans-expire · Checked 2026-10-02
27
RFC 3261 defines 408 Request Timeout as the server being unable to produce a response within a suitable amount of time, for example because it could not determine the location of the user in time.
RFC 3261 — SIP: Session Initiation Protocol · Section 21.4.9 408 Request Timeout · Checked 2026-10-02
28
A stateful proxy forwarding an INVITE runs Timer C, which must be greater than 3 minutes; if it fires without a final response the proxy cancels the branch or, absent a provisional response, treats it as a 408.
RFC 3261 — SIP: Session Initiation Protocol · Section 16.6 step 11 (Set timer C) and Section 16.8 Processing Timer C · Checked 2026-10-02
29
RFC 3261 recommends a default T1 (RTT estimate) of 500 ms and a T2 (maximum retransmit interval for non-INVITE requests and INVITE responses) of 4 seconds.
RFC 3261 — SIP: Session Initiation Protocol · Section 17.1.1.1 and Table 4 (Appendix A Timer Values) · Checked 2026-10-02
30
Over a reliable transport such as TCP or TLS, the INVITE client transaction does not retransmit the request, so a trace of a timed-out INVITE over TCP shows a single INVITE rather than a retransmission series.
RFC 3261 — SIP: Session Initiation Protocol · Section 17.1.1.2 Formal Description (Timer A only started for unreliable transport) · Checked 2026-10-02
31
Under RFC 3261 a UAC that receives a timeout error from its transaction layer treats it as if a 408 Request Timeout response had been received, so a 408 reported by a UAC need not have crossed the wire.
RFC 3261 — SIP: Session Initiation Protocol · Section 8.1.3.1 Transaction Layer Errors · Checked 2026-10-02
32
For an INVITE client transaction over an unreliable transport, Timer A starts at T1 and the retransmission interval doubles each time Timer A fires.
RFC 3261 — SIP: Session Initiation Protocol · Section 17.1.1.2 Formal Description · Checked 2026-10-02
33
RFC 3261 sets the INVITE transaction timeout, Timer B, to 64*T1, which is 32 seconds with the default T1 of 500 ms.
RFC 3261 — SIP: Session Initiation Protocol · Section 17.1.1.2 Formal Description; Table 4 timer summary · Checked 2026-10-02
34
Under RFC 3261 a fatal transport error (such as a fatal ICMP error over UDP or a TCP connection failure) is treated by the UAC as a 503 Service Unavailable, not as a 408.
RFC 3261 — SIP: Session Initiation Protocol · Section 8.1.3.1 Transaction Layer Errors · Checked 2026-10-02
35
When failing over to the next server, RFC 3263 says the client should send a new request identical to the previous one but with a new Via branch ID, making it a new SIP transaction.
RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers · Section 4.3 · Checked 2026-10-02
36
Under RFC 3263, if no NAPTR or SRV records are found and no transport is specified, a client should use UDP for a sip URI and TCP for a sips URI.
RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers · Section 4.1 Selecting a Transport Protocol · Checked 2026-10-02
37
RFC 3263 directs a SIP client to try the next server from its DNS-derived list when a transaction times out, when a transport failure occurs, or when a 503 is received.
RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers · Section 4.3 (failover text following port and address determination) · Checked 2026-10-02
38
RFC 3398 maps ISUP cause 18 (no user responding) received from the PSTN to SIP 408 Request Timeout.
RFC 3398: Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping · Section 7.2.4.1 ISUP cause to SIP status mapping table · Checked 2026-10-02
39
RFC 3398 says that when ISUP timer T7 expires before an ACM or CON is received, the gateway should send 504 Server Timeout to the SIP side, not 408.
RFC 3398: Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping · Section 7.1.3 ISUP T7 Expires; Section 7.2.2 · Checked 2026-10-02
40
With rport, the server records the request's source port in rport and source IP in received, and sends the UDP response to that address and port from the address and port the request arrived on.
RFC 3581: An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing · Section 4 Server Behavior · Checked 2026-10-02
41
Without rport, a SIP server returns UDP responses to the request's source address but to the port in the top Via, which does not match the NAT binding the request created, so the response may never reach a client behind NAT.
RFC 3581: An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing · Section 1 Introduction · Checked 2026-10-02
42
RFC 4320's rationale is that a 408 to a non-INVITE request always arrives after the requester's own Timer F has already expired, so the requester gains nothing from it.
RFC 4320: Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction · Section 2.2 · Checked 2026-10-02
43
RFC 4320 forbids a transaction-stateful SIP element from sending a 408 response to a non-INVITE request.
RFC 4320: Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction · Section 4.2 · Checked 2026-10-02
44
RFC 4321 notes that a SIP proxy cannot reliably distinguish an element that has failed from one that is merely slow to respond, which complicates blacklisting of unresponsive next hops.
RFC 4321: Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction · Section 1.3 · Checked 2026-10-02
45
RFC 4321 observes that most endpoints emit a 408 for a non-INVITE request 64*T1 after receiving it if no earlier final response was sent, and that such a 408 reaches the upstream element too late to be useful.
RFC 4321: Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction · Section 1.4 · Checked 2026-10-02
46
For a non-INVITE client transaction, Timer E starts at T1 and doubles on each firing while in Trying, capping at T2; after a provisional response it retransmits every T2.
RFC 4321: Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction · Section 1.2 · Checked 2026-10-02
47
The non-INVITE transaction timeout Timer F is 64*T1, which is 32 seconds with default timers.
RFC 4321: Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction · Section 1.2 · Checked 2026-10-02
48
The INVITE client transaction state machine as redrawn in RFC 6026 shows that from the Calling state, Timer B firing or a transport error leads to informing the transaction user and terminating.
RFC 6026: Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests · Section 8.4, updated Figure 5 (INVITE client transaction) · Checked 2026-10-02
49
RFC 6357 states that the built-in 503 Service Unavailable mechanism cannot prevent SIP server overload or congestion collapse and may shift load between servers.
RFC 6357: Design Considerations for Session Initiation Protocol (SIP) Overload Control · Section 1 Introduction · Checked 2026-10-02
50
RFC 6357 notes that significantly increased delay at an overloaded SIP server can lead to time-outs and retransmissions that make the overload worse.
RFC 6357: Design Considerations for Session Initiation Protocol (SIP) Overload Control · Section 8 · Checked 2026-10-02
51
Over UDP, SIP retransmits messages that an overloaded server dropped or delayed, increasing the offered load on the already overloaded server.
RFC 6357: Design Considerations for Session Initiation Protocol (SIP) Overload Control · Section 2 · Checked 2026-10-02
52
For origination 408s Twilio advises confirming the trunk's Origination SIP URI and checking that the firewall and PBX allow Twilio's IP addresses and ports.
Troubleshooting your Trunk · Origination section, solution list under the 408/504 problem · Checked 2026-10-02
53
Twilio states that an Elastic SIP Trunking origination call failing with 408 (or 504) Request Timeout means Twilio is getting no response from the customer's SIP infrastructure.
Troubleshooting your Trunk · Origination section, problem 'The call fails with a 408 Request Timeout error or 504 Request Timeout error' · Checked 2026-10-02

Documents

tier 1 standards and regulators

Cite this page

APA

WarmTransfer. (2026, October 2). Troubleshooting SIP 408 Request Timeout and calls that get no response. WarmTransfer. https://warmtransfer.net/knowledge/sip-408-timeout-troubleshooting

BibTeX

@misc{warmtransfer-sip-408-timeout-troubleshooting,
  title  = {Troubleshooting SIP 408 Request Timeout and calls that get no response},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/sip-408-timeout-troubleshooting},
  note   = {Verified 2026-10-02}
}