[itu-sg16] Facility-based call transfer in H.323
Folks, For years - perhaps since the first release of H.323 - many vendors have supported a means of doing a simple call transfer by sending a Facility message. The problem is that, while it's extremely trivial to implement, some devices didn't because it was not officially supported in H.323. Cisco took a proposal to the ITU years ago (D.345 from February 2000) proposing that we standardize it by adding it to H.323v4 officially. Unfortunately, it was rejected in favor of keeping a single mechanism for doing call transfer: H.450.2. However, it was not immediately dismissed: there were at least some who felt that it might be useful, but rather than introducing a new "callTransfer" reason, re-used "callForwarded" as is commonly (though not universally) implemented. Ultimately, though, the proposal went nowhere. The issue has not gone away, though, and it's now 2009. I believe we still need to introduce this procedure formally to H.323. I would not want to propose changes to the ASN.1, but I would like to legitimize sending Facility with a reason of "callForwarded" in order to perform a call transfer. Some devices may not support it, but that's the way things are today. My hope would be that at least more people would know about it. As an undocumented behavior, we have inconsistency in devices. What is the opinion of others? I'd be glad to submit a formal contribution to the next Q2/16 meeting if there is interest, but I'd like to hear from people both for or against the proposed change. If introduced, it would be an Amendment to H.323v7. To write this contribution, though, we probably need some guidance on what to do when a device does not respond to the Facility message. How do devices behave today? Do they assume the transfer failed if a Release Complete is not received within n seconds? In any case, please give me your opinion. Paul
Hi Paul, BTW, It is 2010 already! Happy New Year. First of all I do agree that we need to do something about this issue. The status today is that we need to "guess" what the peer is going to do with if such a Facility message. It is good if the Facility is just ignored, however, what if the peer crashes? Currently the only way we know to deal with this is to consult (before sending the message) a list of vendor and product IDs which are known to implement this procedure. It would be a little more straightforward to include some kind of more specific feature ID in SETUP/CONNECT messages. Regards, Sasha From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Thursday, January 07, 2010 8:51 PM To: itu-sg16@lists.packetizer.com; h323implementers@lists.packetizer.com Subject: [itu-sg16] Facility-based call transfer in H.323 Folks, For years - perhaps since the first release of H.323 - many vendors have supported a means of doing a simple call transfer by sending a Facility message. The problem is that, while it's extremely trivial to implement, some devices didn't because it was not officially supported in H.323. Cisco took a proposal to the ITU years ago (D.345 from February 2000) proposing that we standardize it by adding it to H.323v4 officially. Unfortunately, it was rejected in favor of keeping a single mechanism for doing call transfer: H.450.2. However, it was not immediately dismissed: there were at least some who felt that it might be useful, but rather than introducing a new "callTransfer" reason, re-used "callForwarded" as is commonly (though not universally) implemented. Ultimately, though, the proposal went nowhere. The issue has not gone away, though, and it's now 2009. I believe we still need to introduce this procedure formally to H.323. I would not want to propose changes to the ASN.1, but I would like to legitimize sending Facility with a reason of "callForwarded" in order to perform a call transfer. Some devices may not support it, but that's the way things are today. My hope would be that at least more people would know about it. As an undocumented behavior, we have inconsistency in devices. What is the opinion of others? I'd be glad to submit a formal contribution to the next Q2/16 meeting if there is interest, but I'd like to hear from people both for or against the proposed change. If introduced, it would be an Amendment to H.323v7. To write this contribution, though, we probably need some guidance on what to do when a device does not respond to the Facility message. How do devices behave today? Do they assume the transfer failed if a Release Complete is not received within n seconds? In any case, please give me your opinion. Paul
Hi, I totally agree that something needs to be done about this. If there were a way to signal support for the Facility transfer of established connections as Sasha suggests, that would certainly lessen the pain. I think the CONNECT would be the appropriate place, since the forward before the CONNECT is already in the standard. And when more and more implementations will support the transfer, our expensive equipment will finally be able to support the same basic functionality as traditional phones always have. ;-) BTW: Does anybody maintain a list of vendors/products that support the facility transfer ? Regards, Jan -- Jan Willamowius, jan@willamowius.de, http://www.gnugk.org/ Sasha Ruditsky wrote:
Hi Paul,
BTW, It is 2010 already!
Happy New Year.
First of all I do agree that we need to do something about this issue.
The status today is that we need to "guess" what the peer is going to do with if such a Facility message.
It is good if the Facility is just ignored, however, what if the peer crashes?
Currently the only way we know to deal with this is to consult (before sending the message) a list of vendor and product IDs which
are known to implement this procedure.
It would be a little more straightforward to include some kind of more specific feature ID in SETUP/CONNECT messages.
Regards,
Sasha
From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Thursday, January 07, 2010 8:51 PM To: itu-sg16@lists.packetizer.com; h323implementers@lists.packetizer.com Subject: [itu-sg16] Facility-based call transfer in H.323
Folks,
For years - perhaps since the first release of H.323 - many vendors have supported a means of doing a simple call transfer by sending a Facility message. The problem is that, while it's extremely trivial to implement, some devices didn't because it was not officially supported in H.323.
Cisco took a proposal to the ITU years ago (D.345 from February 2000) proposing that we standardize it by adding it to H.323v4 officially. Unfortunately, it was rejected in favor of keeping a single mechanism for doing call transfer: H.450.2. However, it was not immediately dismissed: there were at least some who felt that it might be useful, but rather than introducing a new "callTransfer" reason, re-used "callForwarded" as is commonly (though not universally) implemented. Ultimately, though, the proposal went nowhere.
The issue has not gone away, though, and it's now 2009. I believe we still need to introduce this procedure formally to H.323. I would not want to propose changes to the ASN.1, but I would like to legitimize sending Facility with a reason of "callForwarded" in order to perform a call transfer. Some devices may not support it, but that's the way things are today. My hope would be that at least more people would know about it. As an undocumented behavior, we have inconsistency in devices.
What is the opinion of others? I'd be glad to submit a formal contribution to the next Q2/16 meeting if there is interest, but I'd like to hear from people both for or against the proposed change. If introduced, it would be an Amendment to H.323v7.
To write this contribution, though, we probably need some guidance on what to do when a device does not respond to the Facility message. How do devices behave today? Do they assume the transfer failed if a Release Complete is not received within n seconds?
In any case, please give me your opinion.
Paul
Sasha, Happy New Year! (I'm always running behind ;-) ) Advertising the feature would be good, but it would not solve the issues I see today. I'm not opposed to adding such capability advertisement (which I guess would be a "supportedFeature"), but what I'm most interested in is documenting the procedure that is widely implemented for the benefit of some folks who didn't know about this defacto-standard behavior. For certain, boxes ought not be crashing, documented or otherwise. Paul From: Sasha Ruditsky [mailto:sasha@radvision.com] Sent: Friday, January 08, 2010 8:13 AM To: Paul E. Jones Cc: itu-sg16@lists.packetizer.com; h323implementers@lists.packetizer.com Subject: RE: [itu-sg16] Facility-based call transfer in H.323 Hi Paul, BTW, It is 2010 already! Happy New Year. First of all I do agree that we need to do something about this issue. The status today is that we need to "guess" what the peer is going to do with if such a Facility message. It is good if the Facility is just ignored, however, what if the peer crashes? Currently the only way we know to deal with this is to consult (before sending the message) a list of vendor and product IDs which are known to implement this procedure. It would be a little more straightforward to include some kind of more specific feature ID in SETUP/CONNECT messages. Regards, Sasha From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Thursday, January 07, 2010 8:51 PM To: itu-sg16@lists.packetizer.com; h323implementers@lists.packetizer.com Subject: [itu-sg16] Facility-based call transfer in H.323 Folks, For years - perhaps since the first release of H.323 - many vendors have supported a means of doing a simple call transfer by sending a Facility message. The problem is that, while it's extremely trivial to implement, some devices didn't because it was not officially supported in H.323. Cisco took a proposal to the ITU years ago (D.345 from February 2000) proposing that we standardize it by adding it to H.323v4 officially. Unfortunately, it was rejected in favor of keeping a single mechanism for doing call transfer: H.450.2. However, it was not immediately dismissed: there were at least some who felt that it might be useful, but rather than introducing a new "callTransfer" reason, re-used "callForwarded" as is commonly (though not universally) implemented. Ultimately, though, the proposal went nowhere. The issue has not gone away, though, and it's now 2009. I believe we still need to introduce this procedure formally to H.323. I would not want to propose changes to the ASN.1, but I would like to legitimize sending Facility with a reason of "callForwarded" in order to perform a call transfer. Some devices may not support it, but that's the way things are today. My hope would be that at least more people would know about it. As an undocumented behavior, we have inconsistency in devices. What is the opinion of others? I'd be glad to submit a formal contribution to the next Q2/16 meeting if there is interest, but I'd like to hear from people both for or against the proposed change. If introduced, it would be an Amendment to H.323v7. To write this contribution, though, we probably need some guidance on what to do when a device does not respond to the Facility message. How do devices behave today? Do they assume the transfer failed if a Release Complete is not received within n seconds? In any case, please give me your opinion. Paul
participants (3)
-
Jan Willamowius -
Paul E. Jones -
Sasha Ruditsky