SIP-H.323 Interworking Call Scenarios
VIPIN PALAWAT
vipin.palawat at wipro.com
Thu Mar 9 07:19:36 EST 2000
Hello Kundan,
Thanks for the detailed comments.
We have put our views and opinions in the "blue" font.
Kindly give us the comments for our views.
> Hi Hemant and Vipin,
>
> Its a very good collection of call flows' translation.
>
> Few comments:
>
> 1) Might want to include H.323---SIP---H.323 case where the
> call goes through two SGWs. Since, combining the
> two call flows (H.323-SIP, sec:1.1) and (SIP-H.323, sec:2.1)
> may not work. The SIP ACK in sec:1.1 has a different session
> description, which will trigger some "Mode Request"
> and/or "Open/Close LogicalChannel" procedures in
> sec:2.1.
>
Fine, I will prepare this case and send it for comments.
> 2) In sec:1.1,1.2,1.3; it might be better to send ACK
> immediately after receiving 200 OK, and send
> re-INVITE once H.245 procedures are complete.
> This way, we can avoid the retransmissions of 200 OK
> by SIP EP if H.245 procedures take more time to complete.
> Comments ??
If you refer to Fig. 11 (Call from H.323 to SIP with conversion between OLC and SDP) of
"draft-singh-sip-h323-00.txt", the ACK is sent only towards the completion of H.245 .
We have just put it after the last OLC and OLC Ack. Does it makes too much time
difference ?
We are still looking towards your view of sending re-INVITE and will come up with this scenario
also for the comments.
> 3) In Fast Connect procedures (sec 3.1), I assume that
> if the normal H.245 procedure resumes after initial
> call setup (with faststart), and there is a change in
> H.323 side session description, then appropriate
> re-INVITE message is sent to SIP EP.
I feel it will be a special case of this scenario. We haven't
looked for such case and will definitely look for such possibility.
> 4) Sec:4 Call transfer may be renamed to (Blind) Call Tranfer.
We have reffered to the conditions that needs to be fulfilled for blind
transfer from "draft-ietf-mmusic-sip-cc-01.txt". I don't feel
that all of the requirements are fulfilled in call transfer shown
in this section.
Please comment .
> 5) Sec:4.1. RTP should be between SIP EP(B) and SIP EP(C)
Agreed, there was a mistake from our side while drawing the figures.
> 6) Sec: 5.1, you may send "181 Call is being forwarded"
> response to SIP (A).
> Can SIP (A) reject the call forwarding here ???
> Who pays for the call if the forwarded call
> costs more (longdistance/international) ? Any
> pointer to this topic is appreciated.
There can be two cases for the billing. These are the services offered
by the service provider and more often seen in mobile networks . So ,I
am considering this also on similar basis.
In those cases, the user use to get a display/and or announcement that the
call is being forwarded to a particular destination. Now, at that point, the
caller can reject the
call to the forwarded party. If he accepts it, then it means that he agrees to have
the forwarded call. In this case, the bill will be paid by the caller.
In other case, the service provider can give the provision to the called party to
either accept or reject the forwarded call based on the caller identity. In this
case, he may have an agreement with the service provider that he will pay the
extra amount for the forwarded call.
Because of these reasons only, we had put a ??? in call diagrams because I was
looking for the appropriate and the best suitable way to tell the caller that the call
is being forwarded to other destination.
There can be a other way to the call scenario that we have shown in 5.1 .
The Setup with divertingLegInfo4.inv will be sent only after sending the message to
the caller that the call is being forwarded and subject to condition that the caller
agrees to accept the forwarded call .
> 7) The call forwarding may be initiated by the
> proxy (after receipt of 486 Busy Here) or by
> the SIP endsystem itself (by responding with 302 Moved Temporarily)
> if it is configured to do so. However, that will not
> affect the translation much.
> 8) Sec:5.3, typo; SIP User (A) should be (B) and (B) should be (C).
Agreed
>
> Considering the wide variety of scenarios between
> H.323 and SIP, would it be reasonable to start with
> a simple call translation specification,
> provide a state machine/pseudo code for
> message handling by the SGW (signaling gateway)
> and then extend the state machine/pseudo code
> to handle all the non-trivial call scenarios.
>
> Once the basic translation specification is ready,
> profiles for extensions (e.g., blind transfer
> using GK, call forwarding using proxy,
> translating forking proxy behaviour to H.323, etc.)
> may be specified.
>
> Thus, the initial specification may cover following
> areas:
> - Simple SIP--SGW--H.323 translation, with SGW
> independent of any GK or proxy.
> - Translating (blind) call transfer by endsystems.
> - Translating call forwarding by endsystems.
> - How to handle, SIP re-INVITEs (change
> in session description/or media transport address)
> and change in
> H.323 logical channel/mode request.
> - How to handle H.323 fast start.
>
> Later on other things may be added:
> - Call hold translation
> - Call transfer/forwarding by GK and/or proxy.
> - SIP--H.323--SIP and H.323---SIP---H.323 scenarios.
> - SGW coexiting with GK or proxy.
> ...
>
> Motivation for such a separation is to allow
> the implementors more freedom in deciding what
> configuration to choose, while still maintaining
> the basic translation framework.
> For example, call forwarding to voicemail may
> be handled by
> - the endsystem by sending 302 moved, after say 4 rings.
> - the proxy server on receipt of 486 busy here
> - the proxy server, forking one branch of the request to the voicemail
> system which accepts the call after, say, 15 seconds.
>
> It turns out that once we have the initial specification,
> (as mentioned in above list) the advanced scenarios
> are just a "special cases"/"combination of cases" of the
> initial scenarios.
>
> Regards
>
> Kundan
> --
> Kundan Singh http://www.cs.columbia.edu/~kns10
>
> On Wed, 8 Mar 2000, Hemant Agrawal wrote:
>
> > Hi All,
> > There was a continuous discussion on the different configuration for the
> > SIP - H.323 interworking.
> >
> > In our opinion, it would be better if some basic features (like Call
> > Transfer, Call Hold and Call forwarding) is also added as part of the
> > discussion.
> >
> > We are enclosing some call flow examples of SIP-H.323 interworking. Please
> > give your comments on these call flows. Our stress is on the call features
> > and others are just informational. We have specified few issues also inorder
> > to make these protocols interwork.
> >
> > Kindly let us know if you agree to include the feature discussion also as
> > part of the SIP - H.323 interworking. We are ready to put our efforts for
> > the feature interworking.
> >
> > Best Regards
> >
> > Hemant Agarwal
> > Vipin Palawat
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000309/37e68771/attachment-0001.htm>
-------------- next part --------------
SIP - H.323 Interworking Call Scenarios
_______________________________________
HEMANT AGRAWAL & VIPIN PALAWAT
REF:1) draft-singh-sip-h323-00
2) draft-sparks-sip-service-examples-00
3) ITU-T H.323
3) ITU-T H.450.2(CallTransfer Supp. Services For H.323)
4) ITU-T H.450.3(CallDiversion Supp. Services For H.323)
5) ITU-T draft H.450.4(Call Hold Supplementary Services For H.323)
INDEX:
1) Call from H.323 Network to SIP Network
1.1) Simple call from H.323 terminal to SIP Terminal
1.2) Call with H.323 Gatekeeper and SIP Proxy Server
1.3) Call with H.323 Gatekeeper and SIP Redirect Server
2) Call from SIP Network to H.323 Network
2.1) Simple call from SIP Terminal to H.323 Terminal
2.2) Call with SIP Proxy and H.323 Gatekeeper
2.3) Call with SIP Redirect and H.323 Gatekeeper
3) Special Scenarios
3.1) Fast Connect Procedures
3.1.1) With SIP Proxy server and H.323 Gatekeeper
3.2) Tunneling Procedure
3.2.1) With SIP Proxy Server and H.323 Gatekeeper
4) Call Transfer Service interworking in SIP-H.323 GW
4.1) H.323 terminal transfer the call from SIP Terminal to SIP Terminal
4.2) H.323 terminal transfer the call from H.323 Terminal to SIP Terminal
5) Call Diversion Service interworking in SIP-H.323 GW
5.1) Call Forwarding on Busy invoked by H.323 GK
5.2) Call Forwarding on Busy, invoked by SIP Proxy
5.3) Call Forwarding on No Answer invoked by H.323 GK
5.4) Call Forwarding on No Answer, invoked by Proxy
6) Call Holding Service interworking in SIP-H.323 GW
6.1) Remote End Call Hold When GK is Transparent.
6.1.1) SIP initiated
6.1.1.1) Hold
6.1.1.2) Retrieve from hold
6.1.2) H.323 Initiated
6.1.2.1) Hold
6.1.2.2) Retrieve from hold
6.2) Remote End Call Hold In GK routed Model
6.2.1) SIP initiated
6.2.1.1) Hold
6.2.1.2) Retreive from hold
6.3) Near End Call Hold for GK Transparent
6.3.1) SIP Initiated
6.3.1.1) Hold
6.3.1.2) Retreive from hold
6.3.2) H.323 Initiated
6.3.2.1) Hold
6.3.2.2) Retreive from hold
1)Call from H.323 Network to SIP Network
1.1) Simple call from H.323 terminal to SIP Terminal
H.323 SIP
EP Setup SGW EP
|------------>| INVITE |
| |------------>|
| | 180 RINGING |
| Alerting |<------------|
|<------------| 200 OK |
| Connect |<------------|
|<------------| |
| H.245 | |
|<----------->| ACK |
| |------------>|
| RTP |
|<------------------------->|
This is a simple call from H.323 network to SIP network which does not involve H.323 gatekeeper and SIP servers. The protocol conversion, i.e. message and parameters mapping between H.323 and SIP is done by the signalling gateway(SGW).
1.2) Call with H.323 Gatekeeper and SIP Proxy Server
H.323 H.323 SIP SIP
EP GK SGW Proxy EP
| ARQ | | | |
|------------>| | | |
| ACF | | | |
|<------------| | | |
| Setup | | | |
|------------>| Setup | | |
| |------------>| | |
| | ARQ | | |
| |<------------| | |
| | ACF | | |
| |------------>| INVITE | |
| | |------------>| INVITE |
| | | |------------>|
| | | | 180 RINGING |
| | | 180 RINGING |<------------|
| | Alerting |<------------| |
| Alerting |<------------| | |
|<------------| | | 200 OK |
| | | 200 OK |<------------|
| | Connect |<------------| |
| Connect |<------------| | |
|<------------| | | |
| H.245 | | |
|<------------------------->| ACK | |
| | |------------>| ACK |
| | | |------------>|
| | | | |
| | RTP | |
|<----------------------------------------------------->|
In this scenario, the ACK will be sent to SIP side only after the completion of H.245 . This is because the channel parameters and capabilities of H.323 terminal needs to be communicated to SIP side which can only be done after capabilities exchange and OLC on H.323 side.
1.3) Call with H.323 Gatekeeper and SIP Redirect Server
H.323 H.323 SIP SIP
EP GK SGW Redirect EP
| ARQ | | | |
|------------>| | | |
| ACF | | | |
|<------------| | | |
| Setup | | | |
|------------>| Setup | | |
| |----------->| | |
| | ARQ | | |
| |<-----------| | |
| | ACF | | |
| |----------->| INVITE | |
| | |----------->| |
| | | 302 Moved | |
| | |<-----------| |
| | | ACK | |
| | |----------->| |
| | | INVITE |
| | |-------------------------->|
| | | 180 RINGING |
| | Alerting |<--------------------------|
| Alerting |<-----------| |
|<------------| | 200 OK |
| | Connect |<--------------------------|
| Connect |<-----------| |
|<------------| | |
| H.245 | |
|<------------------------>| ACK |
| |-------------------------->|
| RTP |
|<---------------------------------------------------->|
In this scenario, the SIP redirect server will contact the location server to find out the address of the destination endpoint. This address will be returned in the 3xx response from SIP redirect server. As mentioned in 1.2 above, the ACK will be sent only after the completion of H.245 on H.323 side.
2) Call from SIP Network to H.323 Network
2.1) Simple call from SIP Terminal to H.323 Terminal
SIP H.323
EP SGW EP
| | |
| INVITE | |
|------------>| Setup |
| |----------->|
| | Alerting |
| 180 RINGING |<-----------|
|<------------| Connect |
| |<-----------|
| | H.245 |
| 200 OK |<---------->|
|<------------| |
| ACK | |
|------------>| |
| RTP |
|<------------------------>|
In this scenario, the 200 OK response is sent only after H.245 gets completed on H.323 side. This is because the capabilities and the channel information needs to be communicated to the SIP side which can be done by 200 OK after H.245. The other possibility is to send OPTIONS which will communicate the capabilities and channel information to SIP side. In this case the 200 OK can be sent immediatly after "Connect" is received from H.323 side.
2.2) Call with SIP Proxy and H.323 Gatekeeper
SIP SIP H.323 H.323
EP Proxy SGW GK EP
| | | | |
| INVITE | | | |
|------------>| INVITE | | |
| |------------>| ARQ | |
| | |------------>| |
| | | ACF | |
| | |<------------| |
| | | Setup | |
| | |------------>| Setup |
| | | |------------>|
| | | | ARQ |
| | | |<------------|
| | | | ACF |
| | | |------------>|
| | | | Alerting |
| | | Alerting |<------------|
| | 180 RINGING |<------------| |
| 180 RINGING |<------------| | |
|<------------| | | Connect |
| | | Connect |<------------|
| | |<------------| |
| | | H.245 |
| | 200 OK |<------------------------->|
| 200 OK |<------------| | |
|<------------| | | |
| ACK | | | |
|------------>| ACK | | |
| |------------>| | |
| | RTP | |
|<----------------------------------------------------->|
This scenario is very much similar to the case 2.1 shown above. In this case, the 200 OK is sent only after completing H.245 on H.323 side.
2.3) Call with SIP Redirect and H.323 Gatekeeper
SIP SIP H.323 H.323
EP Redirect SGW GK EP
| INVITE | | | |
|------------>| | | |
| 302 Moved | | | |
|<------------| | | |
| ACK | | | |
|------------>| | | |
| INVITE | | |
|-------------------------->| ARQ | |
| | |------------>| |
| | | ACF | |
| | |<------------| |
| | | Setup | |
| | |------------>| Setup |
| | | |------------>|
| | | | ARQ |
| | | |<------------|
| | | | ACF |
| | | |------------>|
| | | | Alerting |
| | | Alerting |<------------|
| |180 Ringing |<------------| |
|180 Ringing |<------------| | |
|<------------| | | Connect |
| | | Connect |<------------|
| | |<------------| |
| | | H.245 |
| 200 OK |<------------------------->|
|<--------------------------| | |
| ACK | | |
|-------------------------->| | |
| | RTP | |
|<----------------------------------------------------->|
3)Special Scenarios
3.1)Fast Connect Procedures
3.1.1) With SIP Proxy server and H.323 Gatekeeper
SIP SIP H.323 H.323
EP Proxy SGW GK EP
| | | | |
| | | | |
| INVITE | | | |
|------------>| INVITE | | |
| |------------>| ARQ | |
| | |------------>| |
| | | ACF | |
| | |<------------| |
| | | Setup(with | |
| | | fast start | |
| | | and OLC) | |
| | |------------>| Setup(with |
| | | | fast start |
| | | | and OLC) |
| | | |------------>|
| | | | ARQ |
| | | |<------------|
| | | | ACF |
| | | |------------>|
| | | |Alerting(with|
| | | |fast start) |
| | |Alerting(with|<------------|
| | |fast start) | |
| | 180 RINGING |<------------| |
| 180 RINGING |<------------| | |
|<------------| | |Connect(with |
| | | |fast start |
| | | |and OLC) |
| | |Connect(with |<------------|
| | |fast start | |
| | |and OLC) | |
| | 200 OK |<------------| |
| 200 OK |<------------| | |
|<------------| | | |
| ACK | | | |
|------------>| ACK | | |
| |------------>| | |
| | RTP | |
|<----------------------------------------------------->|
In this scenario, fast connect procedure is used on H.323 side. The MSD,Capability Exchange and OLC is done with Q.931 messages.
3.2) Tunneling Procedure
3.2.1) With SIP Proxy Server and H.323 Gatekeeper
SIP SIP H.323 H.323
EP Proxy SGW GK EP
| | | | |
| INVITE | | | |
|------------>| INVITE | | |
| |------------>|Setup(tunn.= | |
| | |true,MSD,TCS)| |
| | |------------>| |
| | | ARQ | |
| | |<------------| |
| | | ACF | |
| | |------------>| Setup(MSD, |
| | | | TCS) |
| | | |------------>|
| | | | ARQ |
| | | |<------------|
| | | | ACF |
| | | |------------>|
| | | |Alerting(MSD |
| | | |Ack,TCS Ack, |
| | | |TCS,MSD) |
| | |Alerting(MSD |<------------|
| | |Ack,TCS Ack, | |
| | |TCS,MSD) | |
| | 180 RINGING |<------------| |
| 180 RINGING |<------------| | |
|<------------| |Facility(TCS | |
| | |Ack,MSD Ack, | |
| | |OLC) | |
| | |------------>|Facility(TCS |
| | | |Ack,MSD Ack, |
| | | |OLC) |
| | | |------------>|
| | | |Facility(OLC |
| | | |Ack,OLC) |
| | |Facility(OLC |<------------|
| | |Ack,OLC) | |
| | |<------------| |
| | |Facility(OLC | |
| | |Ack) | |
| | |------------>|Facility(OLC |
| | | |Ack) |
| | | |------------>|
| | | | Connect |
| | | Connect |<------------|
| | 200 OK |<------------| |
| 200 OK |<------------| | |
|<------------| | | |
| ACK | | | |
|------------>| ACK | | |
| |------------>| | |
| | RTP | |
|<----------------------------------------------------->|
This scenario takes care of H.245 tunnelling procedures on H.323 side. The tunnelled H.245 messages goes along with Q.931 and Q.932 messages.
4 ) Call Transfer Service interworking in SIP-H.323
4.1) H.323 terminal transfer the call from SIP Terminal to SIP Terminal
H.323 SIP SIP
EP(A) SGW EP(B) EP(C)
| | | |
| Setup | | |
|------------>| INVITE | |
| |------------>| |
| | 180 RINGING | |
| Alerting |<------------| |
|<------------| 200 OK | |
| Connect |<------------| |
|<------------| | |
| H.245 | | |
|<----------->| ACK | |
| |------------>| |
| RTP | |
|<------------------------->| |
| Facility | | |
|(ctInitiate. | | |
| Invoke) | | |
|------------>| BYE | |
| |(Location:C) | |
| |------------>| |
| | 200 OK | |
|Release Comp.|<------------| |
|(ctInitiate. | | |
|ReturnResult)| | INVITE (C) |
|<------------| |------------>|
| | | 200 OK |
| | |<------------|
| | | ACK |
| | |------------>|
| | RTP |
| |<------------------------->|
In this scenario, H.323 terminal talking to a SIP terminal initiates the call transfer for a SIP termianl. The procedure for call transfer is done according to H.450.2 on H.323 side.
4.2)H.323 terminal transfer the call from H.323 Terminal to SIP Terminal
H.323 H.323 SIP
EP(A) EP(B) SGW EP(C)
| | | |
| Setup | | |
|------------>| | |
| Alerting | | |
|<------------| | |
| Connect | | |
|<------------| | |
| H.245 | | |
|<----------->| | |
| RTP | | |
|<----------->| | |
| Facility | | |
|(ctInitiate. | | |
| Invoke) | | |
|------------>| Setup | |
| |(ctSetup. | |
| | Invoke) | |
| |----------->| INVITE |
| | |----------->|
| | | 180 RINGING|
| | |<-----------|
| | | 200 OK |
| |Connect |<-----------|
| |(ctSetup. | |
| |ReturnResult| |
|Release Comp.|<-----------| |
|(ctInitiate. | | |
|ReturnResult)| | |
|<------------| H.245 | |
| |<---------->| ACK |
| | |----------->|
| | RTP |
| |<----------------------->|
In this scenarion, H.323 terminal talking to a H.323 terminal initiates a call transfer for a SIP terminal. The procedure on H.323 side is according to H.450.2 and on SIP side, it is in accordance with the "SIP call control services".
5) Call Diversion Service interworking in SIP-H.323 GW
It is assumed in all the call flows shown that SIP User agent has turned on the required forwarding feature in the Proxy server and H.323 end point has activated the features in the H.323 Gatekeeper.
ISSUE: Should the Cross domain activation of Features allowed eg. A Sip terminal tells a H.323 GK (thru SIP-H.323 GK) about forwarding all the calls for him to another terminal in SIP Domain.
5.1) Call Forwarding on Busy, invoked by H.323 GK
SIP User A Proxy SGW GK H.323 User B User C
| INVITE | | | | |
|----------> | INVITE | | | |
|100 Try |-------------> | SETUP | | |
|<---------- | |-------------> | SETUP | |
| | | Call Proc |-------------> | |
| | |<------------- | RELEASE COMP | |
| | | |(cause:userbusy| |
| | | |<------------- | |
| | |Facility(divert|SETUP(diverting| |
| | |ingLegInfo1.inv| LegInfo4.inv) | |
| | | |-------------->| |
| | ???<---- | <-------------| RELEASE COMP | |
| | | | <------------ | |
| | | |SETUP | |
| | | |(divertingLegInfo2.inv) |
| | | | ---------------------->|
| | | | ARQ | |
| | | |<-----------------------|
| | | | ACF | |
| | | | ---------------------->|
| | | | ALERTING | |
| | | ALERTING |<-----------------------|
| | 180 Ringing |<--------------| CONNECT | |
|180 Ringing |<------------- | CONNECT |<-----------------------|
|<-----------| |<--------------| | |
| | |< ------------------ H.245------------->|
| | 200 OK | | | |
|200 OK |<------------- | | | |
|<---------- | | | | |
| ACK | | | | |
| ---------->| ACK | | | |
| |-------------> | | | |
|---------------------------------------------------------------------|
| RTP BOTH WAYS |
|---------------------------------------------------------------------|
ISSUE: On the Receive of Facility (divertingLegInfo1.inv) at SGW how to indicate the SIP user agent about the forwarding.
5.2) Call Forwarding on Busy, invoked by SIP Proxy
SIP User A Proxy SGW H.323 User B User C
| INVITE | | | |
|----------> | INVITE | | |
|100 Try |-------------> | SETUP | |
|<---------- | |-------------> | |
| | | RELEASE COMP | |
| | |(cause:userbusy| |
| | 486 Busy Here |<------------- | |
| | <-------------| | |
| | ACK | | |
| |-------------->| | |
| | INVITE | | |
| | ------------->| SETUP | |
| | |-------------->| SETUP |
| | | |------------->|
| | | | ALERTING |
| | | ALERTING |<-------------|
| | 180 Ringing |<--------------| CONNECT |
|180 Ringing |<------------- | CONNECT |<-------------|
|<-----------| |<--------------| |
| | |< ---------- H.245 --------- >|
| | 200 OK | | |
|200 OK |<------------- | | |
|<---------- | | | |
| ACK | | | |
| ---------->| ACK | | |
| |-------------> | | |
|-----------------------------------------------------------|
| RTP BOTH WAYS |
|-----------------------------------------------------------|
ISSUE: 1) How to inform H.323 User C about forwarding.
5.3)Call Forwarding on No Answer, invoked by H.323 GK
H.323 SIP SIP
User A GK SGW User A User B
| ARQ | | | |
|------------>| | | |
| ACF | | | |
|<------------| | | |
| Setup | | | |
|------------>| Setup | | |
| |------------>| | |
| | ARQ | | |
| |<------------| | |
| | ACF | | |
| |------------>| INVITE | |
| | |------------>| |
| | | 180 RINGING | |
| | Alerting |<------------| |
| Alerting |<------------| | |
|<------------| Setup | | |
| Request . | (diverting | | |
| Time | LegInfo2. | | |
| Out . | inv) | | |
| ...|------------>| INVITE |
| | Facility |-------------------------->|
| |(diverting | | |
| | LegInfo4. | | |
| | inv) | | |
| |------------>| ??? | |
| | |---------> | |
| | | 180 RINGING |
| | Alerting |<--------------------------|
| |<------------| | |
| | Release | | |
| | Complete | | |
| Facility |------------>| CANCEL | |
|(diverting | |------------>| |
| LegInfo1. | | 200 OK | |
| inv) | Connect |<------------| |
|<------------|(diverting | 200 OK |
| Connect | LegInfo3.|<--------------------------|
|(diverting | inv) | | |
| LegInfo3. |<------------| | |
| inv) | | | |
|<------------| | | |
| H.245 | | |
|<------------------------->| ACK |
| | |-------------------------->|
| | RTP | |
|<----------------------------------------------------->|
ISSUE: 1) On the Receive of Facility (divertingLegInfo4.inv) at SGW how to indicate the SIP user agent about the forwarding.
2) Once the User C Alerted the H.323 GK should send RELEASE COMPLETE for User B. While in SIP Call flows[2], INVITE is going to User C only after sending the CANCEL to User B. At present we are Sending RELEASE COMPLETE for USER B after User C gets alerted.
5.4)Call Forwarding on No Answer, invoked by Proxy
SIP SIP H.323
User A Proxy User B SGW User C
| INVITE | | | |
|------------>| INVITE | | |
| |------------>| | |
| | 180 RINGING | | |
| 180 RINGING |<------------| | |
|<------------| | | |
| | Request | | |
| | Time | | |
| . | Out | | |
| . | | | |
| . | CANCEL | | |
| ... |------------>| | |
| | 200 OK | | |
| |<------------| | |
| | INVITE(C) | |
| |------------------------>| Setup |
| | | |--------->|
| | | | Alerting |
| | 180 RINGING |<---------|
| |<------------------------| Connect |
| | | |<---------|
| | | | H.245 |
| | 200 OK |<-------->|
| 200 OK |<------------------------| |
|<------------| | | |
| ACK | | | |
|------------>| ACK | |
| |------------------------>| |
| | RTP | |
|<------------------------------------------------>|
6) Call Holding Service interworking in SIP-H.323 GW
In H.450.4, Call Hold (SS-HOLD) allows the served user, which may be the originally calling or the called user, to interrupt communications on an existing call and then subsequently, if desired, re-establish (i.e. retrieve) communications with the held user. Hold may only be invoked by the served user for a call in the active state. Communication on the media channels is interrupted and the call is placed in the held state. The distant party is informed, and if appropriate, a specific MOH pattern (e.g. video and/or music on hold) may be provided to the held user. The served user may then originate or accept other calls, or use other services without impacting the call in the held state. Two scenarios are specified for SS-HOLD, "Near-end Call Hold" and "Remote-end Call Hold". The decision whether to invoke one or the other of the methods is an implementation and application matter.
Remote-end Call Hold: The holding endpoint sends a hold request to the remote endpoint requiring the held endpoint to provide MOH to the held user.
Near-end Call Hold: The holding endpoint informs the held endpoint of the hold condition by sending a hold notification and stops receiving user packets from the held endpoint as well as sending user packets to the held endpoint. The held endpoint upon receiving the hold notification may stop sending user packets but shall continue listening to the receive channel.
6.1) Remote End Call Hold When GK is Transparent.
6.1.1) SIP initiated
6.1.1.1) Hold
SIP H.323
User A Proxy SGW GK User B
|INVITE(c=0) | | | |
|----------->| INVITE (c=0) |Facility | |
| |------------->|(remoteHold.inv) |Facility |
| | |------------------->|(remoteHold.inv) |
| | | |------------------->|
| | | <---------------TCS = 0 --------------->|
| | 200 OK | <-------Close Logical Channel---------->|
| 200 OK |<------------ | | |
|<---------- | | |Facility |
| ACK | |Facility |(remoteHold.rr) |
|----------> | ACK |(remoteHold.rr) |<-------------------|
| |------------> |<-------------------| |
|---------------------------------------------------------------------|
#1 NO RTP #2
|---------------------------------------------------------------------|
#1: User A can originates or accept another call or user services without
impacting the call in hold status.
#2: The Hold terminal makes Local provision for music/video.
# : TCS = 0 means Empty capability set.
6.1.1.2) Retrieve from hold
SIP H.323
User A Proxy SG GK User B
|INVITE | | | |
|----------->| INVITE |Facility | |
| |------------->|(remoteRetrieve.inv)|Facility |
| | |------------------->|(remoteRetrieve.inv)|
| | | |------------------->|
| | | <---------------TCS ------------------>|
| | 200 OK | <-------Open Logical Channel---------->|
| 200 OK |<------------ | | |
|<---------- | | |Facility |
| ACK | |Facility |(remoteRetrieve.rr) |
|----------> | ACK |(remoteRetrieve.rr) |<-------------------|
| |------------> |<-------------------| |
| RTP |
|<------------------------------------------------------------------->|
6.1.2) H.323 Initiated
6.1.2.1) Hold
H.323 SIP
User A GK SGW Proxy User B
|Facility | | | |
|(remoteHold.inv)|Facility | | |
|--------------->|(remoteHold.inv) | | |
| |---------------->|INVITE (c=0) | |
| | |--------------->|INVITE (c=0) |
| | | |---------------->|
| | | | 200 OK |
| | | 200 OK |<--------------- |
| | |<-------------- | |
|<--------------TCS = 0 ---------->| | |
|<--------------CLC -------------->| | |
| | Facility | | |
| Facility |(remoteHold.rr) | ACK | |
| (remoteHold.rr)|<--------------- |--------------->|ACK |
| <--------------| | |---------------->|
|---------------------------------------------------------------------|
#1 NO RTP #2
|---------------------------------------------------------------------|
#1: User A can originates or accept another call or user services without
impacting the call in hold status.
#2: The Hold terminal makes Local provision for music/video.
6.1.2.2 Retrieve Hold
User A GK SGW Proxy User B
|Facility | | | |
|(remoteRetrieve.inv)|Facility | | |
|------------------> |(remoteRetrieve.inv) | | |
| |-------------------->|INVITE | |
| | |----------->|INVITE |
| | | |------------->|
| | | | 200 OK |
| | | 200 OK |<-------------|
| | |<---------- | |
|<--------------TCS ---------------------->| | |
|<--------------OLC ---------------------->| | |
| | Facility | | |
| Facility |(remoteRetrieve.rr) | ACK | |
| (remoteRetrieve.rr)|<------------------ |----------->|ACK |
| <----------------- | | |------------->|
| RTP |
|<-------------------------------------------------------------------->|
6.2) Remote End Call Hold In GK routed Model (GK acts on remote hold request on behalf of User B).
6.2.1) SIP initiated
6.2.1.1) Hold
SIP H.323
User A Proxy SGW GK User B
|INVITE(c=0) | | | |
|----------->| INVITE (c=0) |Facility | |
| |------------->|(remoteHold.inv) | |
| | |------------------->| |
| | | <---------------TCS = 0 --------------->|
| | 200 OK | <------=Close Logical Channel---------->|
| 200 OK |<------------ | | |
|<---------- | | |<-----TCS---------->|
| ACK | | |<-----MSD---------->|
|----------> | ACK | |<-----OLC---------->|
| |------------> |Facility |Facility |
| | | (remoteHold.rr) |(holdNotific.inv) |
| | |<-------------------|------------------->|
|------------------------------------------------| |
#1 NO RTP |------MUSIC/VIDE0-->|
|------------------------------------------------| |
Note: The GK/proxy acts upon the received remote-end call hold invocation. "Third party initiated pause and re-routing" procedures according to H.323 clause 8.4.6 may be used for closing the channels between endpoints A and B as well as for establishing new channels for MOH provision between the GK/proxy and endpoint B.
#1: User A can originates or accept another call or user services without
impacting the call in hold status.
6.2.1.2) Retreive from hold
SIP H.323
User A Proxy SGW GK User B
|INVITE | | | |
|----------->|INVITE |Facility | |
| |------------->|(remoteRetrieve.inv)| |
| | |------------------->| |
| | | |<-----TCS=0--------->|
| | | |<-----CLC----------->|
| | |<---------------TCS --------------------->|
| | 200 OK |<----------Open Logical Channel---------->|
| 200 OK |<------------ | | |
|<---------- | | | |
| ACK | | | |
|----------> | ACK | | |
| |------------> |Facility |Facility |
| | |(remoteRetrieve.rr) |(retrieveNotific.inv)|
| | |<-------------------|-------------------> |
| RTP |
|<-------------------------------------------------------------------->|
6.3) Near End Call Hold for GK Transparent
6.3.1) SIP Initiated
6.3.1.1) Hold
User A Proxy SGW GK User B
|INVITE(c=0) | | | |
|----------->| INVITE (c=0) |Facility | |
| |------------->|(holdNotific.inv) |Facility |
| | |------------------->| (holdNotific.inv) |
| | | |------------------->|
| | | <---------------TCS = 0 --------------->|
| | 200 OK | <-------Close Logical Channel ???? --->|
| 200 OK |<------------ | | |
|<-----------| | | |
| ACK | | | |
|----------> | ACK | | |
| |------------> | | |
| | | | |
|---------------------------MUSIC/VIDEO ?????? --------------------->|
ISSUE:
1) In this case the USER B shell continue listening to the receiving channel. However in SIP Hold procedures, SIP Closes the Media Channels.
2) So For User B, How to play MUSIC/VIDEO?
3) Can SG play the MUSIC/VIDEO for User B?
4) Or SG shell always use Remote End Call Hold.
6.3.1.2) Retreive from hold
User A Proxy SGW GK User B
|INVITE | | | |
|----------->|INVITE |Facility | |
| |------------->|(RetrieveNotific.inv)|Facility |
| | |-------------------> |(retrieveNotific.inv)|
| | | |-------------------> |
| | | <---------------TCS --------------------->|
| | 200 OK | <----------Open Logical Channel---------->|
| 200 OK |<------------ | | |
|<---------- | | |Facility |
| ACK | | | |
|----------> | ACK | | |
| |------------> | | |
| RTP |
|<--------------------------------------------------------------------->|
6.3.2) H.323 Initiated
6.3.2.1) Hold
H.323 SIP
User A GK SGW Proxy User B
|Facility | | | |
|(HoldNotific.inv) |Facility | | |
|------------------> |(HoldNotific.inv) | | |
| |-------------------->|INVITE(c=0) | |
| | |----------->|INVITE(c=0) |
| | | |------------->|
| | | | 200 OK |
| | | 200 OK |<------------ |
| | |<---------- | |
|<--------------TCS = 0 ------------------->| | |
|<--------------CLC ----------------------->| | |
| | | ACK | |
| | |----------->| ACK |
| | | |------------->|
|-----------------------------------------------------------------------|
| NO RTP |
|-----------------------------------------------------------------------|
ISSUE: 1) If SG sends INVITE with c=0 then USER B will close the media channel, If SG sends INVITE a normal invite then how to indicate User B about Hold. Should the GK always proxy the 'Near End Hold Request' by 'Remote End Hold Reqest', However this will not prevent the SIP agent 'USER B' to close the channel. Then how to implement 'Near End Hold Request'?
6.3.2.2) Retreive from hold
User A GK SGW Proxy User B
|Facility | | | |
|(RetrieveNotific.inv)|Facility | | |
|------------------> |(RetrieveNotific.inv)| | |
| |-------------------->|INVITE | |
| | |----------->|INVITE |
| | | |------------->|
| | | | 200 OK |
| | | 200 OK |<-------------|
| | |<---------- | |
|<--------------TCS ----------------------->| | |
|<--------------OLC ----------------------->| | |
| | | ACK | |
| | |----------->| ACK |
| | | |------------->|
| RTP |
|<--------------------------------------------------------------------->|
-------------- next part --------------
SIP - H.323 Interworking Call Scenarios
_______________________________________
HEMANT AGRAWAL & VIPIN PALAWAT
REF:1) draft-singh-sip-h323-00
2) draft-sparks-sip-service-examples-00
3) ITU-T H.323
3) ITU-T H.450.2(CallTransfer Supp. Services For H.323)
4) ITU-T H.450.3(CallDiversion Supp. Services For H.323)
5) ITU-T draft H.450.4(Call Hold Supplementary Services For H.323)
INDEX:
1) Call from H.323 Network to SIP Network
1.1) Simple call from H.323 terminal to SIP Terminal
1.2) Call with H.323 Gatekeeper and SIP Proxy Server
1.3) Call with H.323 Gatekeeper and SIP Redirect Server
2) Call from SIP Network to H.323 Network
2.1) Simple call from SIP Terminal to H.323 Terminal
2.2) Call with SIP Proxy and H.323 Gatekeeper
2.3) Call with SIP Redirect and H.323 Gatekeeper
3) Special Scenarios
3.1) Fast Connect Procedures
3.1.1) With SIP Proxy server and H.323 Gatekeeper
3.2) Tunneling Procedure
3.2.1) With SIP Proxy Server and H.323 Gatekeeper
4) Call Transfer Service interworking in SIP-H.323 GW
4.1) H.323 terminal transfer the call from SIP Terminal to SIP Terminal
4.2) H.323 terminal transfer the call from H.323 Terminal to SIP Terminal
5) Call Diversion Service interworking in SIP-H.323 GW
5.1) Call Forwarding on Busy invoked by H.323 GK
5.2) Call Forwarding on Busy, invoked by SIP Proxy
5.3) Call Forwarding on No Answer invoked by H.323 GK
5.4) Call Forwarding on No Answer, invoked by Proxy
6) Call Holding Service interworking in SIP-H.323 GW
6.1) Remote End Call Hold When GK is Transparent.
6.1.1) SIP initiated
6.1.1.1) Hold
6.1.1.2) Retrieve from hold
6.1.2) H.323 Initiated
6.1.2.1) Hold
6.1.2.2) Retrieve from hold
6.2) Remote End Call Hold In GK routed Model
6.2.1) SIP initiated
6.2.1.1) Hold
6.2.1.2) Retreive from hold
6.3) Near End Call Hold for GK Transparent
6.3.1) SIP Initiated
6.3.1.1) Hold
6.3.1.2) Retreive from hold
6.3.2) H.323 Initiated
6.3.2.1) Hold
6.3.2.2) Retreive from hold
1)Call from H.323 Network to SIP Network
1.1) Simple call from H.323 terminal to SIP Terminal
H.323 SIP
EP Setup SGW EP
|------------>| INVITE |
| |------------>|
| | 180 RINGING |
| Alerting |<------------|
|<------------| 200 OK |
| Connect |<------------|
|<------------| |
| H.245 | |
|<----------->| ACK |
| |------------>|
| RTP |
|<------------------------->|
This is a simple call from H.323 network to SIP network which does not involve H.323 gatekeeper and SIP servers. The protocol conversion, i.e. message and parameters mapping between H.323 and SIP is done by the signalling gateway(SGW).
1.2) Call with H.323 Gatekeeper and SIP Proxy Server
H.323 H.323 SIP SIP
EP GK SGW Proxy EP
| ARQ | | | |
|------------>| | | |
| ACF | | | |
|<------------| | | |
| Setup | | | |
|------------>| Setup | | |
| |------------>| | |
| | ARQ | | |
| |<------------| | |
| | ACF | | |
| |------------>| INVITE | |
| | |------------>| INVITE |
| | | |------------>|
| | | | 180 RINGING |
| | | 180 RINGING |<------------|
| | Alerting |<------------| |
| Alerting |<------------| | |
|<------------| | | 200 OK |
| | | 200 OK |<------------|
| | Connect |<------------| |
| Connect |<------------| | |
|<------------| | | |
| H.245 | | |
|<------------------------->| ACK | |
| | |------------>| ACK |
| | | |------------>|
| | | | |
| | RTP | |
|<----------------------------------------------------->|
In this scenario, the ACK will be sent to SIP side only after the completion of H.245 . This is because the channel parameters and capabilities of H.323 terminal needs to be communicated to SIP side which can only be done after capabilities exchange and OLC on H.323 side.
1.3) Call with H.323 Gatekeeper and SIP Redirect Server
H.323 H.323 SIP SIP
EP GK SGW Redirect EP
| ARQ | | | |
|------------>| | | |
| ACF | | | |
|<------------| | | |
| Setup | | | |
|------------>| Setup | | |
| |----------->| | |
| | ARQ | | |
| |<-----------| | |
| | ACF | | |
| |----------->| INVITE | |
| | |----------->| |
| | | 302 Moved | |
| | |<-----------| |
| | | ACK | |
| | |----------->| |
| | | INVITE |
| | |-------------------------->|
| | | 180 RINGING |
| | Alerting |<--------------------------|
| Alerting |<-----------| |
|<------------| | 200 OK |
| | Connect |<--------------------------|
| Connect |<-----------| |
|<------------| | |
| H.245 | |
|<------------------------>| ACK |
| |-------------------------->|
| RTP |
|<---------------------------------------------------->|
In this scenario, the SIP redirect server will contact the location server to find out the address of the destination endpoint. This address will be returned in the 3xx response from SIP redirect server. As mentioned in 1.2 above, the ACK will be sent only after the completion of H.245 on H.323 side.
2) Call from SIP Network to H.323 Network
2.1) Simple call from SIP Terminal to H.323 Terminal
SIP H.323
EP SGW EP
| | |
| INVITE | |
|------------>| Setup |
| |----------->|
| | Alerting |
| 180 RINGING |<-----------|
|<------------| Connect |
| |<-----------|
| | H.245 |
| 200 OK |<---------->|
|<------------| |
| ACK | |
|------------>| |
| RTP |
|<------------------------>|
In this scenario, the 200 OK response is sent only after H.245 gets completed on H.323 side. This is because the capabilities and the channel information needs to be communicated to the SIP side which can be done by 200 OK after H.245. The other possibility is to send OPTIONS which will communicate the capabilities and channel information to SIP side. In this case the 200 OK can be sent immediatly after "Connect" is received from H.323 side.
2.2) Call with SIP Proxy and H.323 Gatekeeper
SIP SIP H.323 H.323
EP Proxy SGW GK EP
| | | | |
| INVITE | | | |
|------------>| INVITE | | |
| |------------>| ARQ | |
| | |------------>| |
| | | ACF | |
| | |<------------| |
| | | Setup | |
| | |------------>| Setup |
| | | |------------>|
| | | | ARQ |
| | | |<------------|
| | | | ACF |
| | | |------------>|
| | | | Alerting |
| | | Alerting |<------------|
| | 180 RINGING |<------------| |
| 180 RINGING |<------------| | |
|<------------| | | Connect |
| | | Connect |<------------|
| | |<------------| |
| | | H.245 |
| | 200 OK |<------------------------->|
| 200 OK |<------------| | |
|<------------| | | |
| ACK | | | |
|------------>| ACK | | |
| |------------>| | |
| | RTP | |
|<----------------------------------------------------->|
This scenario is very much similar to the case 2.1 shown above. In this case, the 200 OK is sent only after completing H.245 on H.323 side.
2.3) Call with SIP Redirect and H.323 Gatekeeper
SIP SIP H.323 H.323
EP Redirect SGW GK EP
| INVITE | | | |
|------------>| | | |
| 302 Moved | | | |
|<------------| | | |
| ACK | | | |
|------------>| | | |
| INVITE | | |
|-------------------------->| ARQ | |
| | |------------>| |
| | | ACF | |
| | |<------------| |
| | | Setup | |
| | |------------>| Setup |
| | | |------------>|
| | | | ARQ |
| | | |<------------|
| | | | ACF |
| | | |------------>|
| | | | Alerting |
| | | Alerting |<------------|
| |180 Ringing |<------------| |
|180 Ringing |<------------| | |
|<------------| | | Connect |
| | | Connect |<------------|
| | |<------------| |
| | | H.245 |
| 200 OK |<------------------------->|
|<--------------------------| | |
| ACK | | |
|-------------------------->| | |
| | RTP | |
|<----------------------------------------------------->|
3)Special Scenarios
3.1)Fast Connect Procedures
3.1.1) With SIP Proxy server and H.323 Gatekeeper
SIP SIP H.323 H.323
EP Proxy SGW GK EP
| | | | |
| | | | |
| INVITE | | | |
|------------>| INVITE | | |
| |------------>| ARQ | |
| | |------------>| |
| | | ACF | |
| | |<------------| |
| | | Setup(with | |
| | | fast start | |
| | | and OLC) | |
| | |------------>| Setup(with |
| | | | fast start |
| | | | and OLC) |
| | | |------------>|
| | | | ARQ |
| | | |<------------|
| | | | ACF |
| | | |------------>|
| | | |Alerting(with|
| | | |fast start) |
| | |Alerting(with|<------------|
| | |fast start) | |
| | 180 RINGING |<------------| |
| 180 RINGING |<------------| | |
|<------------| | |Connect(with |
| | | |fast start |
| | | |and OLC) |
| | |Connect(with |<------------|
| | |fast start | |
| | |and OLC) | |
| | 200 OK |<------------| |
| 200 OK |<------------| | |
|<------------| | | |
| ACK | | | |
|------------>| ACK | | |
| |------------>| | |
| | RTP | |
|<----------------------------------------------------->|
In this scenario, fast connect procedure is used on H.323 side. The MSD,Capability Exchange and OLC is done with Q.931 messages.
3.2) Tunneling Procedure
3.2.1) With SIP Proxy Server and H.323 Gatekeeper
SIP SIP H.323 H.323
EP Proxy SGW GK EP
| | | | |
| INVITE | | | |
|------------>| INVITE | | |
| |------------>|Setup(tunn.= | |
| | |true,MSD,TCS)| |
| | |------------>| |
| | | ARQ | |
| | |<------------| |
| | | ACF | |
| | |------------>| Setup(MSD, |
| | | | TCS) |
| | | |------------>|
| | | | ARQ |
| | | |<------------|
| | | | ACF |
| | | |------------>|
| | | |Alerting(MSD |
| | | |Ack,TCS Ack, |
| | | |TCS,MSD) |
| | |Alerting(MSD |<------------|
| | |Ack,TCS Ack, | |
| | |TCS,MSD) | |
| | 180 RINGING |<------------| |
| 180 RINGING |<------------| | |
|<------------| |Facility(TCS | |
| | |Ack,MSD Ack, | |
| | |OLC) | |
| | |------------>|Facility(TCS |
| | | |Ack,MSD Ack, |
| | | |OLC) |
| | | |------------>|
| | | |Facility(OLC |
| | | |Ack,OLC) |
| | |Facility(OLC |<------------|
| | |Ack,OLC) | |
| | |<------------| |
| | |Facility(OLC | |
| | |Ack) | |
| | |------------>|Facility(OLC |
| | | |Ack) |
| | | |------------>|
| | | | Connect |
| | | Connect |<------------|
| | 200 OK |<------------| |
| 200 OK |<------------| | |
|<------------| | | |
| ACK | | | |
|------------>| ACK | | |
| |------------>| | |
| | RTP | |
|<----------------------------------------------------->|
This scenario takes care of H.245 tunnelling procedures on H.323 side. The tunnelled H.245 messages goes along with Q.931 and Q.932 messages.
4 ) Call Transfer Service interworking in SIP-H.323
4.1) H.323 terminal transfer the call from SIP Terminal to SIP Terminal
H.323 SIP SIP
EP(A) SGW EP(B) EP(C)
| | | |
| Setup | | |
|------------>| INVITE | |
| |------------>| |
| | 180 RINGING | |
| Alerting |<------------| |
|<------------| 200 OK | |
| Connect |<------------| |
|<------------| | |
| H.245 | | |
|<----------->| ACK | |
| |------------>| |
| RTP | |
|<------------------------->| |
| Facility | | |
|(ctInitiate. | | |
| Invoke) | | |
|------------>| BYE | |
| |(Location:C) | |
| |------------>| |
| | 200 OK | |
|Release Comp.|<------------| |
|(ctInitiate. | | |
|ReturnResult)| | INVITE (C) |
|<------------| |------------>|
| | | 200 OK |
| | |<------------|
| | | ACK |
| | |------------>|
| | | RTP |
| | |<----------->|
In this scenario, H.323 terminal talking to a SIP terminal initiates the call transfer for a SIP termianl. The procedure for call transfer is done according to H.450.2 on H.323 side.
4.2)H.323 terminal transfer the call from H.323 Terminal to SIP Terminal
H.323 H.323 SIP
EP(A) EP(B) SGW EP(C)
| | | |
| Setup | | |
|------------>| | |
| Alerting | | |
|<------------| | |
| Connect | | |
|<------------| | |
| H.245 | | |
|<----------->| | |
| RTP | | |
|<----------->| | |
| Facility | | |
|(ctInitiate. | | |
| Invoke) | | |
|------------>| Setup | |
| |(ctSetup. | |
| | Invoke) | |
| |----------->| INVITE |
| | |----------->|
| | | 180 RINGING|
| | |<-----------|
| | | 200 OK |
| |Connect |<-----------|
| |(ctSetup. | |
| |ReturnResult| |
|Release Comp.|<-----------| |
|(ctInitiate. | | |
|ReturnResult)| | |
|<------------| H.245 | |
| |<---------->| ACK |
| | |----------->|
| | RTP |
| |<----------------------->|
In this scenarion, H.323 terminal talking to a H.323 terminal initiates a call transfer for a SIP terminal. The procedure on H.323 side is according to H.450.2 and on SIP side, it is in accordance with the "SIP call control services".
5) Call Diversion Service interworking in SIP-H.323 GW
It is assumed in all the call flows shown that SIP User agent has turned on the required forwarding feature in the Proxy server and H.323 end point has activated the features in the H.323 Gatekeeper.
ISSUE: Should the Cross domain activation of Features allowed eg. A Sip terminal tells a H.323 GK (thru SIP-H.323 GK) about forwarding all the calls for him to another terminal in SIP Domain.
5.1) Call Forwarding on Busy, invoked by H.323 GK
SIP User A Proxy SGW GK H.323 User B User C
| INVITE | | | | |
|----------> | INVITE | | | |
|100 Try |-------------> | SETUP | | |
|<---------- | |-------------> | SETUP | |
| | | Call Proc |-------------> | |
| | |<------------- | RELEASE COMP | |
| | | |(cause:userbusy| |
| | | |<------------- | |
| | |Facility(divert|SETUP(diverting| |
| | |ingLegInfo1.inv| LegInfo4.inv) | |
| | | |-------------->| |
| | 181 Call Fwd. | <-------------| RELEASE COMP | |
|181 Call Fwd|<--------------| | <------------ | |
|<-----------| | |SETUP | |
| | | |(divertingLegInfo2.inv) |
| | | | ---------------------->|
| | | | ARQ | |
| | | |<-----------------------|
| | | | ACF | |
| | | | ---------------------->|
| | | | ALERTING | |
| | | ALERTING |<-----------------------|
| | 180 Ringing |<--------------| CONNECT | |
|180 Ringing |<------------- | CONNECT |<-----------------------|
|<-----------| |<--------------| | |
| | |< ------------------ H.245------------->|
| | 200 OK | | | |
|200 OK |<------------- | | | |
|<---------- | | | | |
| ACK | | | | |
| ---------->| ACK | | | |
| |-------------> | | | |
|---------------------------------------------------------------------|
| RTP BOTH WAYS |
|---------------------------------------------------------------------|
ISSUE: On the Receive of Facility (divertingLegInfo1.inv) at SGW how to indicate the SIP user agent about the forwarding.
5.2) Call Forwarding on Busy, invoked by SIP Proxy
SIP User A Proxy SGW H.323 User B User C
| INVITE | | | |
|----------> | INVITE | | |
|100 Try |-------------> | SETUP | |
|<---------- | |-------------> | |
| | | RELEASE COMP | |
| | |(cause:userbusy| |
| | 486 Busy Here |<------------- | |
| | <-------------| | |
| | ACK | | |
| |-------------->| | |
| | INVITE | | |
| | ------------->| SETUP | |
| | |-------------->| SETUP |
| | | |------------->|
| | | | ALERTING |
| | | ALERTING |<-------------|
| | 180 Ringing |<--------------| CONNECT |
|180 Ringing |<------------- | CONNECT |<-------------|
|<-----------| |<--------------| |
| | |< ---------- H.245 --------- >|
| | 200 OK | | |
|200 OK |<------------- | | |
|<---------- | | | |
| ACK | | | |
| ---------->| ACK | | |
| |-------------> | | |
|-----------------------------------------------------------|
| RTP BOTH WAYS |
|-----------------------------------------------------------|
ISSUE: 1) How to inform H.323 User C about forwarding.
5.3)Call Forwarding on No Answer, invoked by H.323 GK
H.323 SIP SIP
User A GK SGW User B User C
| ARQ | | | |
|------------>| | | |
| ACF | | | |
|<------------| | | |
| Setup | | | |
|------------>| Setup | | |
| |------------>| | |
| | ARQ | | |
| |<------------| | |
| | ACF | | |
| |------------>| INVITE | |
| | |------------>| |
| | | 180 RINGING | |
| | Alerting |<------------| |
| Alerting |<------------| | |
|<------------| Setup | | |
| Request . | (diverting | | |
| Time | LegInfo2. | | |
| Out . | inv) | | |
| ...|------------>| INVITE |
| | Facility |-------------------------->|
| |(diverting | | |
| | LegInfo4. | | |
| | inv) | | |
| |------------>|181 Call Fwd.| |
| | |------------>| |
| | | 180 RINGING |
| | Alerting |<--------------------------|
| |<------------| | |
| | Release | | |
| | Complete | | |
| Facility |------------>| CANCEL | |
|(diverting | |------------>| |
| LegInfo1. | | 200 OK | |
| inv) | Connect |<------------| |
|<------------|(diverting | 200 OK |
| Connect | LegInfo3.|<--------------------------|
|(diverting | inv) | | |
| LegInfo3. |<------------| | |
| inv) | | | |
|<------------| | | |
| H.245 | | |
|<------------------------->| ACK |
| | |-------------------------->|
| | RTP | |
|<----------------------------------------------------->|
ISSUE: 1) On the Receive of Facility (divertingLegInfo4.inv) at SGW how to indicate the SIP user agent about the forwarding.
2) Once the User C Alerted the H.323 GK should send RELEASE COMPLETE for User B. While in SIP Call flows[2], INVITE is going to User C only after sending the CANCEL to User B. At present we are Sending RELEASE COMPLETE for USER B after User C gets alerted.
5.4)Call Forwarding on No Answer, invoked by Proxy
SIP SIP H.323
User A Proxy User B SGW User C
| INVITE | | | |
|------------>| INVITE | | |
| |------------>| | |
| | 180 RINGING | | |
| 180 RINGING |<------------| | |
|<------------| | | |
| | Request | | |
| | Time | | |
| . | Out | | |
| . | | | |
| . | CANCEL | | |
| ... |------------>| | |
| | 200 OK | | |
| |<------------| | |
| | INVITE(C) | |
| |------------------------>| Setup |
| | | |--------->|
| | | | Alerting |
| | 180 RINGING |<---------|
| |<------------------------| Connect |
| | | |<---------|
| | | | H.245 |
| | 200 OK |<-------->|
| 200 OK |<------------------------| |
|<------------| | | |
| ACK | | | |
|------------>| ACK | |
| |------------------------>| |
| | RTP | |
|<------------------------------------------------>|
6) Call Holding Service interworking in SIP-H.323 GW
In H.450.4, Call Hold (SS-HOLD) allows the served user, which may be the originally calling or the called user, to interrupt communications on an existing call and then subsequently, if desired, re-establish (i.e. retrieve) communications with the held user. Hold may only be invoked by the served user for a call in the active state. Communication on the media channels is interrupted and the call is placed in the held state. The distant party is informed, and if appropriate, a specific MOH pattern (e.g. video and/or music on hold) may be provided to the held user. The served user may then originate or accept other calls, or use other services without impacting the call in the held state. Two scenarios are specified for SS-HOLD, "Near-end Call Hold" and "Remote-end Call Hold". The decision whether to invoke one or the other of the methods is an implementation and application matter.
Remote-end Call Hold: The holding endpoint sends a hold request to the remote endpoint requiring the held endpoint to provide MOH to the held user.
Near-end Call Hold: The holding endpoint informs the held endpoint of the hold condition by sending a hold notification and stops receiving user packets from the held endpoint as well as sending user packets to the held endpoint. The held endpoint upon receiving the hold notification may stop sending user packets but shall continue listening to the receive channel.
6.1) Remote End Call Hold When GK is Transparent.
6.1.1) SIP initiated
6.1.1.1) Hold
SIP H.323
User A Proxy SGW GK User B
|INVITE(c=0) | | | |
|----------->| INVITE (c=0) |Facility | |
| |------------->|(remoteHold.inv) |Facility |
| | |------------------->|(remoteHold.inv) |
| | | |------------------->|
| | | <---------------TCS = 0 --------------->|
| | 200 OK | <-------Close Logical Channel---------->|
| 200 OK |<------------ | | |
|<---------- | | |Facility |
| ACK | |Facility |(remoteHold.rr) |
|----------> | ACK |(remoteHold.rr) |<-------------------|
| |------------> |<-------------------| |
|---------------------------------------------------------------------|
#1 NO RTP #2
|---------------------------------------------------------------------|
#1: User A can originates or accept another call or user services without
impacting the call in hold status.
#2: The Hold terminal makes Local provision for music/video.
# : TCS = 0 means Empty capability set.
6.1.1.2) Retrieve from hold
SIP H.323
User A Proxy SG GK User B
|INVITE | | | |
|----------->| INVITE |Facility | |
| |------------->|(remoteRetrieve.inv)|Facility |
| | |------------------->|(remoteRetrieve.inv)|
| | | |------------------->|
| | | <---------------TCS ------------------>|
| | 200 OK | <-------Open Logical Channel---------->|
| 200 OK |<------------ | | |
|<---------- | | |Facility |
| ACK | |Facility |(remoteRetrieve.rr) |
|----------> | ACK |(remoteRetrieve.rr) |<-------------------|
| |------------> |<-------------------| |
| RTP |
|<------------------------------------------------------------------->|
6.1.2) H.323 Initiated
6.1.2.1) Hold
H.323 SIP
User A GK SGW Proxy User B
|Facility | | | |
|(remoteHold.inv)|Facility | | |
|--------------->|(remoteHold.inv) | | |
| |---------------->|INVITE (c=0) | |
| | |--------------->|INVITE (c=0) |
| | | |---------------->|
| | | | 200 OK |
| | | 200 OK |<--------------- |
| | |<-------------- | |
|<--------------TCS = 0 ---------->| | |
|<--------------CLC -------------->| | |
| | Facility | | |
| Facility |(remoteHold.rr) | ACK | |
| (remoteHold.rr)|<--------------- |--------------->|ACK |
| <--------------| | |---------------->|
|---------------------------------------------------------------------|
#1 NO RTP #2
|---------------------------------------------------------------------|
#1: User A can originates or accept another call or user services without
impacting the call in hold status.
#2: The Hold terminal makes Local provision for music/video.
6.1.2.2 Retrieve Hold
User A GK SGW Proxy User B
|Facility | | | |
|(remoteRetrieve.inv)|Facility | | |
|------------------> |(remoteRetrieve.inv) | | |
| |-------------------->|INVITE | |
| | |----------->|INVITE |
| | | |------------->|
| | | | 200 OK |
| | | 200 OK |<-------------|
| | |<---------- | |
|<--------------TCS ---------------------->| | |
|<--------------OLC ---------------------->| | |
| | Facility | | |
| Facility |(remoteRetrieve.rr) | ACK | |
| (remoteRetrieve.rr)|<------------------ |----------->|ACK |
| <----------------- | | |------------->|
| RTP |
|<-------------------------------------------------------------------->|
6.2) Remote End Call Hold In GK routed Model (GK acts on remote hold request on behalf of User B).
6.2.1) SIP initiated
6.2.1.1) Hold
SIP H.323
User A Proxy SGW GK User B
|INVITE(c=0) | | | |
|----------->| INVITE (c=0) |Facility | |
| |------------->|(remoteHold.inv) | |
| | |------------------->| |
| | | <---------------TCS = 0 --------------->|
| | 200 OK | <------=Close Logical Channel---------->|
| 200 OK |<------------ | | |
|<---------- | | |<-----TCS---------->|
| ACK | | |<-----MSD---------->|
|----------> | ACK | |<-----OLC---------->|
| |------------> |Facility |Facility |
| | | (remoteHold.rr) |(holdNotific.inv) |
| | |<-------------------|------------------->|
|------------------------------------------------| |
#1 NO RTP |------MUSIC/VIDE0-->|
|------------------------------------------------| |
Note: The GK/proxy acts upon the received remote-end call hold invocation. "Third party initiated pause and re-routing" procedures according to H.323 clause 8.4.6 may be used for closing the channels between endpoints A and B as well as for establishing new channels for MOH provision between the GK/proxy and endpoint B.
#1: User A can originates or accept another call or user services without
impacting the call in hold status.
6.2.1.2) Retreive from hold
SIP H.323
User A Proxy SGW GK User B
|INVITE | | | |
|----------->|INVITE |Facility | |
| |------------->|(remoteRetrieve.inv)| |
| | |------------------->| |
| | | |<-----TCS=0--------->|
| | | |<-----CLC----------->|
| | |<---------------TCS --------------------->|
| | 200 OK |<----------Open Logical Channel---------->|
| 200 OK |<------------ | | |
|<---------- | | | |
| ACK | | | |
|----------> | ACK | | |
| |------------> |Facility |Facility |
| | |(remoteRetrieve.rr) |(retrieveNotific.inv)|
| | |<-------------------|-------------------> |
| RTP |
|<-------------------------------------------------------------------->|
6.3) Near End Call Hold for GK Transparent
6.3.1) SIP Initiated
6.3.1.1) Hold
User A Proxy SGW GK User B
|INVITE(c=0) | | | |
|----------->| INVITE (c=0) |Facility | |
| |------------->|(holdNotific.inv) |Facility |
| | |------------------->| (holdNotific.inv) |
| | | |------------------->|
| | | <---------------TCS = 0 --------------->|
| | 200 OK | <-------Close Logical Channel ???? --->|
| 200 OK |<------------ | | |
|<-----------| | | |
| ACK | | | |
|----------> | ACK | | |
| |------------> | | |
| | | | |
|---------------------------MUSIC/VIDEO ?????? --------------------->|
ISSUE:
1) In this case the USER B shall continue listening to the receiving channel. However in SIP Hold procedures, SIP Closes the Media Channels.
2) So For User B, How to play MUSIC/VIDEO?
3) Can SG play the MUSIC/VIDEO for User B?
4) Or SG shell always use Remote End Call Hold.
6.3.1.2) Retreive from hold
User A Proxy SGW GK User B
|INVITE | | | |
|----------->|INVITE |Facility | |
| |------------->|(RetrieveNotific.inv)|Facility |
| | |-------------------> |(retrieveNotific.inv)|
| | | |-------------------> |
| | | <---------------TCS --------------------->|
| | 200 OK | <----------Open Logical Channel---------->|
| 200 OK |<------------ | | |
|<---------- | | |Facility |
| ACK | | | |
|----------> | ACK | | |
| |------------> | | |
| RTP |
|<--------------------------------------------------------------------->|
6.3.2) H.323 Initiated
6.3.2.1) Hold
H.323 SIP
User A GK SGW Proxy User B
|Facility | | | |
|(HoldNotific.inv) |Facility | | |
|------------------> |(HoldNotific.inv) | | |
| |-------------------->|INVITE(c=0) | |
| | |----------->|INVITE(c=0) |
| | | |------------->|
| | | | 200 OK |
| | | 200 OK |<------------ |
| | |<---------- | |
|<--------------TCS = 0 ------------------->| | |
|<--------------CLC ----------------------->| | |
| | | ACK | |
| | |----------->| ACK |
| | | |------------->|
|-----------------------------------------------------------------------|
| NO RTP |
|-----------------------------------------------------------------------|
ISSUE: 1) If SG sends INVITE with c=0 then USER B will close the media channel, If SG sends INVITE a normal invite then how to indicate User B about Hold. Should the GK always proxy the 'Near End Hold Request' by 'Remote End Hold Reqest', However this will not prevent the SIP agent 'USER B' to close the channel. Then how to implement 'Near End Hold Request'?
6.3.2.2) Retreive from hold
User A GK SGW Proxy User B
|Facility | | | |
|(RetrieveNotific.inv)|Facility | | |
|------------------> |(RetrieveNotific.inv)| | |
| |-------------------->|INVITE | |
| | |----------->|INVITE |
| | | |------------->|
| | | | 200 OK |
| | | 200 OK |<-------------|
| | |<---------- | |
|<--------------TCS ----------------------->| | |
|<--------------OLC ----------------------->| | |
| | | ACK | |
| | |----------->| ACK |
| | | |------------->|
| RTP |
|<--------------------------------------------------------------------->|
More information about the sg16-avd
mailing list