[Asterisk-Dev] IAX and attended call transfer -- Comments please

[Benjamin on Asterisk Mailing Lists]

I am currently documenting various IAX call scenarios in form or call
flow charts.

I started this because I talked a Taiwanese phone manufacturer into
IAX and they asked me for the charts as a guide for their work on IAX
firmware for their phones. But when I contacted Frank Miller, the
author of the IAX specification document, he expressed interest to
incorporate the charts, so the scope widened a little.

It is in respect of one particular scenario that I would like to start
a discussion and get some comments because I believe that there is
room for improvement in the signalling. The scenario in question is
the attended call transfer and the issue comes down to this:

There are in principle two ways how to connect the two remote parties
during an attended call transfer:

1) the bridging of the two calls takes place on the phone that
initiates the call transfer

2) the bridging of the two calls takes place on a central server

(NB: Of course there is also the possibility to tell the end points to
establish a direct connection from their end, but for various reasons
this is not subject of this discussion.)

The two methods have their own distinct characteristics:

Method #1 first bridges the two calls using a non-optimal route
initially, then utilising a route transition mechanism to optimise the
call path afterwards.

Method #2 bridges the two calls directly thus starting with the
optimal route, avoiding the need to go through a route transition to
optimise the call path.

Depending on how the calls are routed, one method has advantages over the other:

Method #1 has an advantage in a true peer-to-peer environment where
end points first seek to establish a direct route before using the
services of a central server and where the two calls to be bridged use
different routes that do not pass through a central server.

Method #2 has an advantage in an environment where end points connect
to other end points through a central server, such as is typically the
case in an office environment.


At present, IAX only supports method #1 and I would like to discuss
the enhancement of IAX signalling so that it will also support method
#2. The effort to do so would seem fairly small.

There are two requirements in order to do this:

1) the server must have the capability of bridging the far end legs of
two calls that pass through it
2) IAX needs an additional signal to request the server to bridge the
far end legs of two calls

If the server does not fulfil requirement #1, then it could send an
INVALID message back to the requesting end point as a response to the
bridging request. The end point could then fall back to method #1. If
IAX does not fulfil requirement #2, I don't believe it is possible to
support method #2 in any other way.

I will now describe an actual call scenario for illustration ...

A is a calling party on the PSTN calling in on Asterisk server B which
routes the call to called party C using an IAX phone ...

A ---PSTN---> B ---IAX---> C

C now wants to do an attended transfer to D using a SIP phone. At
first C parks the call with A and established a second call with D ...

C ---IAX---> B ---SIP---> D

D agrees to take the call from A, so C now bridges the two calls
(using method #1) ...

A ---PSTN ---> B ---IAX---> C ---IAX---> B ---SIP---> D

Since this is not the optimal call route, C initiates an "IAX
Transfer" by sending a TXREQ to B *twice*, once for each leg of the
call as if it was saying to B "You don't need me in the middle, why
don't you talk directly to yourself?" as a result of which B will
optimise the route removing C from the call path ...

B <---TXREQ--- C ---TXREQ---> B
B --------------------TXCNT----------> B
B <------------------TXACC-----------  B
B <------------------TXCNT------------ B
B --------------------TXACC----------> B
B -TXREADY-> C <-TXREADY- B
B <---TXREL---- C ----TXREL---> B
B ---------------------VOICE----------> B
B <-------------------VOICE------------ B

The end result with be the following optimised call path ...

A ---PSTN---> B ---SIP---> D


On the other hand, if there was an IAX signal that requested the
server to bridge the two legs A->B and B->D directly, the same end
result could be achieved without any of the additional signalling
overhead.

C ----IAX-ATTENDED-XFR-REQ---> B
C ----IAX IE: call#1 id; call#2 id-----> B
C <-------------------ACK-------------------- B
C <------------------HANGUP-------------- B
C ---------------------ACK-------------------> B

Which would be much more straightforward and much simpler.


I am thinking of IAX as the prime candidate for WiFi IP phones as the
predominant protocol because of its NAT friendliness and robustness
and the problems that people will be having with their SIP based WiFi
phones in public hotspots. If we think of a not so distant future
where IAX is a common sight on WiFi phones, then we can easily imagine
the scenario where an IAX WiFI phone user waits in front of an
elevator until he has finished his phone call because he knows he will
lose the signal in the elevator.

In my experience it takes about 8-10 seconds for an "IAX Transfer"
(the route optimisation process) to complete. This means a WiFi phone
user may transfer a call and think it is safe to jump into the
elevator but his phone will need abother 8-10 seconds to be optimise
out of the call path. If the signal is lost before then, the two
parties who have just been connected to each other will get cut off
and the person who transferred the call does not even become aware of
this.

This is just one example I could think of, there will probably be more
examples of cases where the current method is not optimal and imposes
a handicap on usability or other factors.

Any comments will be appreciated, but in particular comments from
developers who know the IAX library and comments from phone
manufacturers thinking about supporting IAX in the future are most
sought after.

thanks
regds
benjk

-- 
Sunrise Telephone Systems, 9F Shibuya Daikyo Bldg., 1-13-5 Shibuya,
Tokyo, Japan.

NB: Spam filters in place. Messages unrelated to the * mailing lists
may get trashed.