[asterisk-dev] IAX hardphone

Kevin P. Fleming kpfleming at digium.com
Mon Feb 14 10:33:24 CST 2011


On 02/14/2011 09:56 AM, Bill Shaw wrote:
>
>
> On 2/12/2011 9:25 AM, Kevin P. Fleming wrote:
>> On 02/11/2011 03:35 PM, Bill Shaw wrote:
>>> I'm seeing some information elements in my data that are not defined in
>>> the RFC and Wireshark doesn't know - 0x37 & 0x38. Is there an updated
>>> list of ies available somewhere?
>>>
>>> Also, I'm wondering if my 'accept' issue is because I'm not
>>> authenticating first. I should be able to just 'accept' the 'new'
>>> without authenticating, shouldn't I?
>>
>> If you are the receiver of the NEW request, you are not going to
>> 'authenticate' at all, although you could choose to require the sender
>> of the NEW to authenticate *to* you. Whether you do or not should not
>> affect the remainder of the call.
>>
>> Are you not seeing *any* logging on the Asterisk console (with maximum
>> verbosity and debug levels, and 'iax2 debug on') when your ACCEPT is
>> sent to it?
>>
>
> Entering 'iax2 debug on' at the command line gets a "no such command'
> response.

Well, that was a shot in the dark because you haven't really given us 
much basic information... like the version of Asterisk you are using, 
for example.

Let's start with that... tell us what version you are using, and we'll 
be able to tell you how to maximize the amount of debugging information 
emitted to your console, so you can get some clue as to what is happening.

As far as the comment about the source being protocol documentation: 
that is *not* your issue. I was referring to the addition of new 
information elements in my response, which should be documented before 
they are added to a release of Asterisk (in my opinion, at least). 
However, even if they are not, addition of new information elements 
would never make Asterisk non-backwards-compatible with any existing 
IAX2 implementation (except in rare cases, which are always fully 
documented), and any proper implementation should be able to cope with 
receiving (and ignoring) information elements it does not understand.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org



More information about the asterisk-dev mailing list