* You are viewing Posts Tagged ‘chan’

mfcr2 channel state IDLE 0×00 and call trace log file not ended ??

Hi, would be glad to be contributing with this question to all the comunity.

I´m having a weird issue, suddenly I get Channels on IDLE
0×00 state until I do a dahdi restart.

Trying to do a call trace to see whats going on deeper, I get surprised when tried to open the .call file to see the log this is incomplete.

This is what I see


[root@localhost telefonica]# nano chan-9-backward-804-20130507123100.call
…..

[12:31:01:846] [Thread:
3067460464] [Chan 9] – Getting ANI digit 3
[12:31:01:846] [Thread:
3067460464] [Chan 9] – ANI so far: 1152723, expected length:
10
[12:31:01:846] [Thread: 3067460464] [Chan 9] – MF Tx >> 5
[ON]
[12:31:01:846] [Thread: 3067460464] [Chan 9] – scheduled timer id
13 (mf_back_cycle)
[12:31:01:906]

(I deleted the first part just for being more readable, but I didnt deleted the end its just has its end was somehow incomplete.

this is what I get from other call in the same situation.

[12:30:57:242] [Thread: 3067214704] [Chan 12] – MF Rx << 6
[OFF]
[12:30:57:242] [Thread: 3067214704] [Chan 12] - MF Tx >> 5
[OFF]
[12:30:57:302] [Thread: 3067214704] [Chan 12] – MF Rx << 7
[ON]
[12:30:57:302] [Thread: 3067214704] [Chan 12] - Attempting to cancel timer time$
[12:30:57:302] [Thread: 3067214704] [Chan 12] - timer id 12 found, cancelling i$
[12:30:57:302] [Thread: 3067214704] [Chan 12]
- Getting ANI digit 7
[12:30:57:302] [Thread: 3067214704] [Chan 12] -
ANI so far: 1148567, expected l$
[12:30:57:302] [Thread: 3067214704]
[Chan 12] - MF T

just like “cutted”

but then I found some complete logs of those same “RX: 0×00 state” calls…

cat chan-30-backward-428-20130514144454.call

……

[14:44:56:300]
[Thread: 3067771760] [Chan 30] – Getting ANI digit 1
[14:44:56:300]
[Thread: 3067771760] [Chan 30] – ANI so far: 1145043471, expected length: 10
[14:44:56:300] [Thread: 3067771760] [Chan 30] – Done getting ANI!
[14:44:56:300] [Thread: 3067771760] [Chan 30] – Requesting change to Group II with signal 0×33
[14:44:56:300] [Thread: 3067771760] [Chan
30] – MF Tx >> 3 [ON]
[14:44:56:300] [Thread: 3067771760] [Chan 30] -
scheduled timer id 16 (mf_back_cycle)
[14:44:56:360] [Thread:
3067771760] [Chan 30] – MF Rx << 1 [OFF]
[14:44:56:360] [Thread:
3067771760] [Chan 30] - MF Tx >> 3 [OFF]
[14:44:56:420] [Thread:
3067771760] [Chan 30] – MF Rx << 1 [ON]
[14:44:56:420] [Thread:
3067771760] [Chan 30] - Attempting to cancel timer timer
16
[14:44:56:420] [Thread: 3067771760] [Chan 30] - timer id 16 found, cancelling it now
[14:44:56:420] [Thread: 3067771760] [Chan 30] - MF Tx
[14:44:56:420] [Thread: 3067771760] [Chan 30] - scheduled timer id 17 (mf_back_cycle)
[14:44:56:480] [Thread: 3067771760] [Chan
30] - MF Rx << 1 [OFF]
[14:44:56:480] [Thread: 3067771760] [Chan 30] -
MF Tx >> 6 [OFF]
[14:44:56:480] [Thread: 3067771760] [Chan 30] -
Attempting to cancel timer timer 17
[14:44:56:480] [Thread: 3067771760]
[Chan 30] – timer id 17 found, cancelling it now
[14:44:56:480] [Thread:
3067771760] [Chan 30] – scheduled timer id 18
(r2_answer_delay)
[14:44:56:640] [Thread: 3067771760] [Chan 30] -
Attempting to cancel timer timer 18
[14:44:56:640] [Thread: 3067771760]
[Chan 30] – timer id 18 found, cancelling it now
[14:44:56:640] [Thread:
3067771760] [Chan 30] – calling timer 18 (r2_answer_delay)
callback
[14:45:12:244] [Thread: 3052403568] [Chan 30] – CAS Tx >>
[ANSWER] 0×04
[14:45:12:244] [Thread: 3052403568] [Chan 30] – CAS Raw Tx
[14:50:53:853] [Thread: 3052403568] [Chan 30] – Attempting to cancel timer timer 0
[14:50:53:853] [Thread: 3052403568] [Chan 30] -
Cannot cancel timer 0
[14:50:53:853] [Thread: 3052403568] [Chan 30] -
CAS Tx >> [CLEAR BACK] 0x0C
[14:50:53:853] [Thread: 3052403568] [Chan
30] – CAS Raw Tx >> 0x0D

and the same for this other channel..

….


[14:50:22:417] [Thread: 3067771760] [Chan 31] – Attempting to cancel timer timer 18
[14:50:22:417] [Thread: 3067771760] [Chan 31] – timer id
18 found, cancelling it now
[14:50:22:417] [Thread: 3067771760] [Chan
31] – calling timer 18 (r2_answer_delay) callback
[14:50:22:418]
[Thread: 3055217520] [Chan 31] – CAS Tx >> [ANSWER] 0×04
[14:50:22:418]
[Thread: 3055217520] [Chan 31] – CAS Raw Tx >> 0×05
[14:50:54:194]
[Thread: 3055217520] [Chan 31] – Attempting to cancel timer timer
0
[14:50:54:194] [Thread: 3055217520] [Chan 31] – Cannot cancel timer
0
[14:50:54:194] [Thread: 3055217520] [Chan 31] – CAS Tx >> [CLEAR BACK]
0x0C
[14:50:54:194] [Thread: 3055217520] [Chan 31] – CAS Raw Tx >> 0x0D


Is this call ended normally? Could it be an irq or hardware issue? Its happens only in the first port, which is connected to the teco, but the
2nd port which is connected to a samsung pbx didn´t get problems. Would be glad if anybody put some light on it.

By the way this is my configuration:

Asterisk 10.5.0 (but also tried in 1.8 and 1.6 with the same results)

HP ML110 G7 server

lspci -v

..

0e:08.0
Communication controller: Digium, Inc. Wildcard TE210P/TE212P dual-span T1/E1/J1 card 3.3V (rev 02)
Subsystem: Device 0003:0000
Flags: bus master, medium devsel, latency 64, IRQ 11
Memory at fbff0000 (32-bit, non-prefetchable) [size8]
Kernel driver in use: wct4xxp Kernel modules: wct4xxp

..

cat
/etc/dahdi/system.conf

span=1,1,0,cas,hdb3
cas=1-15,17-31:1101


span=2,0,0,cas,hdb3
cas2-46,48-62:1101
echocanceller=mg2,32-46,48-62


loadzone = ve defaultzone = ve

nano /etc/asterisk/chan_dahdi.conf


resetinterval=never context=from-pstn group=0
;mfcr2_forced_release=yes mfcr2_logdir=telefonica mfcr2_logging=all mfcr2_call_files=yes echocancel=yes language=es signalling=mfcr2
mfcr2_variant=itu mfcr2_get_ani_first=no mfcr2_max_ani

mfcr2_max_dnis=4
mfcr2_category=national_subscriber
;mfcr2_mfback_timeout=-1
mfcr2_metering_pulse_timeoutP0
mfcr2_mfback_timeout

PRI trunk between Asterisk servers does not work.

In article <4FECCD0C.1020000@fivecats.org>,
James Sharp wrote:
> On 6/28/2012 3:53 PM, Ernie Dunbar wrote:
> > We have three Asterisk servers, Voip1, Voip2, and Voip3. Voip1 has a
> > Wildcard TE405P (3rd Gen), Voip2 has a Wildcard TE410P/TE405P (1st Gen),
> > and Voip3 has a Wildcard TE110P. Voip1 is the server that handles our
> > PRI to the PSTN and we hope will allow us to failover to other Asterisk
> > servers (ie, Voip2 and Voip3). Voip2 is our current production server,
> > and Voip3 is being turned into our next production server.
> >
> > We’re trying to build a PRI trunk between Voip1 and Voip3. Curiously
> > enough, we’ve already done this between Voip1 and Voip2, so one would
> > think that the same configuration would work between Voip1 and Voip3 as
> > well. However, it hasn’t gone so smoothly. If you’re wondering why we
> > don’t just use SIP trunking between these servers, it’s because faxes
> > are not reliable over SIP trunks. I am open to suggestions however.
> >
> > At any rate, the PRI trunk between Voip1 and Voip3 isn’t working, and
> > that’s my current problem.
> >
> > – I have built a T1 crossover cable, and it’s plugged in between Span 3
> > on Voip1, and Span 1 on Voip3.
> > – I have a green light on both PRI cards for the appropriate spans.
> > – Both servers detect their cards on boot.
> > – DAHDI is installed on both servers, and all diagnostics are good, ie.
> > dahdi_test returns good results, dahdi_tool shows that the alarms are
> > OK, and executing ‘dahdi show status’ on the Asterisk console shows the
> > same.
> >
> > The chan_dahdi.conf configuration for spans 3 and 4 on Voip1 looks like
> > this:
> >
> > ; Span 3: TE4/0/4 “T4XXP (PCI) Card 0 Span 4″
> > group=3
> > context=default
> > switchtype = national
> > signalling = pri_net
> > channel => 49-71
> > group = 63
> >
> > ; Span 4: TE4/0/4 “T4XXP (PCI) Card 0 Span 4″
> > group=4
> > context=default
> > switchtype = national
> > signalling = pri_net
> > channel => 73-95
> > context = default
> > group = 63
> >
> > Span 4 goes to Voip2, which has a working PRI trunk.
> >
> > The chan_dahdi configuration for Voip3 looks like this:
> >
> > group=1
> > signalling=pri_cpe
> > switchtype=national
> > context=local
> > channel=>1-23
> > dchannel=>24
> > ;channel=25-47,49-71,73-95
> > rxgain=0
> > txgain=0
> > busydetect=yes
> > busycount=5
> >
> > resetinterval=1800
> >
> > I have a test DID, the dialplan for which on Voip1 looks like this:
> >
> > exten => 604484XXXX,1,Dial(DAHDI/g3/604482YYYY)
> >
> > But when I call 604484XXXX from my cell phone, I get no output on the
> > Asterisk console on Voip3, and this output on Voip1:
> >
> >
> > — Executing [604484XXXX@local:1] Dial(“DAHDI/5-1″,
> > “DAHDI/g3/604482XXXX”) in new stack
> > [Jun 28 12:43:32] WARNING[4219]: app_dial.c:1286 dial_exec_full: Unable
> > to create channel of type ‘DAHDI’ (cause 34 – Circuit/channel congestion)
> > == Everyone is busy/congested at this time (1:0/1/0)
> > == Auto fallthrough, channel ‘DAHDI/5-1′ status is ‘CONGESTION’
> > — Accepting call from ’778839ZZZZ’ to ’604484XXXX’ on channel 0/5,
> > span 1
> >
> > I’ve also tried connecting span 3 to one of the other ports on Voip2
> > with the same configuration, and I get the same results. I’ve run
> > loopback tests on the TE110P and tested the cable thoroughly.
> >
> > Any input on this problem is greatly appreciated.
>
>
> You’ve got the spans configured as “group = 63″ but you’re trying to
> dial out on group 3 (DAHDI/g3 rather than DAHDI/g63).

No, the group=63 lines are actually redundant. It is the settings *above*
each channel=> line that get applied to the channels when they are created.

To the OP: what does “pri show span 3″ give you on Voip1?

It might be useful to see the complete chan_dahdi.conf from Voip1.
To save space, you can list it without comments like this:

# grep -v ‘^;’ /etc/asterisk/chan_dahdi.conf

Cheers
Tony

Asterisk with LCR -> chan_lcr needed?

Hello,

I short question:

I want to connect Asterisk to OpenBSC with mISDN, mISDNuser and LCR.

Do I need chan_lcr?

I have:
Asterisk 1.8
mISDN .v2 integrated in Kernel 3.0.22
mISDNuser
lcr 1.7
HFC-E1 Evaluation board from cologne chip

I tried to configure Asterisk with <./configure –prefix=/usr/src/lcr

Error SIP/2.0 488 Not acceptable here

Hello,

a person trying to call me by my phone number is getting the error 488 Not
acceptable here. I googled that error, seems like this error is normally
caused by a failed codec negotation, though I have no clue how I could have
read this out of the logs. Anyway, my setup is as follows:
Asterisk 1.8.13.0 – NAT – Sipgate SIP Provider
The user calling me is also using Sipgate and is calling my landline phone
number from Sipgate (not [my sip id]@sipgate.de).

My sip.conf including the codec restrictions looks like this (I left out my
local sip account)

[general]
> port=5060
> bindaddr=0.0.0.0
> context=other
> language=de
> allowguest=no
>
> qualify=no
> disallow=all
> allow=alaw
> allow=ulaw
> allow=g729
> allow=gsm
> allow=slinear
> srvlookup=yes
>
> register => : @sipgate.de/
>
>
>
> [sipgate]
> type=friend
> insecure=invite
> nat=yes
> username=

> fromuser=

> fromdomain=sipgate.de
> secret= > host=sipgate.de
> qualify=yes
> canreinvite=no
> dtmfmode=rfc2833
> context = from_external_voip_provider
>

The relevant part from my full asterisk log /var/log/asterisk/full
including the 488 Not acceptable here error message:

[Jun 18 20:15:26] VERBOSE[1164] chan_sip.c:
> < --- SIP read from UDP:217.10.79.9:5060 --->
> INVITE sip:@192.168.5.11:5060 SIP/2.0
> Record-Route:
> Record-Route:
> Record-Route:
> Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK8f5c.48627b3.0
> Via: SIP/2.0/UDP 172.20.40.3;branch=z9hG4bK8f5c.48627b3.0
> Via: SIP/2.0/UDP 217.10.79.9:5060
> ;received=217.10.68.222;branch=z9hG4bK-un6p0cm50qse
> Via: SIP/2.0/UDP 192.168.0.8:2048
> ;received=;branch=z9hG4bK-un6p0cm50qse;rport=2048
> From: “sipgate.de” @sipgate.de>;tag=8cgn1bajqb
> To: @sipgate.de;user=phone>
> Call-ID: 4fdf703d880d-ywqwnfbbj1h7
> CSeq: 2 INVITE
> Max-Forwards: 67
> Contact:
> @:2048;line=swnt2d3t>;reg-id=1
> X-Serialnumber: 000413251D76
> User-Agent: snom300/8.7.3.7
> Accept: application/sdp
> Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK,
> MESSAGE, INFO, UPDATE
> Allow-Events: talk, hold, refer, call-info
> Supported: timer, 100rel, replaces, from-change
> Session-Expires: 3600;refresher=uas
> Min-SE: 90
> Content-Type: application/sdp
> Content-Length: 522
> P-Asserted-Identity: @sipgate.de>
>
> v=0
> o=root 269390684 269390684 IN IP4 192.168.0.8
> s=call
> c=IN IP4 217.10.77.20
> t=0 0
> m=audio 62652 RTP/AVP 9 0 8 3 99 108 18 101
> a=crypto:1 AES_CM_128_HMAC_SHA1_32
> inline:Ed8iHaP3BXNVeXHj98PRa6sJyImNer3ImjUvDZps
> a=rtpmap:9 G722/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:3 GSM/8000
> a=rtpmap:99 G726-32/8000
> a=rtpmap:108 AAL2-G726-32/8000
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=no
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> a=ptime:20
> a=sendrecv
> a=direction:active
> a=nortpproxy:yes
> < ------------->
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: — (25 headers 21 lines) —
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Sending to 217.10.79.9:5060(NAT)
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Using INVITE request as basis
> request – 4fdf703d880d-ywqwnfbbj1h7
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Found peer ‘sipgate’ for
> ‘‘ from 217.10.79.9:5060
> [Jun 18 20:15:26] VERBOSE[1164] netsock2.c: == Using SIP RTP CoS mark 5
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Found RTP audio format 9
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Found RTP audio format 0
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Found RTP audio format 8
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Found RTP audio format 3
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Found RTP audio format 99
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Found RTP audio format 108
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Found RTP audio format 18
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Found RTP audio format 101
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Found audio description format
> G722 for ID 9
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Found audio description format
> PCMU for ID 0
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Found audio description format
> PCMA for ID 8
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Found audio description format
> GSM for ID 3
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Found audio description format
> G726-32 for ID 99
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Found audio description format
> AAL2-G726-32 for ID 108
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Found audio description format
> G729 for ID 18
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c: Found audio description format
> telephone-event for ID 101
> [Jun 18 20:15:26] WARNING[1164] chan_sip.c: We are requesting SRTP, but
> they responded without it!
> [Jun 18 20:15:26] VERBOSE[1164] chan_sip.c:
> < --- Reliably Transmitting (NAT) to 217.10.79.9:5060 --->
> SIP/2.0 488 Not acceptable here
> Via: SIP/2.0/UDP 217.10.79.9:5060
> ;branch=z9hG4bK8f5c.48627b3.0;received=217.10.79.9;rport=5060
> Via: SIP/2.0/UDP 172.20.40.3;branch=z9hG4bK8f5c.48627b3.0
> Via: SIP/2.0/UDP 217.10.79.9:5060
> ;received=217.10.68.222;branch=z9hG4bK-un6p0cm50qse
> Via: SIP/2.0/UDP 192.168.0.8:2048
> ;received=;branch=z9hG4bK-un6p0cm50qse;rport=2048
> From: “sipgate.de” @sipgate.de>;tag=8cgn1bajqb
> To: @sipgate.de;user=phone>;tag=as6364b798
> Call-ID: 4fdf703d880d-ywqwnfbbj1h7
> CSeq: 2 INVITE
> Server: Asterisk PBX 1.8.13.0~dfsg-1
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH
> Supported: replaces, timer
> Content-Length: 0
>

I am having problems to see to what “488 Not acceptable here” relates to?
What is not acceptable? Is it maybe about

> [Jun 18 20:15:26] WARNING[1164] chan_sip.c: We are requesting SRTP, but
> they responded without it!

and not a codec problem?

I am not sure if this is relevant and if it really shows the working
codecs, bot for completeness the outputs of “core show codecs” and “core
show translation” follow:

> core show codecs
> Disclaimer: this command is for informational purposes only.
> It does not indicate anything about your configuration.
> INT BINARY HEX TYPE NAME
> DESCRIPTION
>
> ———————————————————————————–
> 1 (1 < < 0) (0x1) audio g723
> (G.723.1)
> 2 (1 < < 1) (0x2) audio gsm
> (GSM)
> 4 (1 < < 2) (0x4) audio ulaw
> (G.711 u-law)
> 8 (1 < < 3) (0x8) audio alaw
> (G.711 A-law)
> 16 (1 < < 4) (0x10) audio g726aal2
> (G.726 AAL2)
> 32 (1 < < 5) (0x20) audio adpcm
> (ADPCM)
> 64 (1 < < 6) (0x40) audio slin (16
> bit Signed Linear PCM)
> 128 (1 < < 7) (0x80) audio lpc10
> (LPC10)
> 256 (1 < < 8) (0x100) audio g729
> (G.729A)
> 512 (1 < < 9) (0x200) audio speex
> (SpeeX)
> 1024 (1 < < 10) (0x400) audio ilbc
> (iLBC)
> 2048 (1 < < 11) (0x800) audio g726
> (G.726 RFC3551)
> 4096 (1 < < 12) (0x1000) audio g722
> (G722)
> 8192 (1 < < 13) (0x2000) audio siren7
> (ITU G.722.1 (Siren7, licensed from Polycom))
> 16384 (1 < < 14) (0x4000) audio siren14
> (ITU G.722.1 Annex C, (Siren14, licensed from Polycom))
> 32768 (1 < < 15) (0x8000) audio slin16 (16
> bit Signed Linear PCM (16kHz))
> 65536 (1 < < 16) (0x10000) image jpeg
> (JPEG image)
> 131072 (1 < < 17) (0x20000) image png
> (PNG image)
> 262144 (1 < < 18) (0x40000) video h261
> (H.261 Video)
> 524288 (1 < < 19) (0x80000) video h263
> (H.263 Video)
> 1048576 (1 < < 20) (0x100000) video h263p
> (H.263+ Video)
> 2097152 (1 < < 21) (0x200000) video h264
> (H.264 Video)
> 4194304 (1 < < 22) (0x400000) video mpeg4
> (MPEG4 Video)
> 8388608 (1 < < 23) (0x800000) video unknown
> (unknown)
> 16777216 (1 < < 24) (0x1000000) video unknown
> (unknown)
> 33554432 (1 < < 25) (0x2000000) text unknown
> (unknown)
> 67108864 (1 < < 26) (0x4000000) text red
> (T.140 Realtime Text with redundancy)
> 134217728 (1 < < 27) (0x8000000) text t140
> (Passthrough T.140 Realtime Text)
> 268435456 (1 < < 28) (0x10000000) text unknown
> (unknown)
> 536870912 (1 < < 29) (0x20000000) text unknown
> (unknown)
> 1073741824 (1 < < 30) (0x40000000) (unk) unknown
> (unknown)
> 2147483648 (1 < < 31) (0x80000000) (unk) unknown
> (unknown)
> 4294967296 (1 < < 32) (0x100000000) audio g719
> (ITU G.719)
> 8589934592 (1 < < 33) (0x200000000) audio speex16
> (SpeeX 16khz)
> 17179869184 (1 < < 34) (0x400000000) audio unknown
> (unknown)
> 34359738368 (1 < < 35) (0x800000000) audio unknown
> (unknown)
> 68719476736 (1 < < 36) (0x1000000000) audio unknown
> (unknown)
> 137438953472 (1 < < 37) (0x2000000000) audio unknown
> (unknown)
> 274877906944 (1 < < 38) (0x4000000000) audio unknown
> (unknown)
> 549755813888 (1 < < 39) (0x8000000000) audio unknown
> (unknown)
> 1099511627776 (1 < < 40) (0x10000000000) audio unknown
> (unknown)
> 2199023255552 (1 < < 41) (0x20000000000) audio unknown
> (unknown)
> 4398046511104 (1 < < 42) (0x40000000000) audio unknown
> (unknown)
> 8796093022208 (1 < < 43) (0x80000000000) audio unknown
> (unknown)
> 17592186044416 (1 < < 44) (0x100000000000) audio unknown
> (unknown)
> 35184372088832 (1 < < 45) (0x200000000000) audio unknown
> (unknown)
> 70368744177664 (1 < < 46) (0x400000000000) audio unknown
> (unknown)
> 140737488355328 (1 < < 47) (0x800000000000) audio testlaw
> (G.711 test-law)
> 281474976710656 (1 < < 48) (0x1000000000000) video unknown
> (unknown)
> 562949953421312 (1 < < 49) (0x2000000000000) video unknown
> (unknown)
> 1125899906842624 (1 < < 50) (0x4000000000000) video unknown
> (unknown)
> 2251799813685248 (1 < < 51) (0x8000000000000) video unknown
> (unknown)
> 4503599627370496 (1 < < 52) (0x10000000000000) video unknown
> (unknown)
> 9007199254740992 (1 < < 53) (0x20000000000000) video unknown
> (unknown)
> 18014398509481984 (1 < < 54) (0x40000000000000) video unknown
> (unknown)
> 36028797018963968 (1 < < 55) (0x80000000000000) video unknown
> (unknown)
> 72057594037927936 (1 < < 56) (0x100000000000000) video unknown
> (unknown)
> 144115188075855872 (1 < < 57) (0x200000000000000) video unknown
> (unknown)
> 288230376151711744 (1 < < 58) (0x400000000000000) video unknown
> (unknown)
> 576460752303423488 (1 < < 59) (0x800000000000000) video unknown
> (unknown)
> 1152921504606846976 (1 < < 60) (0x1000000000000000) video unknown
> (unknown)
> 2305843009213693952 (1 < < 61) (0x2000000000000000) video unknown
> (unknown)
> 4611686018427387904 (1 < < 62) (0x4000000000000000) video unknown
> (unknown)
>

> core show translation
> Translation times between formats (in microseconds) for one
> second of data
> Source Format (Rows) Destination Format (Columns)
>
> g723 gsm ulaw alaw g726aal2 adpcm slin lpc10 g729
> speex ilbc g726 g722 siren7 siren14 slin16 g719 speex16 testlaw
> g723 – – – – – – – -
> – – – – – – – – – – -
> gsm – – 2 2 10001 2 1 20001 -
> 90001 – 10001 2 – – 70001 – 130001 2
> ulaw – 10001 – 1 10001 2 1 20001 -
> 90001 – 10001 2 – – 70001 – 130001 2
> alaw – 10001 1 – 10001 2 1 20001 -
> 90001 – 10001 2 – – 70001 – 130001 2
> g726aal2 – 20000 10001 10001 – 10001 10000 30000 -
> 100000 – 20000 10001 – – 80000 – 140000 10001
> adpcm – 10001 2 2 10001 – 1 20001 -
> 90001 – 10001 2 – – 70001 – 130001 2
> slin – 10000 1 1 10000 1 – 20000 -
> 90000 – 10000 1 – – 70000 – 130000 1
> lpc10 – 20000 10001 10001 20000 10001 10000 – -
> 100000 – 20000 10001 – – 80000 – 140000 10001
> g729 – – – – – – – -
> – – – – – – – – – – -
> speex – 20000 10001 10001 20000 10001 10000 30000
> – – – 20000 10001 – – 80000 – 140000 10001
> ilbc – – – – – – – -
> – – – – – – – – – – -
> g726 – 10001 2 2 10001 2 1 20001 -
> 90001 – – 2 – – 70001 – 130001 2
> g722 – 20000 10001 10001 20000 10001 10000 30000 -
> 100000 – 20000 – – – 10000 – 70000 10001
> siren7 – – – – – – – -
> – – – – – – – – – – -
> siren14 – – – – – – – -
> – – – – – – – – – – -
> slin16 – 170000 160001 160001 170000 160001 160000 180000 -
> 250000 – 170000 10000 – – – – 60000 160001
> g719 – – – – – – – -
> – – – – – – – – – – -
> speex16 – 180000 170001 170001 180000 170001 170000 190000 -
> 260000 – 180000 20000 – – 10000 – – 170001
> testlaw – 10001 2 2 10001 2 1 20001 -
> 90001 – 10001 2 – – 70001 – 130001 -
>
>
Thank you very much for any hint on this!

Best regards
Stefan

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.

fake auth rejection??

Very occasionally in my logs I see things like this. In this case 7
lines starting with the first line and each ending with one of the
group of 7. Took about 10 seconds for the 7 tries.

[2012-05-03 16:58:27] NOTICE[31850] chan_sip.c: Sending fake auth
rejection for device “unknown”

;tag=aTZ1eFu5Gi
;tag=MQ7X2xPoIy
;tag=FnfiJEymn6
;tag=tVPso6QAEp
;tag=tWHOjRp11z
;tag=DK42h3mLn1
;tag=CPW3Z9lDvN

Should I be worried?

Ira