[asterisk-dev] How should IAX2 DPREQ work?

Tim Panton tim at mexuar.com
Mon Feb 26 11:38:30 MST 2007


On 23 Feb 2007, at 05:48, Andy Hopper wrote:

> 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 ?
> 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.
>

I've just had a look at the draft RFC It seems to say that DPREQ  
should be within a call
started with a NEW, not an AUTH'd session. Which were you using?



Tim.

Tim Panton

www.mexuar.net
www.westhawk.co.uk/





More information about the asterisk-dev mailing list