[Asterisk-Dev] [LONG?] Impossible auto Dial with chan H323

[Kiel Hedjam]

Hi all,

I'll be straight.

Auto dialing (I mean an extension such as DIAL(H323/root at localhost))
doesn't work.

Why ? here is the metaphysical question ! 
I would never _dare_ to complain without having investigated first ;)

First some points of information on how that stuff works.

A H323Connection is spawned by his H323EndPoint "father" once received
an H225 Setup message.
As you all know, H225 is based on Q931 so that a H225 Setup PDU contains
a Q931 header field which specifies the Q931 CRV (Call Reference Value).

The CRV identifies a call, that means it is the same for both sides of
the call (caller and called party). 
The caller party, when initiating a call, produces a CRV and fill the
appropriate Setup message's field with.

When the called party receives the Setup message, the corresponding 
H323EndPoint object find out the CRV and construct an H323Connection 
object with it.
The CRV will "stick" to the H323Connection for obvious multiplexing
purposes (to route pdu to the corresponding connection object).

So what's happening when an H323Endpoint is calling himself ?

It creates a first connection (let's call it con1) with a suitable
CRV (for example 1242).
Then sends the Setup to himself.
On receive, it creates another connection (con2) with CRV=1242 
As a consequence, a CRV cannot identify "bijectively" a connection.

Remain 2 connections that we cannot distinguish using CRV.

But,(and I do know that you were all expecting that liberating conjunction)
when ast_h323 (the H323 side of the driver) tries to retreive RTP 
paramaters for the incoming connection, it uses the CRV only. 
So what happens when con1 tries ? It finds con0's rtp paramaters (merely
because con0 and con1 have the same CRV and find_call(unsigned callReference)
 function returns the already existing con0)

As a consequence, con1 starts to stream on himself since the last
spawned connection "wins the rtp port" and con0 never receives anything.

I already see hands raising in the room ahah,
"you're making us sick with that problem but you ain't suggest anything"

A solution could be to retreive informations considering the full call
token (which includes the transport) instead of the CRV only.

But this implies transforming deeply chan_h323.c,
what do you think ? Is there a better solution ? or may I stop talking 
now and buy a farm in Lesotho ?

Regards,

-- 
Kiel,
"sometimes hain is better than disdain"