Dismiss Notice
We would like to remind you that we’re updating our login process for all 3CX forums whereby you will be able to login with the same credentials you use for the Partner or Customer Portal. Click here to read more.

New version 7 - Inbound Rule Problem

Discussion in '3CX Phone System - General' started by ziptalk, Jan 15, 2009.

Thread Status:
Not open for further replies.
  1. ziptalk

    ziptalk New Member

    Joined:
    Nov 16, 2008
    Messages:
    180
    Likes Received:
    0
    I upgraded to the latest version last night 7.0.4744.0 and was very happy with the addition of sub-folders under extensions. I expect this will developed further in due course, to allow more than 1 teir of sub-folders and profile settings across extensions.

    However, since upgrade I have noticed that only 1 of my simple DID rules do not work as before.

    I have a DDI Range of 01932251900 - 909 on my test ISDN 2e box.
    I have a DDI Range of 01932233960 - 969 on my production 4 x ISDN 2e boxes.

    I discovered that if I made the inbound rule to *0 through to *9, I can do a mapping to the respective internal extension ending with the same number. I deliberately created my rules loose like this, so when I plug in my production ISDNs, I would not have to create additional rules, these rules basically worked for both lots of ranges.

    However I had to amend *9 to *09 for it to match and foward to the extension. e.g. *09 --> 3969 (internal extension number). THIS ONLY AFFECTS INBOUND RULE FOR *9, all the others go to their respective internal extension number!

    The *9 takes it to my ring group 8000. Please see the 3 screenshots below, the first illustrates my DID rules, the second shows the Patton ISDN Gateway, it's 10002 port with it's respective rules. Note the port rule is to go to 8000, and this is the behavious that is taking place with the *9 rule. I have finally shown the *9 rule point to extension 3969 - Any ideas would be appreciate as I have recreated this rule several times, and the only solution is to change it to *09. Am I doing something wrong ?

    Here is my Activity Log as well for the test:

    Code:
    10:20:03.396  [CM503008]: Call(8): Call is terminated
    
    10:20:01.944  [CM505001]: Ext.3967: Device info: Device Identified: [Man: Snom;Mod: 3xx series;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [snom320/6.5.16] Transport: [sip:192.168.66.57:5060]
    
    10:20:01.924  [CM503002]: Call(8): Alerting sip:3967@192.168.66.102:2051;line=s9u19qgb
    
    10:20:01.784  [CM503004]: Call(8): Calling: HuntGrp8000:3969Ext.3969@[Dev:sip:3969@192.168.66.154:2057;line=yzmyarab]
    
    10:20:01.784  [CM503004]: Call(8): Calling: HuntGrp8000:3968Ext.3968@[Dev:sip:3968@192.168.66.106:2051;line=d9xuop9s]
    
    10:20:01.763  [CM503004]: Call(8): Calling: HuntGrp8000:3967Ext.3967@[Dev:sip:3967@192.168.66.102:2051;line=s9u19qgb]
    
    10:20:01.763  [CM503010]: Making route(s) to <sip:8000@192.168.66.57:5060>
    
    10:20:01.733  [CM503001]: Call(8): Incoming call from anonymous@(Ln.10002@Patton ISDN Gateway) to <sip:8000@192.168.66.57:5060>
    
    10:20:01.723  [CM503012]: Inbound office hours rule (unnamed) for 10002 forwards to DN:8000
    
    10:13:43.069  [CM503008]: Call(7): Call is terminated
    
     

    Attached Files:

    • did.jpg
      did.jpg
      File size:
      26.4 KB
      Views:
      1,951
    • Port.jpg
      Port.jpg
      File size:
      72 KB
      Views:
      1,951
    • rule.jpg
      rule.jpg
      File size:
      52.5 KB
      Views:
      1,950
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  2. ziptalk

    ziptalk New Member

    Joined:
    Nov 16, 2008
    Messages:
    180
    Likes Received:
    0
    Anyone got any ideas on this ?

    An inbound rule of mask *8 should redirect to extension 3968, but it doesn't it goes to a ring group ? which is the default on the port, but the inbound rule should match ?

    This only begun happening when I upgraded to the latest version, please can someone put me out of my misery and let me know this is a bug.

    Thanks,

    Lewis
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. kevin

    kevin Member

    Joined:
    Nov 23, 2006
    Messages:
    316
    Likes Received:
    1
    Hi Lewis

    If you could set the logging to verbose and post the support info file into this ticket, we will try to look into the matter. Please identify the timestamps we need to look at.

    Regards

    Kevin
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  4. Spyklee

    Joined:
    Nov 1, 2007
    Messages:
    45
    Likes Received:
    0
    Hi Lewis,

    I've experienced a similair experience with our inbound DID rules.
    We've got a Patton 4554 with 2 ISDN lines and 2x4 DID numbers. With the extensions within a group te inbound rules of the second poort of the Patton are ignored.

    Eric
     
  5. William400

    William400 Well-Known Member

    Joined:
    Aug 21, 2006
    Messages:
    1,005
    Likes Received:
    0
    Hi

    We have tried to replicate the issue in question in our test labs, however have not encountered the issue in question.

    At this stage we recommend that you enable Verbose logging and then make a call then does not depict the issue, followed by a second call that does replicate the issue. Kindly send us the Support Info files for review. This will allow us follow the inbound call INVITE and its parameters, to ensure that 3CX is correctly detecting the source line and route then compare the logging of both calls. When submitting these please advise the calling and calling number as well as the time stamp of each.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  6. ziptalk

    ziptalk New Member

    Joined:
    Nov 16, 2008
    Messages:
    180
    Likes Received:
    0
    Hi William, thanks for your response and taking the time to troubleshoot this. I had upgraded my version 7 to 7.0.4744 just for the record.

    I have a DID rule *6 that forwards to extension 3966. See verbose log below - but instead now it goes to a ring group with extension 8000!

    Code:
    23:39:44.917  [CM503008]: Call(67): Call is terminated
    
    23:39:36.445  [CM505001]: Ext.3967: Device info: Device Identified: [Man: Snom;Mod: 3xx series;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [snom320/6.5.16] Transport: [sip:192.168.66.57:5060]
    
    23:39:36.435  [CM503002]: Call(67): Alerting sip:3967@192.168.66.102:2051;line=9xtzg0pg
    
    23:39:36.275  [CM503004]: Call(67): Calling: HuntGrp8000:3969Ext.3969@[Dev:sip:3969@192.168.66.154:2057;line=yzmyarab]
    
    23:39:36.275  [CM503016]: Call(67): Target is not registered: HuntGrp8000:3968Ext.3968
    
    23:39:36.265  [CM503004]: Call(67): Calling: HuntGrp8000:3967Ext.3967@[Dev:sip:3967@192.168.66.102:2051;line=9xtzg0pg]
    
    23:39:36.255  [CM503010]: Making route(s) to <sip:8000@192.168.66.57:5060>
    
    23:39:36.224  [CM503001]: Call(67): Incoming call from anonymous@(Ln.10002@Patton ISDN Gateway) to <sip:8000@192.168.66.57:5060>
    
    23:39:36.214  [CM503012]: Inbound out-of-office hours rule (unnamed) for 10002 forwards to DN:8000
    
    23:35:44.361  [CM503008]: Call(66): Call is terminated
    
    23:35:44.361  [CM502001]: Source info: From: "Lewis Sheridan"<sip:3966@94.185.202.167:5060>;tag=9e24c878<sip:3969@94.185.202.167:5060>
    
    23:35:44.361  [CM503013]: Call(66): Incoming call rejected, caller is unknown; msg=SipReq:  INVITE 3969@94.185.202.167:5060 tid=ee721c2a4c33c57c cseq=INVITE contact=3966@127.0.0.1:60332 / 2 from(wire)
    
    23:35:44.071  [CM500002]: Unidentified incoming call. Review INVITE and adjust source identification:
    
      INVITE sip:3969@94.185.202.167:5060 SIP/2.0
    
      Via: SIP/2.0/UDP 192.168.66.57:5080;branch=z9hG4bK-d8754z-ed756f3c1a446457-1---d8754z-;rport=38585;received=94.185.202.161
    
      Via: SIP/2.0/UDP 82.71.0.209:53334;branch=z9hG4bK-d8754z-tunneltid-1---d8754z-;rport
    
      Via: SIP/2.0/UDP 127.0.0.1:60332;branch=z9hG4bK-d8754z-5e6dd5031a1d1818-1---d8754z-;rport=60332
    
      Max-Forwards: 68
    
      Record-Route: <sip:3cxBridge@192.168.66.57:5080;user=proxy;uri="82.71.0.209:53334">
    
      Contact: <sip:3966@127.0.0.1:60332>
    
      To: <sip:3969@94.185.202.167:5060>
    
      From: "Lewis Sheridan"<sip:3966@94.185.202.167:5060>;tag=9e24c878
    
      Call-ID: Yjk2OGQyYmFmMWZlYjhjZjIyMzBhMjk3NDBjMjkxM2U.
    
      CSeq: 1 INVITE
    
      Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO
    
      Supported: replaces
    
      User-Agent: 3CXVoipPhone 3.0.4959.0
    
      Content-Length: 0
    
      
    
    
    Previously this worked fine, inbound call would come in, match my mask of *6, and send to the respective extension of 3966.

    However, when I create a new additional rule called *06, this rule works correctly. However I want to have a single rule that works on my test ISDN with a DDI range, and then cut-over to our live system with a different DDI range. All that is important to me is the ....*1-9 mirros to my internal extensions ...*1-9.

    Here is the verbose of it routing when I create the *06 rule.

    Code:
    23:48:59.234  [CM503008]: Call(69): Call is terminated
    
    23:48:58.163  [CM505001]: Ext.3966: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CXVoipPhone 3.0.4959.0] Transport: [sip:192.168.66.57:5060]
    
    23:48:58.142  [CM503002]: Call(69): Alerting sip:3966@127.0.0.1:60332;rinstance=e14f83077c04d514
    
    23:48:57.301  [CM503004]: Call(69): Calling: Shared:Ext.3966@[Dev:sip:3966@127.0.0.1:60332;rinstance=e14f83077c04d514, Dev:sip:3966@192.168.66.203:60918;rinstance=f5fed60619d694b8]
    
    23:48:57.301  [CM503010]: Making route(s) to <sip:3966@192.168.66.57:5060>
    
    23:48:57.271  [CM503001]: Call(69): Incoming call from anonymous@(Ln.10002@Patton ISDN Gateway) to <sip:3966@192.168.66.57:5060>
    
    23:48:57.261  [CM503012]: Inbound out-of-office hours rule (Lewis) for 10002 forwards to DN:3966
    
    Summary:

    *6 no longer matches, and the call goes to the ring group 8000 and *06 will match but will not match when I plug in a different set of ISDN 2e's with a different DDI. Hope those logs help - here is a screenshot of my rules for reference:



    Final Note: This worked fine prior to the upgrade, and affects all my existing rules that comprise *1-9. I look forward to your response.

    Kind Regards, Lewis
     

    Attached Files:

    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. ziptalk

    ziptalk New Member

    Joined:
    Nov 16, 2008
    Messages:
    180
    Likes Received:
    0
    Hi William, I have deleted all the rules and recreated them just now and it appears to be working and behaving normally. Very strange!

    Lewis
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  8. doddy

    Joined:
    Feb 1, 2009
    Messages:
    12
    Likes Received:
    0
    I am getting a similar issue with the latest build. I can add DDI's I can edit DDI's but if I delete a DDI then all DDI then fail and the ONLY recovery is to delete all DDI's and add them back again. I have also seen problems of all DDI's faikling when the 16 DDI was added.

    This is an incredibly annoying issue and which has caused a huge amount of investigation this weekend. we have built the system on multiple environments includiong clean W2003, W2008, IIS and Cassini and the problem exists in all conditions. All DDI are on the same single PSTN trunk
     
Thread Status:
Not open for further replies.