* You are viewing Posts Tagged ‘process’

FSK ETSI or FSK US

Dear

In essence Caller ID ETSI and FSK US (Bellcore) is based on the same pattern as;
_____________ ___________________ _________ ________________ _____________
|First Ring burst |_500ms_|Channel seizure 300 bits|__|Mark Signal|__| Caller ID Message|_200 ms_|Second ring burst |

So basically any kind of device should be work without any problem, unfortunately during these process if some noises (as miss ground connection or others) happens during the process can make failed to process caller-id information, by the modem.

Mc GRATH Ricardo
E-Mail mcgrathr@mail2web.com

sip show peers

I have a process that runs on a server and does a simple ‘asterisk -rx
“sup show peers’ > /tmp/peers”
and then looks for any “(Unspecified)” items and reports them as having
lost connection.
My server is running 1.4.43 and the two boxes I am monitoring are also
running 1.4.43.
Once in a great while 1 of my boxes reports “(Unspecified)”. I am trying
to find out why.

How can I make the remote boxes have a shorter heart beat to checking
more frequently
with the server so as not to go “(Unspecified)”. By the time I log in
and check its already
back connected again.

Any other thoughts?

Thanks,

Jerry

Slow AMI Originate

Hello,

We use AMI to originate calls. Sometimes, lately every morning, the AMI Originate process operates extremely slowly. I cannot see the calls in “core show channels verbose”, I don’t know where they are, what state they are in, after 2-3 minutes the calls go through one after the other. As mentioned, it usually happens in the morning as soon as people start their workday, where there are a lot of logins and calls being made, but no where close to a peak in terms of simultaneous channels, etc. In some cases restarting asterisk, in others just taking the storm and waiting it out solves the problem. Having a hard time coming up with something to troubleshoot this. Any ideas would be appreciated.

No compatible codecs, not accepting this offer! – after upgrading to 1.8.11

Hi,

I’ve upgraded my asterisk 1.4 to the version 1.8.11. After making some
adjustments to the configuration files to port it to the new version, calls
between registered phones in asterisk, work fine, but inbound calls coming
from the SIP trunk I have with a telco to asterisk, don’t work anymore. I
don’t know why!…

This is the SDP portion that comes in the INVITE messages of calls through
that trunk (let’s say, whose endpoint has the IP x.x.x.x, purposely
omitted). Nothing seems to be wrong with that to me:
v=0
o=CSM 0 1 IN IP4 x.x.x.x
s=Acme
c=IN IP4 x.x.x.x
t=0 0
m=audio 22152 RTP/AVP 8 0 18 4 101
a=rtpmap:101 telephone-event/8000

And here’s the debugging:
[May 8 17:45:30] DEBUG[6444]: chan_sip.c:5092 do_setnat: Setting NAT on RTP
to Off
[May 8 17:45:30] DEBUG[6444]: chan_sip.c:8891 process_sdp: Processing
session-level SDP v=0… UNSUPPORTED.
[May 8 17:45:30] DEBUG[6444]: chan_sip.c:8891 process_sdp: Processing
session-level SDP o=CSM 0 1 IN IP4 x.x.x.x… UNSUPPORTED.
[May 8 17:45:30] DEBUG[6444]: chan_sip.c:8891 process_sdp: Processing
session-level SDP s=Acme… UNSUPPORTED.
[May 8 17:45:30] DEBUG[6444]: netsock2.c:134 ast_sockaddr_split_hostport:
Splitting ‘x.x.x.x’ into…
[May 8 17:45:30] DEBUG[6444]: netsock2.c:188 ast_sockaddr_split_hostport:
…host ‘x.x.x.x’ and port ”.
[May 8 17:45:30] DEBUG[6444]: chan_sip.c:8891 process_sdp: Processing
session-level SDP c=IN IP4 x.x.x.x… OK.
[May 8 17:45:30] DEBUG[6444]: chan_sip.c:8891 process_sdp: Processing
session-level SDP t=0 0… UNSUPPORTED.
[May 8 17:45:30] DEBUG[6444]: rtp_engine.c:537
ast_rtp_codecs_payloads_set_m_type: Setting payload 8 based on m type on
0x416e25b0
[May 8 17:45:30] DEBUG[6444]: rtp_engine.c:537
ast_rtp_codecs_payloads_set_m_type: Setting payload 0 based on m type on
0x416e25b0
[May 8 17:45:30] DEBUG[6444]: rtp_engine.c:537
ast_rtp_codecs_payloads_set_m_type: Setting payload 18 based on m type on
0x416e25b0
[May 8 17:45:30] DEBUG[6444]: rtp_engine.c:537
ast_rtp_codecs_payloads_set_m_type: Setting payload 4 based on m type on
0x416e25b0
[May 8 17:45:30] DEBUG[6444]: rtp_engine.c:537
ast_rtp_codecs_payloads_set_m_type: Setting payload 101 based on m type on
0x416e25b0
[May 8 17:45:30] DEBUG[6444]: chan_sip.c:9110 process_sdp: Processing
media-level (audio) SDP a=rtpmap:101 telephone-event/8000… OK.
[May 8 17:45:30] DEBUG[6444]: rtp_engine.c:640
ast_rtp_codecs_payload_formats: Incorporating payload 0 on 0x416e25b0
[May 8 17:45:30] DEBUG[6444]: rtp_engine.c:640
ast_rtp_codecs_payload_formats: Incorporating payload 4 on 0x416e25b0
[May 8 17:45:30] DEBUG[6444]: rtp_engine.c:640
ast_rtp_codecs_payload_formats: Incorporating payload 8 on 0x416e25b0
[May 8 17:45:30] DEBUG[6444]: rtp_engine.c:640
ast_rtp_codecs_payload_formats: Incorporating payload 18 on 0x416e25b0
[May 8 17:45:30] DEBUG[6444]: rtp_engine.c:640
ast_rtp_codecs_payload_formats: Incorporating payload 101 on 0x416e25b0
[May 8 17:45:30] NOTICE[6444]: chan_sip.c:9188 process_sdp: No compatible
codecs, not accepting this offer!

