[asterisk-dev] How should IAX2 DPREQ work?

[Andy Hopper]

I've spent a lot of time over the last few days messing w/ the IAX2 
dialplan request (DPREQ) interaction. Basically, I have demonstrated 
that the guts (i.e., chan_iax2.c::dp_lookup()) work, but I'm currently 
unsure of how this facility was _intended_ to be used (I'm not speaking 
conceptually, but programmatically ). Anyhow I decided to come up for 
air and pose the question: using libiax2 and asterisk, how should the 
DPREQ work ?

I'm using Asterisk 1.4.0 and libiax2-svn-35.

Here's my observations with the current toolchain:

1) From the perspective of libiax2, you must make a dialplan request 
against a registered libiax2 session. If the session's not registered, 
then the library has no idea who to send the request to.
2) Asterisk doesn't seem to expect a DPREQ message to follow the 
registration. In fact, looking at the session seems to be freed after 
the ACK is received from the client. When the DPREQ arrives, the dcallno 
is cross-referenced against the sessions in iaxs[]--the session isn't 
there. Because the DPREQ isn't listed as a message type that can spawn a 
new session, an INVAL is returned to the client.
3) From the perspective of asterisk, the dialplan request must be 
associated with a previously active session. The reason is--asterisk 
needs to know what context the dialplan request should be made against.
4) In lieu of #2, if you hack chan_iax2.c to force DPREQ request to 
spawn new session, and then force the context, the dp_lookup() works 
like a champ. I was able to validate that you could do digit-by-digit 
validation--so the bones are obviously good.

Now, it's obviously possible that I'm way off-base here, and that I've 
made a bad assumption at the beginning that has led me down the wrong 
path. If so--stop reading here and tell me how I've goofed. I've goofed 
before--and I'm sure I will again ;)

However, if you all agree that I'm correct in saying that the DPREQ 
interaction has been broken at some point, I'd like to offer up a couple 
possible solutions. I'd be glad to help implement whatever we decide is 
appropriate:

1) If we assume that DPREQ messages can only occur on a registered 
session (with an associated context), then one way to fix the current 
interaction is to keep asterisk iaxs[] sessions so that we can process 
DPREQ messages against them.  As far as I can tell, we need the context, 
and the sequence number counters in order to continue to answer these 
requests appropriately.

2) If we decide that DPREQ messages can happen at any time, and can 
initiate new sessions, then we need more information to be packed in the 
requests. Essentially, we need to pass the same sort of extended 
dialstring that we pass in iax_call() (which may include the context, 
etc.). This would be packaged up as extended information elements in the 
DPREQ, and asterisk could parse the message as an atomic unit.

Personally, I like #2 the best, but I recognize that this would change 
the IAX2 protocol.

What do you all think?

Thanks a lot,
Andy