Rebound not working

Discussion in '3CX Phone System - General' started by carolinainnovative, Jun 24, 2010.

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

    Joined:
    May 4, 2009
    Messages:
    369
    Likes Received:
    6
    3cx v 9 Beta 2 - Windows Server 2008

    Testing rebound functionality. It isn't going well.

    Ext. 101 set to ring extension for 18 seconds then forward to cell w/ rebound.

    When rebound is OFF, the call transfers normally to my cell phone.

    With rebound ON, the caller hears the prompt for their name and after speaking the name and pressing any key, the call is put on hold VERY briefly then transfered to the extension's voicemail instead of being forwarded to the cell.

    Logs are as follows for the ENTIRE call:

    Note - for security, the following substitutions have been made:

    ip.addr.of.pbx = Ip address of 3cx server

    internalsipdomain.local = my domain name as configured under "direct sip" (and yes - in the real one it is a REAL domain that is properly configured with the appropriate DNS SRV records)

    sip.internalsipdomain.local = the fqdn of my 3cx box

    1aaaaaaaaaa = my cell phone

    1xxxxxxxxxx = the phone from which I originated this call

    Code:
    18:31:22.189  [MS210003] C:30.6:Answer provided. Connection(transcoding mode[unsecure]):127.0.0.1:7070(7071)
    18:31:22.187  [MS210001] C:30.1:Answer received. RTP connection[unsecure]: 4.55.5.130:26684(26685)
    18:31:22.185  Remote SDP is set for legC:30.1
    18:31:22.049  [CM503007]: Call(30): Device joined: sip:999@127.0.0.1:40600;rinstance=9f9a7143963eb399
    18:31:22.041  [MS210002] C:30.1:Offer provided. Connection(transcoding mode): ip.addr.of.pbx:9000(9001)
    18:31:22.037  [MS210000] C:30.6:Offer received. RTP connection: 127.0.0.1:40658(40659)
    18:31:22.029  Remote SDP is set for legC:30.6
    18:31:22.022  [CM505001]: Ext.999: Device info: Device Identified: [Man: 3CX Ltd.;Mod: Voice Mail Menu;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CX Voice Mail Menu] PBX contact: [sip:999@127.0.0.1:5060]
    18:31:22.021  [CM503002]: Call(30): Alerting sip:999@127.0.0.1:40600;rinstance=9f9a7143963eb399
    18:31:21.858  [CM503025]: Call(30): Calling Ext:Ext.999@[Dev:sip:999@127.0.0.1:40600;rinstance=9f9a7143963eb399]
    18:31:21.800  [CM503004]: Call(30): Route 1: Ext:Ext.999@[Dev:sip:999@127.0.0.1:40600;rinstance=9f9a7143963eb399]
    18:31:21.799  [CM503010]: Making route(s) to <sip:101@127.0.0.1:5060;user=vmail>
    18:31:21.795  Refer: from="1aaaaaaaaaa"<sip:101@internalsipdomain.local:5060>;tag=bd5e2567; to="WIRELESS CALLER"<sip:+1xxxxxxxxxx@127.0.0.1:5060>;tag=ae63c105; RefTo=<sip:101@127.0.0.1:5060;user=vmail>
    18:31:21.578  [MS210003] C:30.5:Answer provided. Connection(transcoding mode[unsecure]):127.0.0.1:7066(7067)
    18:31:21.576  [MS210001] C:30.1:Answer received. RTP connection[unsecure]: 4.55.5.130:26684(26685)
    18:31:21.574  Remote SDP is set for legC:30.1
    18:31:21.423  [MS210002] C:30.1:Offer provided. Connection(transcoding mode): ip.addr.of.pbx:9000(9001)
    18:31:21.421  [MS210000] C:30.5:Offer received. RTP connection: 127.0.0.1:40654(40655)
    18:31:21.418  Remote SDP is set for legC:30.5
    18:31:21.172  [CM503020]: Normal call termination. Reason: Not available
    18:31:21.172  [CM503016]: Call(31): Attempt to reach <sip:1aaaaaaaaaa@127.0.0.1:5060> failed. Reason: Not Registered
    18:31:21.170  [CM503016]: Call(31): Attempt to reach <sip:1aaaaaaaaaa@127.0.0.1:5060> failed. Reason: Not Registered
    18:31:21.170  [CM503017]: Call(31): Target is not registered: Out.1aaaaaaaaaa{rule=11 Digit Dialing- Fax}
    18:31:21.127  [CM503010]: Making route(s) to <sip:1aaaaaaaaaa@127.0.0.1:5060>
    18:31:21.126  [MS210000] C:31.1:Offer received. RTP connection: 127.0.0.1:40656(40657)
    18:31:21.124  Remote SDP is set for legC:31.1
    18:31:21.123  [CM505001]: Ext.IVRForward: Device info: Device Identified: [Man: 3CX Ltd.;Mod: 3CX IVRForward helper;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CX IVRForward helper] PBX contact: [sip:IVRForward@127.0.0.1:5060]
    18:31:21.121  [CM503001]: Call(31): Incoming call from Ext.IVRForward to <sip:1aaaaaaaaaa@127.0.0.1:5060>
    18:31:21.112  [CM500002]: Info on incoming INVITE:
      INVITE sip:1aaaaaaaaaa@127.0.0.1:5060 SIP/2.0
      Via: SIP/2.0/UDP 127.0.0.1:40600;branch=z9hG4bK-d8754z-a868594ac979297a-1---d8754z-;rport=40600
      Max-Forwards: 70
      Contact: <sip:IVRForward@127.0.0.1:40600;rinstance=9d05019878bb7bf3>
      To: <sip:1aaaaaaaaaa@127.0.0.1:5060>
      From: "IVRForward"<sip:IVRForward@127.0.0.1:5060>;tag=79253b56
      Call-ID: OGEwNTBiMzk2YWRlMjgzOGU4Nzc4MDg5MTBhOGFiYWY.
      CSeq: 2 INVITE
      Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
      Proxy-Authorization: Digest username="IVRForward",realm="3CXPhoneSystem",nonce="414d535c02331c3811:8a815e19061e1ecafc98d5b87e02b17c",uri="sip:1aaaaaaaaaa@127.0.0.1:5060",response="095f38af92e3955c870a339441fb7da7",algorithm=MD5
      Supported: replaces
      User-Agent: 3CX IVRForward helper
      Content-Length: 0
      
    18:31:12.766  [MS210003] C:30.5:Answer provided. Connection(transcoding mode[unsecure]):127.0.0.1:7066(7067)
    18:31:12.763  [MS210001] C:30.1:Answer received. RTP connection[unsecure]: 4.55.5.130:26684(26685)
    18:31:12.761  Remote SDP is set for legC:30.1
    18:31:12.612  [CM503007]: Call(30): Device joined: sip:IVRForward@127.0.0.1:40600;rinstance=9d05019878bb7bf3
    18:31:12.607  [MS210002] C:30.1:Offer provided. Connection(transcoding mode): ip.addr.of.pbx:9000(9001)
    18:31:12.604  [MS210000] C:30.5:Offer received. RTP connection: 127.0.0.1:40654(40655)
    18:31:12.601  Remote SDP is set for legC:30.5
    18:31:12.599  [CM505001]: Ext.IVRForward: Device info: Device Identified: [Man: 3CX Ltd.;Mod: 3CX IVRForward helper;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CX IVRForward helper] PBX contact: [sip:IVRForward@127.0.0.1:5060]
    18:31:12.598  [CM503002]: Call(30): Alerting sip:IVRForward@127.0.0.1:40600;rinstance=9d05019878bb7bf3
    18:31:12.507  [CM503003]: Call(30): Call to sip:101@sip.internalsipdomain.local:5060 has failed; Cause: 487 Request Terminated; from IP:68.156.94.252:36358
    18:31:12.385  [CM503003]: Call(30): Call to sip:101@internalsipdomain.local has failed; Cause: 487 Request Terminated; from IP:70.63.254.171:5060
    18:31:12.382  [CM503025]: Call(30): Calling Ext:Ext.IVRForward@[Dev:sip:IVRForward@127.0.0.1:40600;rinstance=9d05019878bb7bf3]
    18:31:12.319  [CM503005]: Call(30): Forwarding: Ext:Ext.IVRForward@[Dev:sip:IVRForward@127.0.0.1:40600;rinstance=9d05019878bb7bf3]
    18:30:57.047  Currently active calls - 1: [30]
    18:30:54.449  [CM505001]: Ext.101: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CXPhone 4.0.12964.0] PBX contact: [sip:101@sip.internalsipdomain.local:5060]
    18:30:54.448  [CM503002]: Call(30): Alerting sip:101@68.156.94.252:36358;rinstance=9c59c19afeda0ce2
    18:30:54.234  [CM503025]: Call(30): Calling Ext:Ext.101@[Dev:sip:101@68.156.94.252:36358;rinstance=9c59c19afeda0ce2]
    18:30:54.222  [CM503025]: Call(30): Calling Ext:Ext.101@[Dev:sip:101@70.63.254.171:5060]
    18:30:54.166  [CM503004]: Call(30): Route 1: Ext:Ext.101@[Dev:sip:101@70.63.254.171:5060,Dev:sip:101@68.156.94.252:36358;rinstance=9c59c19afeda0ce2]
    18:30:54.162  [CM503010]: Making route(s) to <sip:101@127.0.0.1:5060>
    18:30:54.158  Refer: from=<sip:800@127.0.0.1:5060>;tag=184cc211; to="WIRELESS CALLER"<sip:+1xxxxxxxxxx@127.0.0.1:5060>;tag=b2646d11; RefTo=<sip:101@127.0.0.1:5060>
    18:30:53.942  [MS210003] C:30.2:Answer provided. Connection(transcoding mode[unsecure]):127.0.0.1:7064(7065)
    18:30:53.940  [MS210001] C:30.1:Answer received. RTP connection[unsecure]: 4.55.5.130:26684(26685)
    18:30:53.937  Remote SDP is set for legC:30.1
    18:30:53.784  [MS210002] C:30.1:Offer provided. Connection(transcoding mode): ip.addr.of.pbx:9000(9001)
    18:30:53.782  [MS210000] C:30.2:Offer received. RTP connection: 127.0.0.1:40652(40653)
    18:30:53.779  Remote SDP is set for legC:30.2
    18:30:50.335  [MS211000] C:30.1: 4.55.5.130:26684 is delivering DTMF using RTP payload (RFC2833). In-Band DTMF tone detection is disabled for this call segment.
    18:30:44.810  Session 19004 of leg C:30.1 is confirmed
    18:30:44.655  [CM503007]: Call(30): Device joined: sip:800@127.0.0.1:40600;rinstance=cce340fb53b5631a
    18:30:44.647  [CM503007]: Call(30): Device joined: sip:scconsultants@66.23.129.253:5060
    18:30:44.641  [MS210003] C:30.1:Answer provided. Connection(transcoding mode[unsecure]):ip.addr.of.pbx:9000(9001)
    18:30:44.636  [MS210001] C:30.2:Answer received. RTP connection[unsecure]: 127.0.0.1:40652(40653)
    18:30:44.632  Remote SDP is set for legC:30.2
    18:30:44.617  [CM505001]: Ext.800: Device info: Device Identified: [Man: 3CX Ltd.;Mod: 3CX IVR;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CX IVR] PBX contact: [sip:800@127.0.0.1:5060]
    18:30:44.617  [CM503002]: Call(30): Alerting sip:800@127.0.0.1:40600;rinstance=cce340fb53b5631a
    18:30:44.477  [CM503025]: Call(30): Calling Ext:Ext.800@[Dev:sip:800@127.0.0.1:40600;rinstance=cce340fb53b5631a]
    18:30:44.473  [MS210002] C:30.2:Offer provided. Connection(transcoding mode): 127.0.0.1:7064(7065)
    18:30:44.443  [CM503004]: Call(30): Route 1: Ext:Ext.800@[Dev:sip:800@127.0.0.1:40600;rinstance=cce340fb53b5631a]
    18:30:44.440  [MS210000] C:30.1:Offer received. RTP connection: 4.55.5.130:26684(26685)
    18:30:44.438  [CM503010]: Making route(s) to <sip:800@ip.addr.of.pbx:5060>
    18:30:44.433  Remote SDP is set for legC:30.1
    18:30:44.432  [CM505003]: Provider:[nexVortex Inbound/Outbound] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [Zultys MX250 v5.2.17 build 2] PBX contact: [sip:scconsultants@sip.internalsipdomain.local:5060]
    18:30:44.426  [CM503001]: Call(30): Incoming call from +1xxxxxxxxxx@(Ln.10000@nexVortex Inbound/Outbound) to <sip:800@ip.addr.of.pbx:5060>
    18:30:44.411  [CM503012]: Inbound out-of-office hours rule (unnamed) for 10000 forwards to DN:800
    18:30:44.409  Looking for inbound target: called=+18034618970; caller=+1xxxxxxxxxx
    18:30:44.403  [CM500002]: Info on incoming INVITE:
      INVITE sip:18034618970@ip.addr.of.pbx SIP/2.0
      Via: SIP/2.0/UDP 66.23.129.253:5060;branch=z9hG4bK5791.7679c4f1.0
      Via: SIP/2.0/UDP 4.55.5.163:5060;branch=z9hG4bK07B42e623f8efbb3db3
      Max-Forwards: 16
      Record-Route: <sip:+18034618970@66.23.129.253:5060;nat=yes;ftag=gK077bada8;lr=on>
      Contact: "WIRELESS CALLER"<sip:+1xxxxxxxxxx@4.55.5.163:5060>
      To: <sip:+18034618970@66.23.129.253:5060>
      From: "WIRELESS CALLER"<sip:+1xxxxxxxxxx@4.55.5.163:5060>;tag=gK077bada8
      Call-ID: 336021451_58000628@4.55.5.163
      CSeq: 12712 INVITE
      Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
      Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE
      Supported: 100rel
      Content-Length: 0
      Remote-Party-ID: "WIRELESS CALLER" <sip:+1xxxxxxxxxx@4.55.5.163:5060>;privacy=off
    
    
     
  2. nb

    nb Support Team
    Staff Member 3CX Support

    Joined:
    Jun 7, 2007
    Messages:
    2,129
    Likes Received:
    152
    Can you make a wireshark capture and send it?
    Can you also send a backup of your system? nb@3cx.com

    I can assure you that rebound works. What means are you using for outbound calls? Are you putting the correct outbound rule in the rebound address?

    Is the extension set to the correct status profile that catches the rebound function?

    If it is going to voicemail instead it means that the rebound external number cannot be reached.

    If you replace the mobile number with an extension does it work? (I know it might not make sense to rebound to an internal extension but this is just for a test- to rule out whether the rebound function is incorrect or whether the external route can not be reached)

    let us know
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. carolinainnovative

    Joined:
    May 4, 2009
    Messages:
    369
    Likes Received:
    6
    Nicky -

    Your questions helped me narrow down the issue - It is an outbound rule issue.

    I have a bunch of outbound rules. The first 4 are tied to specific ranges of extensions - namely 888-899. 888 is obviously the default FAX ext and I have "allocated" 889-899 as additional fax extensions. since 3cx doesn't seem to be using them, I figured that would be ok. I have taken that voip provider offline temporarily while I test some other stuff. Hence why the calls are failing. HOWEVER THOSE ARE NOT SUPPOSED to be affecting anything because they are specifically tagged as only for extns 889-899. Unfortunately, they HAVE to appear before my REAL outbound rules - otherwise they would never be hit... the whole "first match vs best match" thing - ya get me?

    The rebound appears to come from an extension called IVRForward. IVRForward seems to hit the first rule it sees that matches the number of digits and prefix in outbound and runs with it. The correct behavior, in my opinion, would be to find the first rule that either matches the "Extension" IVRForward (and number of digits/prefix) or hit the first rule with NO extension restriction that matches digits & prefix.

    So - what can we do permanently about this? Eventually I'll be re-enabling the "fax" voip provider - and I don't want the rebound calls going out that provider. I want it going out my main NexVortex sip trunk.

    If you still need the answers to those first questions and the backup sent to you, let me know.

    Thanks,

    Chavous
     
  4. nb

    nb Support Team
    Staff Member 3CX Support

    Joined:
    Jun 7, 2007
    Messages:
    2,129
    Likes Received:
    152
    Send me a screenshot of your outboud rules as they were before.
    And send me a screenshot of how you configured rebound. The rebound (like any other outbound rule) takes the first rule that matches. Probably the configuration of the outbound rules 888 and 889 is conflicting with the prefix you entered in rebound.

    Let me know because if there is something wrong, I want to nail it before the next release on this.
    We need this feature to be working 100%
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. carolinainnovative

    Joined:
    May 4, 2009
    Messages:
    369
    Likes Received:
    6
    Nicky - thanks for looking into this...

    Outbound Rules:


    Rebound Config (I think this is what you wanted)


    The Mobile Number is in the standard north american number 11-digit format - 1XXXYYYZZZZ

    As you can see from the outbound rules, we're not using 9 to dial out or anything similar.

    (*Edited 11:41am est - flipped the images - had them listed backwards)
     

    Attached Files:

  6. nb

    nb Support Team
    Staff Member 3CX Support

    Joined:
    Jun 7, 2007
    Messages:
    2,129
    Likes Received:
    152
    From which rule do you want this rebound call to go out from? From the list of outbound rules you showed me?
    is the 1 before the XXXXXXXXXX you specified PART of the number or is it the prefix for the outbound rule?

    Can you also try to put the number in the FW to external number or skype id field just for a test? Remove it from the mobile number field for now.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. carolinainnovative

    Joined:
    May 4, 2009
    Messages:
    369
    Likes Received:
    6
    The 1 is part of the xxx - so for example, my mobile number is listed as 18035551212... It is sent to the voip carrier intact (ie i have it set to strip nothing, prepend nothing - the same is true for both 11-digit dialing outbound rules).

    The rule it should hit is "11 digit direct dial." Prefix of 1, 11 digits and NO extension restriction.

    I have tried it in the "other" redirect to field as well (after removing it from mobile number) - same effect.
     
  8. nb

    nb Support Team
    Staff Member 3CX Support

    Joined:
    Jun 7, 2007
    Messages:
    2,129
    Likes Received:
    152
    Test 1: Change the first 3 rules from 888-889 to 888,889 instead - see if this makes a difference. Since they are after each other, the range equality - is redundant in this case and it might cause a problem. try and let me know.

    The rules that the 11 direct digit rule might conflict with are the following:

    Test 2: put the rule 11 direct digit rule at the top. It should not cause any problems correct? because you are specifying that this rule should get triggered when the number starts with a 1 and has 11 digits long. you have no other conflict except the 888-889 ~ 1 ~ 11 digits long.

    does this work in this case?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  9. carolinainnovative

    Joined:
    May 4, 2009
    Messages:
    369
    Likes Received:
    6
    Eh - the range was 888-899 not 889 - but I went ahead and changed it to 888,889 to test... Same effect.

    Yes that works - however, my outbound faxes from 888-899 will then hit THAT rule instead of the rule specifically for those extensions. As it is always said - first match not best match.

    I guess my question is - why does "IVRForward" match an extension number at all?

    Thanks for working with me on this Nicky!

    Chavous
     
  10. nb

    nb Support Team
    Staff Member 3CX Support

    Joined:
    Jun 7, 2007
    Messages:
    2,129
    Likes Received:
    152
    Sorry about the 888-889 - I guess Im seeing blurred right now :)

    The problem is this. yes we implement first match not best match to speed up the routing. All the rules must be loaded, processed and outbound route build in less than a split second. If you a lot of rules, you cannot do this in such a short time.

    The call is made by IVR FORWARD - this is the service that makes the call.
    now IVR forward matches everything except what you put in the RANGE OF EXTENTIONS. So for IVRFORWRD having 888 there or any other digit, but the remaining 2 factors work, then it will pass through that.
    What you can do is put a destination for this rule.
    Therefore it is matching 888-899-1-11 (FORWARD TO NOTHING) rule because it has a match of 1 prefix and 11 digit length. This is why your calls fail.

    Do the following - leave the rules exactly as they are in this screenshot and change the length of the 888-899 - 1 - 11 rule to 12 and see if this works.

    In the meantime we will see what we can do for rebound rules. maybe we can make it sensitive to CALL FROM EXTENSIONS section.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  11. nb

    nb Support Team
    Staff Member 3CX Support

    Joined:
    Jun 7, 2007
    Messages:
    2,129
    Likes Received:
    152
    OK BUG - confirmed. Thanks for your feedback.

    the bug is in the Extension 888-889 rule.

    If this bug is fixed, you can put the *11 rule first before the 888-899 rule and everything will be ok. IVR forward will pass from the first and Fax extensions will parse the range of extensions and pass from the appropriate rules.

    thanks for investigating too!!
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  12. nb

    nb Support Team
    Staff Member 3CX Support

    Joined:
    Jun 7, 2007
    Messages:
    2,129
    Likes Received:
    152
    Solution: What if in the *11 rule you make the following:
    Calls from extensions 100-887 (for example) or put all your extensions that you allow out.
    Put this rule first before
    IVR FORWARD Will use this rule because it matches it first since it is not sensitive to Calls from extensions.

    Then put the 888-899 rule behind it.

    Does this give you what you need?

    best match will produce a performance hit - we will see what we can do on this - subject to discussion.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  13. carolinainnovative

    Joined:
    May 4, 2009
    Messages:
    369
    Likes Received:
    6

    This should work for now. THanks! RE best match - I agree re performance hit. How about instead have IVRForward actually act like an extension in outbound rules? Either have it such that it doesn't match any extension pattern or give it a system extension OR let us specify "IVRForward" in the extension list for an outbound rule?

    I would think that any call that traverses the system and is going OUT should be subject to all of the whims of outbound rules - including extension restrictions... but thats just me. :)

    Thanks again,

    Chavous
     
Thread Status:
Not open for further replies.