[asterisk-dev] IAX hardphone

[Bill Shaw]

On 2/14/2011 11:33 AM, Kevin P. Fleming wrote:
> 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.
>

Sorry for the lack of information, Kevin.  let me back up to my original 
post and bring that info forward....

OK.  First,  my setup...

192.168.1.56 - my development system - Win xp - Wireshark, Zoiper, TI's 
Code Composer Studio
192.168.1.4 - My PBX - CentOS 5.5, Asterisk 1.6
192.168.1.31 - my hardphone - TI DSP running my code on the bare metal

Zoiper calls extension 21 which is mapped in the dial plan through to my 
hardphone.  Linux arps for my mac,  I reply with it.  * sends me a 
'new',  I reply with an 'accept'.  There is no response to the 
'accept'.  It just gets ignored and eventually * sends me another 
'new'.  There's got to be something wrong with my 'accept' but I just 
can't see it.  Wireshark shows it as I expect.  No error messages,  
nothing in the messages log,  it just gets dropped.

Captureof the 'accept' from Wireshark:
http://b.shaw.home.comcast.net/accept.ecap


Thanks again,

Bill