thegoodfellas/blogset-br huggingface dataset:
If an incoming request contains a Supported header field with a value 'timer' and a Session Expires header field, the UAS MAY reject the INVITE request with a 422 (Session Interval Too Small) response if the session interval in the Session-Expires header field is smaller than the minimum interval defined by the UAS' local policy. When sending the 422 response, the UAS MUST include a Min-SE header field with the value of its minimum interval. This minimum interval MUST NOT be lower than 90 seconds. If the UAS wishes to accept the request, it copies the value of the Session-Expires header field from the request into the 2xx response.Donovan & Rosenberg Standards Track [Page 15] RFC 4028 Session Timer April 2005 The UAS response MAY reduce its value but MUST NOT set it to a duration lower than the value in the Min-SE header field in the request, if it is present; otherwise the UAS MAY reduce its value but MUST NOT set it to a duration lower than 90 seconds. The UAS MUST NOT increase the value of the Session-Expires header field. If the incoming request contains a Supported header field with a value 'timer' but does not contain a Session-Expires header, it means that the UAS is indicating support for timers but is not requesting one. The UAS may request a session timer in the 2XX response by including a Session-Expires header field. The value MUST NOT be set to a duration lower than the value in the Min-SE header field in the request, if it is present. The UAS MUST set the value of the refresher parameter in the Session-Expires header field in the 2xx response. This value specifies who will perform refreshes for the dialog. The value is based on the value of this parameter in the request, and on whether the UAC supports the session timer extension. The UAC supports the extension if the 'timer' option tag was present in a Supported header field in the request. Table 2 defines how the value in the response is set. A value of 'none' in the 2nd column means that there was no refresher parameter in the request. A value of 'NA' in the third column means that this particular combination shouldn't happen, as it is disallowed by the protocol. UAC supports? refresher parameter refresher parameter in request in response ------------------------------------------------------- N none uas N uac NA N uas NA Y none uas or uac Y uac uac Y uas uas Table 2: UAS Behavior The fourth row of Table 2 describes a case where both the UAC and UAS support the session timer extension, and where the UAC did not select who will perform refreshes. This allows the UAS to decide whether it or the UAC will perform the refreshes. However, as the table indicates, the UAS cannot override the UAC's choice of refresher, if it made one. If the refresher parameter in the Session-Expires header field in the 2xx response has a value of 'uac', the UAS MUST place a Require header field into the response with
the value 'timer'. This isDonovan & Rosenberg Standards Track [Page 16] RFC 4028 Session Timer April 2005 because the uac is performing refreshes and the response has to be processed for the UAC to know this. If the refresher parameter in the 2xx response has a value of 'uas' and the Supported header field in the request contained the value 'timer', the UAS SHOULD place a Require header field into the response with the value 'timer'. In this case, the UAC is not refreshing, but it is supposed to send a BYE if it never receives a refresh. Since the call will still succeed without the UAC sending a BYE, insertion of the Require is a SHOULD here, and not a MUST. Just like the UAC, the UAS stores state for the session timer. This state includes the session interval, the session expiration, and the identity of the refresher. This state is bound to the dialog used to set up the session. The session interval is set to the value of the delta-time from the Session-Expires header field in the most recent 2xx response to a session refresh request on that dialog. It also remembers whether it or its peer is the refresher on the dialog, based on the value of the refresher parameter from the most recent 2xx response to a session refresh request on that dialog. If the most recent 2xx response had no Session-Expires header field, there is no session expiration, and no refreshes have to be performed. If the UAS must refresh the session, it computes the session expiration. The session expiration is the time of transmission of the last 2xx response to a session refresh request on that dialog plus the session interval. If UA wishes to continue with the session beyond the session expiration, it MUST generate a refresh before the session expiration. It is RECOMMENDED that this refresh be sent once half the session interval has elapsed. Additional procedures for this refresh are described in Section 10.10. Performing Refreshes The side generating a refresh does so according to the UAC procedures defined in Section 7. Note that only a 2xx response to a session refresh request extends the session expiration. This means that a UA could attempt a refresh and receive a 422 response with a Min-SE header field that contains a value much larger than the current session interval. The UA will still have to send a session refresh request before the session expiration (which has not changed), even though this request will contain a value of the Session-Expires that is much larger than the current session interval. If the session refresh request transaction times out or generates a 408 or 481 response, then the UAC sends a BYE request as per Section 12.2.1.2 of RFC 3261 [2]. If the session refresh request does not generate a 2xx response (and, as a result, the session is not refreshed), and a response other than 408 or 481 is received, the UACDonovan & Rosenberg Standards Track [Page 17] RFC 4028 Session Timer April 2005 SHOULD follow
the rules specific to that response code and retry if possible. For example, if the response is a 401, the UAC would retry the request with new credentials. However, the UAC SHOULD NOT continuously retry the request if the server indicates the same error response. Similarly, if the side not performing refreshes does not receive a session refresh request before the session expiration, it SHOULD send a BYE to terminate the session, slightly before the session expiration. The minimum of 32 seconds and one third of the session interval is RECOMMENDED. Firewalls and NAT ALGs may be very unforgiving about allowing SIP traffic to pass after the expiration time of the session. This is why the BYE should be sent before the expiration.11. Security Considerations The session timer introduces the capability of a proxy or UA element to force compliant UAs to send refreshes at a rate of the element's choosing. This introduces the possibility of denial-of-service attacks with significant amplification properties. These attacks can be launched from 'outsiders' (elements that attempt to modify messages in transit) or by 'insiders' (elements that are legitimately in the request path but are intent on doing harm). Fortunately, both cases are adequately handled by this specification.11.1. Inside Attacks This introduces the possibility of rogue proxies or UAs introducing denial-of-service attacks. However, the mechanisms in this specification prevent that from happening. First, consider the case of a rogue UAC that wishes to force a UAS to generate refreshes at a rapid rate. To do so, it inserts a Session-Expires header field into an INVITE with a low duration and a refresher parameter equal to uas. Assume it places a Supported header field into the request. The UAS or any proxy that objects to this low timer will reject the request with a 422, thereby preventing the attack. If no Supported header field was present, the proxies will insert a Min-SE header field into the request before forwarding it. As a result, the UAS will not choose a session timer lower than the minimum allowed by all elements on the path. This too prevents the attack. Next, consider the case of a rogue UAS that wishes to force a UAC to generate refreshes at a rapid rate. In that case, the UAC has to support session timer. The initial INVITE arrives at the rogue UAS,Donovan & Rosenberg Standards Track [Page 18] RFC 4028 Session Timer April 2005 which returns a 2xx with a very small session interval. The UAC uses this timer and quickly sends a refresh. Section 7.4 requires that the UAC copy the current session interval into the Session-Expires header field in the request. This enables the proxies to see the current value. The proxies will reject this request and provide a Min-SE with a higher minimum, which the UAC will then use. Note, that if the proxies did not reject the request, but rather proxied the request with a Min-SE header field, an attack would still be possible. The UAS could discard this header field in a 2xx response and force the UAC to
continue to generate rapid requests. In a similar fashion, a rogue proxy cannot force either the UAC or UAS to generate refreshes unless the proxy remains on the signaling path and sees every request and response.11.2. Outside Attacks An element that can observe and modify a request or response in transit can force rapid session refreshes. To prevent this, requests and responses have to be protected by message integrity. Since the session timer header fields are not end-to-end and are manipulated by proxies, the SIP S/MIME capabilities are not suitable for this task. Rather, integrity has to be protected by using hop-by-hop mechanisms. As a result, it is RECOMMENDED that an element send a request with a Session-Expires header field or a Supported header field with the value 'timer' by using TLS. As adequate protection is obtained only if security is applied on each hop, it is RECOMMENDED that the SIPS URI scheme be used in conjunction with this extension. This means that proxies that record-route and request session timer SHOULD record-route with a SIPS URI. A UA that inserts a Session-Expires header into a request or response SHOULD include a Contact URI that is a SIPS URI.12. IANA Considerations This extension defines two new header fields, a new response code, and a new option tag. SIP [2] defines IANA procedures for registering these.12.1. IANA Registration of Min-SE and Session-Expires Header Fields The following is the registration for the Min-SE header field: RFC Number: RFC 4028 Header Name: Min-SE Compact Form: noneDonovan & Rosenberg Standards Track [Page 19] RFC 4028 Session Timer April 2005 The following is the registration for the Session-Expires header field: RFC Number: RFC 4028 Header Name: Session-Expires Compact Form: x12.2. IANA Registration of the 422 (Session Interval Too Small) Response Code The following is the registration for the 422 (Session Interval Too Small) response code: Response Code: 422 Default Reason Phrase: Session Interval Too Small RFC Number: RFC 402812.3. IANA Registration of the 'timer' Option Tag The following is the registration for the 'timer' option tag: Name: timer Description: This option tag is for support of the session timer extension. Inclusion in a Supported header field in a request or response indicates that the UA can perform refreshes according to that specification. Inclusion in a Require header in a request means that the UAS must understand the session timer extension to process the request. Inclusion in a Require header field in a response indicates that the UAC must look for the Session-Expires header field in the response and process it accordingly.13. Example Call Flow Example Session Timer Flow Alice Proxy P1 Proxy P2 Bob |(1) INVITE | | | |SE: 50 | | | |----------->| | | |(2) 422 | | | |MSE: 3600 | | | |<-----------| | | |(3) ACK | | | |----------->| | | |(4) INVITE | | | |SE:3600 | | | |MSE:3600 | | | |----------->| | |Donovan & Rosenberg Standards Track [Page 20] RFC 4028 Session Timer April 2005 | |(5) INVITE | | | |SE:3600 | | | |MSE:3600 |
| | |----------->| | | |(6) 422 | | | |MSE:4000 | | | |<-----------| | | |(7) ACK | | | |----------->| | |(8) 422 | | | |MSE:4000 | | | |<-----------| | | |(9) ACK | | | |----------->| | | |(10) INVITE | | | |SE:4000 | | | |MSE:4000 | | | |----------->| | | | |(11) INVITE | | | |SE:4000 | | | |MSE:4000 | | | |----------->| | | | |(12) INVITE | | | |SE:4000 | | | |MSE:4000 | | | |----------->| | | |(13) 200 OK | | | |SE:4000 | | | |<-----------| | |(14) 200 OK | | | |SE:4000 | | | |<-----------| | |(15) 200 OK | | | |SE:4000 | | | |<-----------| | | |(16) ACK | | | |----------->| | | | |(17) ACK | | | |------------------------>| |(18) UPDATE | | | |SE:4000 | | | |----------->| | | | |(19) UPDATE | | | |SE:4000 | | | |------------------------>| | |(20) 200 OK | | | |SE:4000 | | | |<------------------------|Donovan & Rosenberg Standards Track [Page 21] RFC 4028 Session Timer April 2005 |(21) 200 OK | | | |SE:4000 | | | |<-----------| | | | |(22) BYE | | | |<------------------------| |(23) BYE | | | |<-----------| | | | |(24) 408 | | | |------------------------>| Figure 1: Example Session Timer Flow Figure 1 gives an example of a call flow that makes use of the session timer. In this example, both the UAC and UAS support the session timer extension. The initial INVITE request generated by the UAC, Alice (message 1), might look like this: INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 Supported: timer Session-Expires: 50 Max-Forwards: 70 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) This request indicates that Alice supports the session timer, and is requesting session refreshes every 50 seconds. This arrives at the first proxy, P1. This session interval is below the minimum allowed value of 3600. So P1 rejects the request with a 422 (message 2): SIP/2.0 422 Session Interval Too Small Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 Min-SE: 3600 To: Bob ;tag=9a8kz From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITEDonovan & Rosenberg Standards Track [Page 22] RFC 4028 Session Timer April 2005 This response contains a Min-SE header field with the value 3600. Alice then retries the request. This time, the request contains a Min-SE header, as Alice has received a 422 for other INVITE requests with the same Call-ID. The new request (message 4) might look like this: INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 Supported: timer Session-Expires: 3600 Min-SE: 3600 Max-Forwards: 70 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314160 INVITE Contact: Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) Proxy P1 record-routes. Since the session interval is now acceptable to it, it forwards the request to P2 (message 5). However, the session interval is below its minimum configured amount of 4000. So it rejects the request with a 422 response code (message
3264, June 2002.Donovan & Rosenberg Standards Track [Page 25] RFC 4028 Session Timer April 200515.2. Informative References [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [6] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.Authors' Addresses Steve Donovan Cisco Systems, Inc. 2200 E. President George Bush Turnpike Richardson, Texas 75082 US EMail: srd@cisco.com Jonathan Rosenberg Cisco Systems, Inc. 600 Lanidex Plaza Parsippany, NJ 07054 US EMail: jdrosen@cisco.comDonovan & Rosenberg Standards Track [Page 26] RFC 4028 Session Timer April 2005Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.
ISDN Cause CodesCause No. 0This is usually given by the router when none of the other codes apply. This cause usually occurs in the same type of situations as cause 1, cause 88, and cause 100.Cause No. l - Unallocated (unassigned) number.This cause indicates that the destination requested by the calling user cannot be reached because, although the number is in a valid format, it is not currently assigned (allocated).What it usually means:The SPIDS may be incorrectly entered in the router or the Telco switch, giving a SPID failure in the router logs.The ISDN phone number being dialed by the router is invalid and the telco switch cannot locate the number to complete the call, as it is invalid.On long distance calls, the call cannot be properly routed to its destination.Cause No. 2 - No route to specified transit network (national use).This cause indicates that the equipment sending this cause has received a request to route the call through a particular transit network which it does not recognize. The equipment sending this cause does not recognize the transit network either because the transit network does not exist or because that particular transit network not serve the equipment which is sending this cause.Cause No. 3 - No route to destination.This cause indicates that the called party cannot be reached because the network through which the call has been routed does not serve the destination desired. This cause is supported on a network dependent basis.Cause No. 4 - send special information tone.This cause indicates that the called party cannot be reached for reasons that are of a long term nature and that the special information tone should be returned to the calling party.Cause No. 5 - misdialed trunk prefix (national use).This cause indicates the erroneous inclusion of a trunk prefix in the called party number. This number is to sniped from the dialed number being sent to the network by the customer premises equipment.Cause No. 6 - channel unacceptable.This cause indicates that the channel most recently identified is not acceptable to the sending entity for use in this call.Cause No. 7 - call awarded. being delivered in an established channel.This cause indicates that the user has been awarded the incoming call and that the incoming call is being connected to a channel already established to that user for similar calls (e.g. packet-mode x.25 virtual calls).Cause No. 8 - preemption.This cause indicates the call is being preempted.Cause No. 9 - preemption - circuit reserved for reuse.This cause indicates that the call is being preempted and the circuit is reserved for reuse by the preempting exchange.Cause No. 16 - normal call clearing.This cause indicates that the call is being cleared because one of the users involved in the call has requested that the call be cleared.What it means:This could be almost anything; it is the vaguest of the cause codes. The call comes down normally, but the reasons for it could be: Bad username or passwordRouter's settings do not match what is expected by the remote end.Telephone line problems.Hung session on remote end.Cause No. 17 -
user busy.This cause is used to indicate that the called party is unable to accept another call because the user busy condition has been encountered. This cause value may be generated by the called user or by the network. In the case of user determined user busy it is noted that the user equipment is compatible with the call.What is means:Calling end is busy.Cause No. 18 - no user responding.This cause is used when a called party does not respond to a call establishment message with either an alerting or connect indication within the prescribed period of time allocated.What it means:The equipment on the other end does not answer the call. Usually this is a misconfiguration on the equipment being called.Cause No. 19 - no answer from user (user alerted).This cause is used when the called party has been alerted but does not respond with a connect indication within a prescribed period of time. Note - This cause is not necessarily generated by Q.931 procedures but may be generated by internal network timers.Cause No. 20 - subscriber absent.This cause value is used when a mobile station has logged off. Radio contact is not obtained with a mobile station or if a personal telecommunication user is temporarily not addressable at any user-network interface.Cause No. 21 - call rejected.This cause indicates that the equipment sending this cause does not wish to accept this call. although it could have accepted the call because the equipment sending this cause is neither busy nor incompatible. This cause may also be generated by the network, indicating that the call was cleared due to a supplementary service constraint. The diagnostic field may contain additional information about the supplementary service and reason for rejection.What it means:This is usually a telco issue. The call never reaches the final destination, which can be caused by a bad switch translation, or a misconfiguration on the equipment being called.Cause No. 22 - number changed.This cause is returned to a calling party when the called party number indicated by the calling party is no longer assigned. The new called party number may optionally be included in the diagnostic field. If a network does not support this cause, cause no. 1, unallocated (unassigned) number shall be used.Cause No. 26 - non-selected user clearing.This cause indicates that the user has not been awarded the incoming call.Cause No. 27 - destination out of order.This cause indicates that the destination indicated by the user cannot be reached because the interface to the destination is not functioning correctly. The term "not functioning correctly" indicates that a signal message was unable to be delivered to the remote party; e.g., a physical layer or data link layer failure at the remote party or user equipment off-line.Cause No. 28 - invalid number format (address incomplete).This cause indicates that the called party cannot be reached because the called party number is not in a valid format or is not complete.Cause No. 29 - facilities rejected.This cause is returned when a supplementary service requested by the user cannot be provide by the network.Cause No. 30