[Problem] SN 4120 / Asterisk 11.4.0: Auch unbeantwortete Anrufe erhalten ANSWERED im CDR

[Ralph*]

Eben ist mir aufgefallen, dass in den CDRs ausgehende Gespräche auch dann die Disposition "ANSWERED" und billsecs > 0 erhalten, wenn der Anruf unbeantwortet geblieben ist.

Das ist für die korrekte hausinterne Abrechnung der ausgehenden Gespräche nicht so hilfreich...

In diesem Fall sollte doch eigentlich "NO ANSWER" und billsec = 0 richtig sein - so war es zumindest früher, als die ISDN-Verbindung noch über eine Diva Server Karte und chan-capi erfolgt ist und es noch ein Asterisk 1.4 war.

Asterisk bekommt also keine Information vom SmartNode, dass der Rufaufbau nicht erfolgreich war, oder?
Könnte das etwas damit zu tun haben, ob Asterisk im media path ist?

Hier ist meine sip.conf:

[general]
domain=192.168.0.24 (IP-Adresse von Asterisk)
bindport=5060                   ; UDP Port to bind to (SIP standard is 5060)
bindaddr=0.0.0.0                ; IP address to bind to (0.0.0.0 binds to all)
srvlookup=no
nat=no
videosupport=no

;--- Security ---
context=internalsip
deny=0.0.0.0/0
contactdeny=0.0.0.0/0
contactpermit=192.168.0.0/24
allowguest=no
alwaysauthreject=yes

; --- Language and Codec ---
language=de
disallow=all
allow=alaw

;--- BLF ---
allowsubscribe=yes
notifyringing=yes
notifyhold=yes
limitonpeers=yes

[gw-smartnode]
type=peer
host=192.168.0.2 (IP-Adresse des SmartNode)
port=5060
context=from-patton

Konfiguration des SmartNode:

#----------------------------------------------------------------#
#                                                                #
# SN4120/2BIS4V                                                  #
# R6.3 2013-05-01 H323 SIP                                       #
# 2013-09-02T13:38:23                                            #
# SN/xxxxxxxxxxxx                                                #
# Generated configuration file                                   #
#                                                                #
#----------------------------------------------------------------#

cli version 3.20
clock local default-offset +02:00
dns-client server 192.168.0.1
webserver port 80 language en
sntp-client
sntp-client server primary 192.168.0.1 port 123 version 4

system

  ic voice 0

system
  clock-source 1 bri 0 0
  clock-source 2 bri 0 1

profile ppp default

profile tone-set default

profile voip default
  codec 1 g711alaw64k rx-length 20 tx-length 20
  codec 2 g711ulaw64k rx-length 20 tx-length 20
  fax transmission 1 bypass g711alaw64k rx-length 10 tx-length 10
  fax transmission 2 bypass g711ulaw64k rx-length 10 tx-length 10
  fax transmission 3 relay t38-udp
  fax redundancy low-speed 2 high-speed 1
  fax max-bit-rate 9600
  fax bypass-method v150-vbd
  modem transmission 1 bypass g711alaw64k rx-length 10 tx-length 10
  modem bypass-method v150-vbd

profile pstn default

profile sip default
  no autonomous-transitioning

profile aaa default
  method 1 local
  method 2 none

context ip router

  interface eth0
    ipaddress 192.168.0.2 255.255.255.0
    tcp adjust-mss rx mtu
    tcp adjust-mss tx mtu

context cs switch
  national-prefix 0
  international-prefix 00

  routing-table called-e164 RT_IN
    route .T dest-interface IF_SIP

  interface isdn IF_ISDN_00
    route call dest-table RT_IN
    no call-waiting

  interface isdn IF_ISDN_01
    route call dest-table RT_IN
    no call-waiting

  interface sip IF_SIP
    bind context sip-gateway GW_SIP
    route call dest-service SER_HUNT_PSTN
    remote 192.168.0.24
    early-connect
    early-disconnect
    privacy

  service hunt-group SER_HUNT_PSTN
    cyclic
    drop-cause normal-unspecified
    drop-cause no-circuit-channel-available
    drop-cause network-out-of-order
    drop-cause temporary-failure
    drop-cause switching-equipment-congestion
    drop-cause access-info-discarded
    drop-cause circuit-channel-not-available
    drop-cause resources-unavailable
    route call 1 dest-interface IF_ISDN_00
    route call 2 dest-interface IF_ISDN_01

context cs switch
  no shutdown

context sip-gateway GW_SIP

  interface IF_GWSIP
    bind interface eth0 context router port 5060

context sip-gateway GW_SIP
  no shutdown

port ethernet 0 0
  medium auto
  encapsulation ip
  bind interface eth0 router
  no shutdown

port bri 0 0
  clock auto
  encapsulation q921

  q921
    protocol pp
    uni-side auto
    encapsulation q931

    q931
      protocol dss1
      uni-side user
      bchan-number-order ascending
      encapsulation cc-isdn
      bind interface IF_ISDN_00 switch

