[asterisk-dev] How should IAX2 DPREQ work?

[Andy Hopper]

OK--got things working. Thanks so much for the tip!

What I found out is that you must call the extension "TBD" in order for 
asterisk to "accept" the call (i.e., user:secret at peer/TBD)

I found this by looking at the source...seems like this should be 
specified in a document somewhere (if it is--I missed it).

Thanks,
Andy

Tim Panton wrote:
>
> 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/
>
>
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev