Hi,

Since you are using G-711 u-Law, we can rule out the possibility of an unsupported codec.

Are you using IAX2 Trunking, you can see them as IAX2 Trunk Metaframes ?

Can you send me a small cap by private mail to info at unleashnetworks dt com ?

Thanks,

Are you using IAX2 Trunking, you can see them as IAX2 Trunk Metaframes ?

I am not sure.

Can you send me a small cap by private mail to info at unleashnetworks dt com ?

I will do this after confirming one thing, do you need to have paid support to play back IAX voip calls?
I am only using the free version.

Hi,

The Trial is fully functional. There is nothing in the paid version that is not in the trial.

My guess is :

1) IAX2 Trunk frames are not being interpreted correctly.

2) Something out of place in the signalling.

So send me the packets containing the call setup + a few payload packets.


Thanks,

email sent with attachment to This e-mail address is being protected from spambots. You need JavaScript enabled to view it

Hi Jeremy,

ACK the email. Thanks.

I looked at the trace and found that only one direction of IAX2 traffic is captured.

Unsniff looks for the remote side to issue an IAX2 ACCEPT message in response to NEW before setting up the user object. The idea here is that the remote side has an option of choosing a codec, although I rarely see the remote side disagreeing with the choice of the initiator.

Is it feasible for you to capture both directions? If not, I could add an option to allow a single leg capture (which may not always work due to the missing info about the codec from the ACCEPT message).

Thanks,

Pardon my ignorance >>>only one direction of IAX2 traffic is captured. Is this because I am using a passive tap to perform my capture?

Let me describe me setup a little more. I am using Google voice in combination with Asterisk to make VoIP calls. My IAX2 phone number provider is for inbound only.

I hope this helps make a little more sense of things.