port bri 0 0
  no shutdown

port bri 0 1
  clock auto
  encapsulation q921

  q921
    protocol pp
    uni-side auto
    encapsulation q931

    q931
      protocol dss1
      uni-side user
      bchan-number-order ascending
      encapsulation cc-isdn
      bind interface IF_ISDN_01 switch

port bri 0 1
  no shutdown

Danke für Eure Hilfe!

Ralph

 

[Ralph*]

Noch eine Erkenntnis dazu:

Im CLI von Asterisk erhalte ich folgendes, wenn ich vom Telefon 123 aus den externen Teilnehmer 1234567 anrufe:

    -- Called SIP/1234567@gw-smartnode
    -- SIP/gw-smartnode-00001358 [B]answered[/B] SIP/123-00001357

Der SmartNode antwortet also nicht mit "is ringing" sondern meldet sofort "answered", obwohl die Verbindung zum externen Teilnehmer noch nicht aufgebaut wurde (es noch "klingelt").

Kann ich das nicht irgendwie "richtiger" machen?

Ralph

 

[sunseb]

Hallo Ralph,

es ist einfach nur vielleicht einen Versuch wert:

Im interface sip IF_SIP das early-connect herausnehmen (no early connect).

Gruss, SEBastian

PS. Ich kann deinen Frust bezüglich der Anworten in diesem Unterforum sehr gut verstehen. Ich bin auch nicht der Spezialist, hatte aber mit dieser Änderung schon mal Erfolg im Zusammenhang mit einem Lancom-Router...

 

[Ralph*]

Hallo SEBastian,

das Blöde ist, dass es bei manchen Gesprächen funktioniert - wie ich jetzt herausgefunden habe. Ich beobachte im Asterisk-CLI über den Tag verschiedene Telefonate ins ISDN-Netz: Bei manchen ist der Status des SmartNodes zunächst "is ringing", bei anderen kommt sofort "answered".

Ich muss herausfinden, ob sich bestimmte Nebenstellen (z.B. wegen einer anderen Konfiguration der snoms) so oder anders verhalten, es möglicherweise von der angerufenen Nummer abhängt (was ich im Moment für unwahrscheinlich halte...), oder welche andere Gesetzmäßigkeit dahinter steckt.

Das early-connect kann also eigentlich keinen Einfluss darauf haben.

Bezüglich des Frustes danke ich für das Verständnis. Das hilft! Ich verstehe aber auch, dass die Forum-Cracks nicht zu jedem Thema ausführlich Stellung nehmen, wenn sie mit der Dienstleistung eigentlich ihr Geld verdienen.

Ich denke aber, dass ich mit unserem Szenario (snom an Asterisk an SmartNode an ISDN-Anlagenanschluss) keine besonderen Konfigurationssonderwünsche erfüllen muss. Das ist doch eigentlich ein Setup, wie es in Deutschland oder sogar Europa hundert- oder gar tausendfach vorkommt und es daher eine erprobte, funktionierende und publizierte SmartNode-Konfiguration dafür geben müsste... aber das denkt vermutlich jeder Thread-Ersteller von seinem Problem ;-)

Ralph

 

[Ralph*]

Update: Am Telefon liegt es schon mal nicht.

Die selbe Nebenstelle hat kurz hintereinander zwei verschiedene Festnetzteilnehmer angerufen. Beim ersten Versuch hatte sich der Kollege wohl verwählt, denn die Nummern waren bis auf die erste Ziffer identisch. Sofort danach erfolgte dann der Anruf auf die - dann wohl richtige - Nummer:

Erster Anruf:

  == Using SIP RTP CoS mark 5
    -- Called SIP/123456@gw-smartnode
    -- SIP/gw-smartnode-000016a5 [B]is ringing[/B]
    -- SIP/gw-smartnode-000016a5 answered SIP/123-000016a4

Zweiter Anruf:

  == Using SIP RTP CoS mark 5
    -- Called SIP/223456@gw-smartnode
    -- SIP/gw-smartnode-000016a7 answered SIP/123-000016a6

Kann es an den unterschiedlichen NTBAs liegen? Ich weiß nicht, wie der SmartNode die Amtsleitungen für abgehende Anrufe auswählt, aber möglicherweise wurden die beiden Anrufe auf zwei verschiedenen NTBAs geführt. Ist vermutlich Quatsch, oder?

Freue mich über jede Anregung...

Ralph

 

[Ralph*]

Hallo SEBastian,

es ist zwar schon eine Weile her... aber nachdem ich das early-connect herausgenommen habe, funktioniert es.

Vielen Dank für den Denkanstoß - man sollte Lösungsvorschläge eben auch ausprobieren, und nicht wie ich erst mal behaupten, dass es daran nicht liegen könnte!

Schöne Grüße
Ralph