Summary:ASTERISK-07446: no RTP audio during a call
Reporter:Kaloyan Kovachev (knk)Labels:
Date Opened:2006-08-02 12:09:19Date Closed:2011-06-07 14:02:46
Versions:Frequency of
Environment:Attachments:( 0) sip_debug.txt
( 1) test_patch.diff
Description:On a new call between two SIP devices there is no audio. If the call is put on hold and if moh starts (see bug 7643) the music is heard and when going back to the call later the audio is OK.


zaptel is trunk r1255, no zaptel hardware - ztdummy is used
tried to set internal_timing=no in asterisk.conf, but still the same
Comments:By: Joshua C. Colp (jcolp) 2006-08-02 12:10:26

Do you have reinvites enabled? are they behind NAT?

By: Serge Vecher (serge-v) 2006-08-02 12:15:22

additionally, please produce sip debugs, which you very well know are required when posting bugs under SIP project.

By: Kaloyan Kovachev (knk) 2006-08-02 12:15:47

reinvites are disabled in sip.conf and also Dial with options 'TWHKtwhk' should cause the call to be bridged from asterisk.
the devices are not behind NAT
silence suppresion is disabled for both of them

By: Joshua C. Colp (jcolp) 2006-08-02 12:16:25

sip debug plus rtp debug is needed and console output

By: Kaloyan Kovachev (knk) 2006-08-02 12:34:12

here it comes, sorry.
i was thinking to try injecting a voice frame before bridging, but will not be able to test by the end of the week.
the call is between the two ports of SPA2100, but bridged from asterisk

By: Serge Vecher (serge-v) 2006-08-02 13:37:17

hmmm, what's K or k option in Dial()? Also, not to sure about two pipes

By: Kaloyan Kovachev (knk) 2006-08-02 14:56:51

K/k option is something i've found in app Dial description - to allow call parking (for calling/called user).  The option does not exist in 1.2 and is new for trunk.

The missing parameter between the two pipes (if i understand you properly) is the timeout for the Dial, which is optional parameter and i am using it since 1.2'.0' without problems.

By: Serge Vecher (serge-v) 2006-08-02 14:59:43

hmm, looking at the logs -- what happened to RTP audio ... Is there another recent revision of trunk that has worked for you or did you upgrade directly from 1.2.x?

By: Kaloyan Kovachev (knk) 2006-08-02 15:28:57

I saw, that there is almost no difference with and without ?rtp debug? (if that?s what you mean), while in fact there are packets sent to Asterisk from SPA (according to the SPA?s LED) and this was the reason to think that Asterisk is not processing the packets because of timing problems.
First i was testing the new patch (for bug 6335) with Dial to a Local channel connecting to MOH, so i don?t know if there is any revision working on the (brand) new machine (x86_64), which i am preparing as the next production server running 1.4 instead of 1.2 (on 32bit AMD Athlon), so even 1.2 has never been started on this machine and ?MOH via Local? has always working fine.

By: Kaloyan Kovachev (knk) 2006-08-08 10:26:56

as promised i have tested injecting something in the call just before the 'for ever' loop (line 3620 channel.c):
on any channel didn't help, neither did
      ast_moh_start(c0, NULL, NULL);
even the moh is not heard in this case, but
      ast_stream_and_wait(c0, "silence/1", c0->language, "");
did the job and there is audio.

By: Kaloyan Kovachev (knk) 2006-08-14 03:52:53

To get the audio, at least 80 samples are need to be sent to any of the channels.

In the attached diff i have used the code from silence generator, but instead of slin the samples are marked in the same format as the channel. It is not silence with all formats, but it is not audible.

It is strange, but ast_prod does not work in this case even with more than 80 samples and disabling the STATE_UP checking.

By: Kaloyan Kovachev (knk) 2006-08-25 09:57:39

please close this bug, as it have shown to be a firewall problem between the SPA and the Asterisk server. sorry for the noise

By: Joshua C. Colp (jcolp) 2006-08-25 10:10:54

Issue was not Asterisk but a firewall in place.