Internet DRAFT - draft-ranarang-sipping-middialog-sip-status
draft-ranarang-sipping-middialog-sip-status
Network Working Group R. Narang
Internet-Draft Cisco Systems Inc.
Intended status: Standards Track June 2006
Expires: December 3, 2006
Session Initiation Protocol (SIP) Mid-Dialog Status code for network
disconnection on one side of B2BUA
draft-ranarang-sipping-middialog-sip-status-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 3, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Narang Expires December 3, 2006 [Page 1]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
Abstract
This document defines a new SIP status code needed for communicating
about the network failure happening in signaling connection on one
side of the B2BUA to the other side of B2BUA on an established
dialog/session. The network failure condition MAY be detected by
session timers [rfc4028] or any other proprietary mechanism.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction and Overview . . . . . . . . . . . . . . . . . . 4
2.1. Simple Handling of the n/w failure . . . . . . . . . . . . 4
2.2. Optimized Handling . . . . . . . . . . . . . . . . . . . . 5
3. B2BUA detecting the network failure behavior . . . . . . . . . 6
3.1. B2BUA wants to remain in partial dialog for CDR . . . . . 6
3.1.1. UA4 is a non-refresher . . . . . . . . . . . . . . . . 6
3.1.2. UA4 is a refresher . . . . . . . . . . . . . . . . . . 6
3.2. B2BUA doesn't want to remain in partial dialog . . . . . . 6
4. B2BUA receiving the 450 status code behavior . . . . . . . . . 7
4.1. UA3 handling . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. UA2 handling . . . . . . . . . . . . . . . . . . . . . . . 7
5. Phone detecting the network failure behavior . . . . . . . . . 8
5.1. Phone2 is a Media Application . . . . . . . . . . . . . . 8
6. Phone receiving the 450 status code behavior . . . . . . . . . 9
6.1. 450 receipt in session refresh . . . . . . . . . . . . . . 9
6.2. 450 receipt in BYE's Reason header . . . . . . . . . . . . 9
7. Proxy's 450 status code behavior . . . . . . . . . . . . . . . 10
7.1. Call Stateful Proxy . . . . . . . . . . . . . . . . . . . 10
7.2. Transaction Stateful Proxy . . . . . . . . . . . . . . . . 10
7.3. Stateless Proxy . . . . . . . . . . . . . . . . . . . . . 10
8. Call Stateful Proxy Session Timeout handling . . . . . . . . . 11
9. IP-PSTN GW receiving the 450 status code behavior . . . . . . 12
10. NAT/ALG's 450 status code behavior . . . . . . . . . . . . . . 13
11. CDR logging of 450 status code . . . . . . . . . . . . . . . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12.1. IANA Registration of the 450 (Call in minimal state)
Response Code . . . . . . . . . . . . . . . . . . . . . . 15
13. Backward's compatibilty . . . . . . . . . . . . . . . . . . . 16
14. 450 (Call in minimal state) Definition . . . . . . . . . . . . 17
15. Security Considerations . . . . . . . . . . . . . . . . . . . 18
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Narang Expires December 3, 2006 [Page 2]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Narang Expires December 3, 2006 [Page 3]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
2. Introduction and Overview
Consider that a SIP session was established using an INVITE dialog
from phone1 to phone2 with B2BUA's in the path as per the following
topology:-
+----+ +---------+ +---------+ +----+
| +-+| |+-+ +-+| |+-+ +-+| |+-+ |
| | || dialog1 || | | || dialog2|| | | || dialog3|| | |
| |U||<-------->||U| |U||<------>||U| |U||<------>||U| |
| |A|| nw1 ||A| |A|| nw2 ||A| |A|| nw3 ||A| |
| |1|| ||2| |3|| ||4| |5|| ||6| |
| | || || | | || || | | || || | |
| +-+| |+-+ +-+| |+-+ +-+| |+-+ |
+----+ +---------+ +---------+ +----+
phone1 B2BUA1 B2BUA2 phone2
Figure 1
There will be an active INVITE dialogs between individual UA's.
Consider during session establishment, UA's have negotiated the
session timers on the individual INVITE dialogs as per [rfc4028].
The session timers are actively running for monitoring the liveliness
of the SIP session.
Note:- In the B2BUA configuration as above, the session timers are
independently negotiated for each individual dialog between UA's.
There is only one media session i.e from phone1 to phone2.
The session i.e media path from phone1 to phone2 could have been
established using a different network than the call signaling (i.e
dialog) path.
Consider 'nw3' as per above topology encounters a sudden network
failure condition. After session timeout for dialog3, the 'UA5' &
'UA6' will be able to detect this error condition.
2.1. Simple Handling of the n/w failure
A simple implementation of UA5 or UA6 would assume this as a critical
condition. The UA6 may stop the session (media) and give reorder
tone to the user. The UA5 would assume that sip session is also torn
down, so it will initiate tearing down the dialog2 towards B2BUA1 by
sending a BYE.
Narang Expires December 3, 2006 [Page 4]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
2.2. Optimized Handling
An optimized implementation at UA6 (phone2) would be to not assume
this as a critical problem for an active SIP media session between
phone1 & phone2. It could try its best to 'not' interrupt the active
media connection between phone2 and phone1. The UA6 MAY want to wait
for actual physical hang-up from the phone2 user.
An optimized implementation at B2BUA2 would be to not tear down an
active sip 'dialog2' towards B2BUA1 and instead communicate the
status of nw3's "out of order condition" which impacted dialog3.
The B2BUA1 on learning about dialog3 disconnection due to n/w
failure, could take an appropriate action whether to tear down the
'associated' SIP session towards UA1 or wait for normal hang-up from
phone1.
As it is described the requirement is to communicate the failure
status across the B2BUA about one SIP dialog 'dialog3' onto the
another SIP dialog 'dialog2' associated with the same SIP session.
Currently in SIP specification there is no appropriate Status code
for communicating this kind of failure from one sip dialog to another
for an established session.
To fulfill this requirement a new SIP Status code 450 "Call in
minimal state" is being proposed.
Note:- The above optimized handling is also possible when there is
only one B2BUA in the configuration.
Narang Expires December 3, 2006 [Page 5]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
3. B2BUA detecting the network failure behavior
This is referring UA5 in Figure 1. The UA5 shall be monitoring the
session by using session timers or some other proprietary mechanism.
We shall be discussing in the context of session timers throughout
this document. During session establishment, it would have been
negotiated whether UA5 is a "refresher" or a "non-refresher".
The failure of session timer's refresh would not certainly tell
whether UA6 crashed or it is due to network connectivity issues. For
optimized handling UA5 SHALL make an assumption that session timeout
is due to network connectivity issues. The UA5 SHALL internally
communicate this condition to the UA4 by passing the 450 status code.
Then UA5 MAY terminate itself.
The UA4 MAY handle this special condition in two ways depending on
whether or not it needs to remain in the partial dialog for the
purposes of logging "Call Detail Records" on completion of the SIP
session with phone1.
3.1. B2BUA wants to remain in partial dialog for CDR
3.1.1. UA4 is a non-refresher
When UA4 is the "non-refresher" for dialog2, then on receiving the
next session refresh i.e a re-INVITE or UPDATE, a 450 "Call in
minimal state" response MUST be sent.
3.1.2. UA4 is a refresher
When UA4 is the "refresher" for dialog2, then an INVITE/UPDATE with
Reason header having SIP Status code 450 MUST be sent.
Reason: SIP;cause=450;text="Call in minimal state"
The session refresh procedure on dialog2 MUST be continued until a
BYE is received from remote or session refresh timeout occurs.
3.2. B2BUA doesn't want to remain in partial dialog
A BYE with SIP Status code 450 SHOULD be sent and UA4 MUST be
terminated on receiving 200 OK (for BYE).
Reason: SIP;cause=450;text="Call in minimal state"
Narang Expires December 3, 2006 [Page 6]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
4. B2BUA receiving the 450 status code behavior
This is referring to UA3 in Figure 1. The receipt of SIP Status
code="450" by UA3 would indicate that somewhere in the network
segment connecting from remote UA or further down, the network is
detected as "disconnected". There is no specific information whether
the SIP Session/media path between the caller and callee is still
active or got disconnected. The received 450 status code MUST be
communicated to the other side of B2BUA.
4.1. UA3 handling
The UA3 MUST interwork the 450 status code to the UA2 in the same
B2BUA. The UA3 handling SHALL be based on whether BYE with 450 in
Reason header is received or whether it is the refresher and 450
response to re-INVITE/UPDATE is received or whether it is the non-
refresher and re-INVITE/UPDATE with 450 in Reason header is received.
The receipt of BYE SHOULD immediately terminate the UA3 and dialog2.
Otherwise the session timers mechanism on dialog2 MUST continue until
UA2 sends a disconnect (for receipt of BYE on dialog1, or when UA2
needs to tear down the partial dialog by sending a BYE on dialog1).
If session timer's timeout occurs on UA3 then also UA3 MUST clear
itself.
4.2. UA2 handling
The UA2 handling is going to be same as UA4 as it is described above.
The UA2 MAY handle this special condition in two ways depending on
whether or not it needs to remain in the partial dialog for the
purposes of logging "Call Detail Records" on completion of the SIP
session with phone1.
Preferably immediate B2BUA interacting with the phone UA SHOULD NOT
clear the dialog with phone UA until hangup from the phone. The
session refresh SHOULD continue until then.
If UA2 needs to clear itself, it MUST send an internal disconnect to
UA3 and MUST send a BYE with Reason header having a SIP Status
code=450 on dialog1. After UA2 receives 200 OK (for BYE) it MUST
terminate itself. The internal disconnect to UA3 SHALL result in
sending BYE on dialog2, which SHALL clear the dialog with remote UA4.
If UA2 needs to remain then it SHOULD continue with the session
timers procedure and respond with 450 status code for non-refresher
case and MUST send INVITE/UPDATE having 450 in the reason header for
refresher case on the session timeout.
Narang Expires December 3, 2006 [Page 7]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
5. Phone detecting the network failure behavior
This is referring UA6 (phone2) in Figure 1. When a phone detects a
network failure condition for an established signaling connection via
session timers or any other proprietary mechanism it implies a
problem in the connectivity for the SIP dialog. The associated SIP
media session could have been established through a different
network, so sip dialog disconnection due to n/w error doesn't
definitely imply that media session is also impacted.
Rather than tearing down the media session, best attempt handling
would be to just preserve the existing session in a limited mode i.e
no other feature capabilities possible. For disconnecting the
session, the phone MAY wait for hang-up from the user or MAY depend
on media specific monitoring of the session.
In this condition the SIP dialog SHALL be terminated immediately, but
SIP media session MAY be preserved until hang-up. So phone2 SHALL go
into a state where it will just have the media session operational.
There SHALL be no 450 status code generation by the phone UA as SIP
dialog is already torn down.
5.1. Phone2 is a Media Application
It is possible that phone2 is a Media Application i.e. there is no
human user e.g IVR or Call Recorder. On session timeout at UA6
(phone2), the SIP dialog with immediate B2BUA SHALL be cleared. So
there SHALL be no BYE message received to tear down the media
session.
If Media application is implementing media session preservation for
such scenarios, it MUST be required to additionally kick-off RTP/RTCP
monitoring capability on such a condition, so that it is detected
when to stop communicating media with the remote and close the RTP/
RTCP channels.
Narang Expires December 3, 2006 [Page 8]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
6. Phone receiving the 450 status code behavior
This is referring UA1 (phone1) in Figure 1. The receipt of 450
status code SHALL intimate to the phone that the network through
which the sip dialog was established has detected an error in
connectivity. There is no definite information about the status of
SIP media session.
An optimized action at the UA1 would be to do the best effort
handling i.e no interruption to the existing media session. For
making sure no features on the SIP dialog are allowed, the softkeys
on the phone MUST be disabled.
6.1. 450 receipt in session refresh
If UA1 is the refresher, the 450 response SHALL be received in
response to INVITE or UPDATE. If UA1 is the non-refresher, the 450
response SHALL be received in the INVITE's Reason header. The
session timer's refresh procedure MUST keep on running.
For tearing down the session the phone UA MUST wait for hang-up from
the user. When user hangs up then a BYE message MUST be sent to the
B2BUA.
6.2. 450 receipt in BYE's Reason header
This is the scenario when B2BUA's doesn't want to remain in the
minimal dialog for CDR purposes. The Phone UA MUST interpret the
Reason header in BYE and if 450 is received it would mean to attempt
optimized handling as described above. The phone UA MUST send 200 OK
for BYE and dialog1 SHALL be terminated.
The phone1 will go into a state where it will just have the media
session operational. On user hangup the media session i.e RTP/RTCP
channels SHOULD be closed.
Narang Expires December 3, 2006 [Page 9]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
7. Proxy's 450 status code behavior
Consider there is a Proxy in the signaling path from phone1 to
phone2.
7.1. Call Stateful Proxy
Consider that a sip dialog was established from UA through the proxy
to a remote UA, the proxy chose to be in the path of all the requests
sent in a sip dialog by adding Record-Route header in the requests
and responses forwarded through it.
For the mid dialog re-INVITE's forwarded through the Proxy, if the
client transaction receives a 450 status code from the UAS, the same
450 response MUST be forwarded by the proxy to the server transaction
for sending to the UAC. The standard handling as per section 16.7 of
per [rfc3261] SHALL be performed with no special handling specific to
450.
7.2. Transaction Stateful Proxy
The proxy which is only a transaction stateful will not be in the
path of SIP messages after initial INVITE/200 OK exchange. The 450
status code is intended to be useful on an established session/dialog
for communicating about sudden network failure in the signaling path
in some segment. The 450 status code SHALL be generated by B2BUA and
possibly will not be traversing through the proxy, which is
transaction stateful only.
7.3. Stateless Proxy
If 450 status code response is received by a stateless Proxy, the
standard handling as per section 16.11 of [rfc3261] SHALL be
performed.
Narang Expires December 3, 2006 [Page 10]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
8. Call Stateful Proxy Session Timeout handling
Assume the configuration having UA endpoints communicating through a
call stateful proxy and no B2BUA in the path. During session
establishment the session timers were exchanged and actively running
for monitoring the session.
There will be a session timer running on the stateful proxy. If this
timeout occurs on the proxy it would mean either the refresher UA
hasn't refreshed or 200 OK from non-refresher isn't received in time.
It might be possible that n/w path from proxy to either UA got lost.
On encountering this condition, the proxy will remove the call state
w/o initiating the BYE from itself as per [rfc4028]. In case later
an INVITE/UPDATE/BYE or other response is received from the UA's, it
shall be proxied to the other side without using the call stateful
proxy logic i.e will be routed by using the Request-URI in the SIP
message.
The proxy SHALL NOT generate a 450 status code on its own in this
condition.
At the UA endpoints also, there will be a session timeout condition
i.e refresher will not receive 200 OK or non-refresher will not
receive the session refresh request. The handling for this condition
at the phone UA will be implementation specific or as per section 5
of this draft. As both UA endpoints will autonomously detect this
error condition, either side SHALL NOT be generating or handling 450
status code in this situation.
Narang Expires December 3, 2006 [Page 11]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
9. IP-PSTN GW receiving the 450 status code behavior
The receipt of 450 status code SHALL imply that remote UA has
probably detected a network disconnection in a sip dialog towards
other side of the UA or further down the network towards the
destination party, a disconnection caused sending of 450 status code
on the sip dialog towards the IP-PSTN GW.
The 450 status code could be received in the following ways:-
1. BYE with Reason header having 450 status code. With receipt of
BYE the dialog from IP-GW to the remote UA gets terminated.
2. SIP leg on the GW is the refresher and in response to re-INVITE/
UPDATE, a 450 status code is received. The session timers MAY
continue until hang-up from the user on the PSTN side or until a
failure occurs in session refresh procedure.
3. SIP leg on the GW is the non-refresher and a remote sends a re-
INVITE with Reason header having 450 status code. The session timers
MAY continue until hang-up from the user on the PSTN side or until a
failure occurs in session refresh procedure.
For the above cases the IP-PSTN GW MAY maintain a SIP leg/dialog in a
minimal state allowing the preservation of the established media
session. There MAY NOT be any notification to the PSTN side about
this situation. Any features attempted from the PSTN side MUST be
rejected with appropriate Q.931 specific error codes.
Narang Expires December 3, 2006 [Page 12]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
10. NAT/ALG's 450 status code behavior
If NAT receives a 450 status code during session refresh, it would
imply that network link in the further segment has been detected
down. The session refresh between the sip elements will be
continuing until a BYE is received, so there SHOULD NOT be transport
disconnection on receipt of 450 by NAT/ALG's.
Narang Expires December 3, 2006 [Page 13]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
11. CDR logging of 450 status code
If there has been 450 status code specific handling in a SIP call leg
then while CDR's are generated the information about 450 MAY be
logged to CDR's. This will indicate that media might have been
active longer than the call duration logged in the CDR's due to the
specific nature of the 450 status code, allowing media session to be
active without the SIP dialog for n/w error conditions.
Narang Expires December 3, 2006 [Page 14]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
12. IANA Considerations
This extension defines a new response code i.e 450.
12.1. IANA Registration of the 450 (Call in minimal state) Response
Code
The following is the registration for the 450 (Call in minimal state)
response code:
Response Code: 450
Default Reason Phrase: Call in minimal state
RFC Number:
Narang Expires December 3, 2006 [Page 15]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
13. Backward's compatibilty
If a version of intermediate proxy or B2BUA is not implementing 450
response handling then it will result in session timeout on that
element, which will result in immediate clearing of the established
dialog/media session for the call.
Narang Expires December 3, 2006 [Page 16]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
14. 450 (Call in minimal state) Definition
This response code indicates that the network through which the sip
dialog was successfully established has detected an error in
connectivity. There is no definite information about the status of
SIP session. Its default reason phrase is "Call in minimal state".
Narang Expires December 3, 2006 [Page 17]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
15. Security Considerations
None.
Narang Expires December 3, 2006 [Page 18]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
16. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[rfc3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", June 2002.
[rfc4028] Donovan, S. and J. Rosenberg, "Session Timers in the
Session Initiation Protocol (SIP)", April 2005.
Narang Expires December 3, 2006 [Page 19]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
Author's Address
Rajeev Narang
Cisco Systems Inc.
12 Bannerghatta Road
Subramanya Arcade Block D
Bangalore
India
Email: ranarang@cisco.com
Narang Expires December 3, 2006 [Page 20]
Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Narang Expires December 3, 2006 [Page 21]