Any help?

Thanks,
Ricardo.

Asterisk Directmedia

What is directmedia?

To put it simply, is the process where Asterisk tries to redirect the RTP media stream to go directly from the caller to the callee. Be careful that some devices do not support this (especially if one of them is behind a NAT). The default setting is YES, for example in the SIP protocol configuration file sip.conf.

When should I use directmedia in Asterisk?

If you have all clients behind a NAT, or for some other reason want Asterisk to stay in the audio path, you may want to turn this off.

If you want to allow media path redirection (reinvite) only when the peer where the media is being  sent is known to not be behind a NAT (as the RTP core can determine it based on the apparent IP address the media arrives from), set this to nonat.

asterisk 1.4.39 and dahdi 2.6 on Ubuntu

On 04/19/2012 05:59 PM, bilal ghayyad wrote:
> Dears;
>
> I see this at the /var/log/asterisk/messages:
>
> [Apr 20 01:49:48] ERROR[1657] codec_dahdi.c: Failed to open /dev/dahdi/transcode: No such file or directory

If you aren’t using a DAHDI transcoding card, then you don’t need to
load the codec_dahdi module in Asterisk. Since it was built, though, you
clearly have DAHDI built and installed properly, and the Asterisk build
process was aware of that.

>
> Again, I am installing asterisk and dahdi at Ubuntu (uname -a
> Linux House 3.0.0-17-server #30-Ubuntu SMP Thu Mar 8 22:15:30 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux).
>
> I do not know if you were talking about the messages logs or about someting else?
>
> Anyway, these are the logs that I see at the messages after running /etc/init.d/asterisk restart:
>
>
> [Apr 20 01:49:48] NOTICE[1657] cdr.c: CDR simple logging enabled.
> [Apr 20 01:49:48] NOTICE[1657] loader.c: 142 modules will be loaded.
> [Apr 20 01:49:48] WARNING[1657] res_smdi.c: No SMDI interfaces are available to listen on, not starting SMDI listener.
> [Apr 20 01:49:48] NOTICE[1657] pbx_ael.c: Starting AEL load process.
> [Apr 20 01:49:48] NOTICE[1657] pbx_ael.c: AEL load process: calculated config file name ‘/etc/asterisk/extensions.ael’.
> [Apr 20 01:49:48] NOTICE[1657] pbx_ael.c: AEL load process: parsed config file name ‘/etc/asterisk/extensions.ael’.
> [Apr 20 01:49:48] NOTICE[1657] pbx_ael.c: AEL load process: checked config file name ‘/etc/asterisk/extensions.ael’.
> [Apr 20 01:49:48] NOTICE[1657] pbx_ael.c: AEL load process: compiled config file name ‘/etc/asterisk/extensions.ael’.
> [Apr 20 01:49:48] NOTICE[1657] pbx_ael.c: AEL load process: merged config file name ‘/etc/asterisk/extensions.ael’.
> [Apr 20 01:49:48] NOTICE[1657] pbx_ael.c: AEL load process: verified config file name ‘/etc/asterisk/extensions.ael’.
> [Apr 20 01:49:48] ERROR[1657] codec_dahdi.c: Failed to open /dev/dahdi/transcode: No such file or directory

All of that is perfectly normal. If you want that ERROR message to go
away, add ‘noload => codec_dahdi’ to your /etc/asterisk/modules.conf file.