PISN | | IP NETWORK
| +-----+------+------+ |
| | | |
| | | |
| QSIG DISCONNECT | | 1- 4XX / 6XX |
1|----------------------->|......|---------------------->|4
| QSIG RELEASE | | 1- ACK |
2|<-----------------------| |<----------------------|5
| QSIG RELEASE COMP | | |
3|----------------------->| | |
| | | |
| | | |
Figure 10: Typical message sequence for call clearing from QSIG to
SIP, during establishment of a call from SIP to QSIG (gateway has
not sent a final response to the SIP INVITE request)
1 The PISN sends a QSIG DISCONNECT message to the gateway
2 The gateway sends back a QSIG RELEASE message to the PISN in
response to the QSIG DISCONNECT message
3 The PISN sends a QSIG RELEASE COMPLETE message in response. All
PISN resources are now released.
4 The gateway maps the QSIG DISCONNECT message to a SIP 4xx-6xx
response
5 The IP network sends back a SIP ACK request in response to the SIP
4xx-6xx response. All IP resources are now released
A.4.3. QSIG to SIP, during establishment of a call from QSIG to SIP
+-------------------+
| |
| GATEWAY |
PISN | | IP NETWORK
| +-----+------+------+ |
| | | |
| | | |
| QSIG DISCONNECT | | 1- CANCEL |
1|----------------------->|......|----------------------->|4
| QSIG RELEASE | |1-487 Request Terminated|
2|<-----------------------| |<-----------------------|5
| QSIG RELEASE COMP | | |
3|----------------------->| | 1- ACK |
| | |----------------------->|6
| | | |
| | | 1- 200 OK |
| | |<-----------------------|7
| | | |
Figure 11: Typical message sequence for call clearing from QSIG to
SIP, during establishment of a call from QSIG to SIP (gateway has
received a provisional response to the SIP INVITE request but not a
final response)
1 The PISN sends a QSIG DISCONNECT message to the gateway.
2 The gateway sends back a QSIG RELEASE message to the PISN in
response to the QSIG DISCONNECT message.
3 The PISN sends a QSIG RELEASE COMPLETE message in response. All
PISN resources are now released.
4 The gateway maps the QSIG DISCONNECT message to a SIP CANCEL
request (subject to receipt of a provisional response, but not of
a final response).
5 The IP network sends back a SIP 487 (Request Terminated) response
to the SIP INVITE request.
6 The gateway, on receiving a SIP final response (487) to the SIP
INVITE request, sends back a SIP ACK request to acknowledge
receipt.
7 The IP network sends back a SIP 200 (OK) response to the SIP
CANCEL request. All IP resources are now released.
A.5. Message Sequence for Call Clearing from SIP to QSIG
Below are typical message sequences for Call Clearing from SIP to
QSIG
A.5.1. SIP to QSIG, subsequent to call establishment
+-------------------+
| |
| GATEWAY |
IP NETWORK | | PISN
| +-----+------+------+ |
| | | |
| | | |
| 2- BYE | | QSIG DISCONNECT |
1|----------------------->|......|----------------------->|3
| | | QSIG RELEASE |
| | |<-----------------------|4
| 2-200 OK | | QSIG RELEASE COMP |
2|<-----------------------| |----------------------->|5
| | | |
| | | |
Figure 12: Typical message sequence for call clearing from SIP to
QSIG, subsequent to call establishment
1 The IP network sends a SIP BYE request to the gateway.
2 The gateway sends back a SIP 200 (OK) response to the SIP BYE
request. All IP resources are now released.
3 The gateway maps the SIP BYE request to a QSIG DISCONNECT message.
4 The PISN sends back a QSIG RELEASE message to the gateway in
response to the QSIG DISCONNECT message.
5 The gateway sends a QSIG RELEASE COMPLETE message in response.
All PISN resources are now released.
A.5.2. SIP to QSIG, during establishment of a call from QSIG to SIP
+-------------------+
| |
| GATEWAY |
IP NETWORK | | PISN
| +-----+------+------+ |
| | | |
| | | |
| 1- 4XX / 6XX | | QSIG DISCONNECT |
1|----------------------->|......|----------------------->|3
| | | QSIG RELEASE |
| | |<-----------------------|4
| 1- ACK | | QSIG RELEASE COMP |
2|<-----------------------| |----------------------->|5
| | | |
| | | |
| | | |
Figure 13: Typical message sequence for call clearing from SIP to
QSIG, during establishment of a call from QSIG to SIP (gateway has
not previously received a final response to the SIP INVITE request)
1 The IP network sends a SIP 4xx-6xx response to the gateway.
2 The gateway sends back a SIP ACK request in response to the SIP
4xx-6xx response. All IP resources are now released.
3 The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT
message.
4 The PISN sends back a QSIG RELEASE message to the gateway in
response to the QSIG DISCONNECT message.
5 The gateway sends a QSIG RELEASE COMPLETE message in response.
All PISN resources are now released.
A.5.3. SIP to QSIG, during establishment of a call from SIP to QSIG
+-------------------+
| |
| GATEWAY |
IP NETWORK | | PISN
| +-----+------+------+ |
| | | |
| | | |
| 1- CANCEL | | QSIG DISCONNECT |
1|----------------------->|......|----------------------->|4
| | | QSIG RELEASE |
| | |<-----------------------|5
|1-487 Request Terminated| | QSIG RELEASE COMP |
2|<-----------------------| |----------------------->|6
| | | |
| 1- ACK | | |
3|----------------------->| | |
| | | |
| 1- 200 OK | | |
4|<-----------------------| | |
Figure 14: Typical message sequence for call clearing from SIP to
QSIG, during establishment of a call from SIP to QSIG (gateway has
sent a provisional response to the SIP INVITE request but not a final
response)
1 The IP network sends a SIP CANCEL request to the gateway.
2 The gateway sends back a SIP 487 (Request Terminated) response to
the SIP INVITE request.
3 The IP network, on receiving a SIP final response (487) to the SIP
INVITE request, sends back a SIP ACK request to acknowledge
receipt.
4 The gateway sends back a SIP 200 (OK) response to the SIP CANCEL
request. All IP resources are now released.
5 The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT
message.
6 The PISN sends back a QSIG RELEASE message to the gateway in
response to the QSIG DISCONNECT message.
7 The gateway sends a QSIG RELEASE COMPLETE message in response.
All PISN resources are now released.
Authors’ Addresses
John Elwell
Siemens plc
Technology Drive
Beeston
Nottingham, UK, NG9 1LA
EMail: john.elwell@siemens.com
Frank Derks
NEC Philips Unified Solutions
Anton Philipsweg 1
1223 KZ Hilversum
The Netherlands
EMail: frank.derks@nec-philips.com
Olivier Rousseau
Alcatel Business Systems
32,Avenue Kleber
92700 Colombes
France
EMail: Olivier.Rousseau@alcatel.fr
Patrick Mourot
Alcatel Business Systems
1,Rue Dr A. Schweitzer
67400 Illkirch
France
EMail: Patrick.Mourot@alcatel.fr
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).