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

[Sasha Ruditsky]

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 at lists.packetizer.com
[mailto:itu-sg16-bounces at lists.packetizer.com] On Behalf Of Paul E.
Jones
Sent: Thursday, January 07, 2010 8:51 PM
To: itu-sg16 at lists.packetizer.com; h323implementers at 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

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20100108/d7b61a34/attachment-0004.html>