[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