[itu-sg16] Facility-based call transfer in H.323

Paul E. Jones paulej at packetizer.com
Thu Jan 7 20:50:53 EST 2010



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.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20100107/5ac3dd9b/attachment-0003.html>

More information about the sg16-avd mailing list