Christian

Most Valued Users
  • Content count

    35
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Christian

  • Rank
    Advanced Member
  • Birthday 06/06/1989

Profile Information

  • Gender
    Male
  • Location
    Hannover, Germany
  1. Hallo Mak, schau mal hier: http://archive-swyx-forum.com/community/Forums/tabid/54/forumid/46/threadid/6198/scope/posts/Default.aspx#.WUJVPmjyguU Liebe Grüße
  2. Dein Block 9981 müsste die gleiche Weiterleitung hinterlegt haben wie "Kollegin 2", allerdings mit dem Haken "Mit Callrouting des Ziels fortfahren". Dann ist das Gespräch aber raus aus dem Kontext des Notruftelefons und du hast keine Chance es von dort zurück zu holen. Der einfachste Lösungsansatz ist es, bei "Kollegin 2" ein weiteres Callrouting zu hinterlegen, dass nach der Umleitung auf "Kollegin 3" eine Weiterleitung an die Mailbox des Notruftelefons macht. Letzteres geht am einfachsten mit einem individuellen Voicemail-Block im Callrouting des Kollegens. Eine weitere Möglichkeit ist es, den Ruf nach dem Versuch an "Kollegin 3" zuzustellen wieder an das Notruftelefon weiter zu leiten und dort als erstes Abzufragen, ob der Ruf von Kollegin 2 kommt (Details HIER) und dann aus sich des Notruftelefons an die eigene Voicemail durchzustellen - dann klappt auch die Signalisierung von hinterlassenen Voicemailnachrichten im Swyx Client.
  3. Du kannst in deinem Dummyuser die Durchwahl des ursprünglichen Empfängers UND die Gruppendurchwahl angeben. Einfach beide Nummern im Durchstellenblock mit Semikolon trennen.
  4. #solved by myself never noticed, that the PMX/ISDN PRI takes 30 lines doesn't matter the calls are active or not. I've now reduced the number of lines for PMX trunk, restarted the trunk and the freed licenses are now available to the SIP trunks. I think that will help. All the best, Christian
  5. Hi Guys, I just came across an error that sometimes happens with one sip trunk. Thats what happens: We call a client in France, due to the +33 countrycode, Netphone selects the IPDirections trunk - so far everything is fine.than during the connecting process, the system throws this error: SPBXBwLtdCont::AllocateBandwidth1 (location [4], bandwidth 1) SPBXBwLtdTrunk::AllocateBandwidth (bandwidth 1) on location [4] 'Frankreich'. SPBXBwLtdTrunk::AllocateBandwidth () Allocated 1. used/max 1/INFINITE at location [4] 'Frankreich'. SPBXCall::AllocateBandwidth () Allocated 1 at location [4] Frankreich. Total allocation is 1 SPBXCall::AdjustBandwidth () Allocated bandwidth (1) because both parties reside in different locations. local [4], peer [1] SDeviceImpl::IncrChannelCount (out) no free channel license available SPBXCall::IncrementChannelCounter incrementing channel counter (outbound) failed with LicenseLimitReached SPBXCallFSM::ActionOnOutgoingCall () No free channel -> aborting call. STclCall::SignalDisconnect (NoChannelAvailable, lateDisconnect=false, extCause=0) 16685658 After this, the system restarts the process of an outgoing call with our german PMX trunk. We've in total 36 voice channels licensed, but at this time only 5 or so has been in use. The IPDirections trunk has 4 channels configured but there has been no other active call on that trunk. The outgoing call through the PMX trunk has been successfull. Do you have any idea, why this could happen from time to time? ps: attached is the IpPbxSrv.log filtered to the call. Many thanks in advance and all the Best! Christian IpPbxSrv.exe.log
  6. unresolved

    I use IP-addresses in my trunk group configuration, the only dns names are the realms. So it is probably a different issue, right? I can see the event 8706, but not not 8708 Unfortunatly the node4 sip trunk is with IP authentication and not with sip registration, I think that is probably the reason for that. Is there any other way to monitor the Trunk state?
  7. Hi Guys, from time to time, calls are not accepted by our Netphone 2015R3 with the reason 404 destination number not found- however the numbers are fine. some times I can call from my mobile just 2nd time right after the first try and it works. the SIP packets seem to be absolutely the same. 2nd problem is, that the same trunk appears in the administrator from time to time as unconnected (small white cross). After disabling and activating the trunk, everything is fine again. I couldn't find a way to monitor a way of this unconnect event or an entry in the system logs. Is there a possibility to monitor this?
  8. unresolved

    Mit einer Gruppe wirst du das nicht gelöst bekommen. Du könntest jedoch händisch über ECR eine parallele Rufzustellung realisieren, dazu musst du die Nummern im Durchstellenblock nur mit Semikolon separieren. ACHTUNG: Der Ruf wird dabei immer an das Gerät zugestellt, dass zu erst einen Verbindungsaufbau meldet. - Wenn bei einem der Mitarbeiter also zb eine Voicemail aktiv ist, bekommt dieser den Anruf. Ich würde dir empfehlen von dieser Prozedur Abstand zu nehmen und zb eine Voicemail zu schalten, deren Nachricht an ein gemeinsames Postfach zugestellt wird.
  9. While you're in edit mode, you can open the tempfolder where als images are stored %tmp%\ClCurSkn Todo: Edit Background, click on select Image icon, replace background.bmp with the new larger background, swyxit will complain regarding the size, but afterwards it will show the new background. now safe your skin prior to any further changes.
  10. unresolved

    So, problem has been sorted. The problem was an update within the firewall, which removed the "static port" rule for our netphone server. static port means, that the firewall uses the same port for forwarding traffic to the internet, as the netphone server did. Without that option, the STUN Server discovered the the port used by the firewall, which is completely random. this caused to problems: 1. it's almost impossible to setup a proper port forwarding in the firewall 2. the linkmgr stucks listening on port 5500x, so the RTP stream couldn't be received even if the firewall would forward the packets. After telling the firwall to use the same port as the netphone server, everything is works fine again.
  11. Hallo Zusammen, wir suchen für unsere Telefonanlage einen neuen Ansprechpartner zur schnelleren Lösung von auftretenden Problemen. Weil wir mit unserem aktuellen Systempartner nicht zufrieden sind, suche ich einen neuen Swyxpartner der mich bei der Wartung unserer Systems unterstützt. Besonderen Wert lege ich auf eine hohe Expertise im Bereich SIP Trunking und ECR. Über zielführende Kontaktaufnahmen freue ich mich sehr!
  12. unresolved

    Hi Virikas, many thanks for your prompt response! I've discoverd that is seems to be caused by the STUN server / external IP discovery. The Port suggested in the SIP package by the LinkMgr is always the same as the port behind "Use STUN external IP/ports=62.154.242.220:31206" If I disable STUN, the LinkMgr uses again ports between 55000 and 56000. However in this case, the wrong ip is signaled to the trunk provider. Any suggestions on how to solve that?
  13. unresolved

    Hi Guys, I'm struggeling since wednesday with one of our SIP trunks - the Node4 one. So far, neither me nor Node4 seems to have done any change. However since Wednesday, we can't hear the external person. I figured out, that during connection (SIP status packet 200 OK), the LinkMgr requests to receive the RDP Mediastream on a specific port: SIP/SDF Status: 200 OK: [...] Media Description, name and address (m): audio 17267 RTP/AVP 8 101 [...] in result to this message, node4 tries to send the RTP stream to 17267 - but unfortunately the LinkMgr isn't listening on that port. Does anyone has an idea of what causes this issue and how it could be solved? many thanks in advance!