Rebound not working

[carolinainnovative]

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

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:[email protected]: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:[email protected]:5060]
18:31:22.021  [CM503002]: Call(30): Alerting sip:[email protected]:40600;rinstance=9f9a7143963eb399
18:31:21.858  [CM503025]: Call(30): Calling Ext:Ext.999@[Dev:sip:[email protected]:40600;rinstance=9f9a7143963eb399]
18:31:21.800  [CM503004]: Call(30): Route 1: Ext:Ext.999@[Dev:sip:[email protected]:40600;rinstance=9f9a7143963eb399]
18:31:21.799  [CM503010]: Making route(s) to <sip:[email protected]:5060;user=vmail>
18:31:21.795  Refer: from="1aaaaaaaaaa"<sip:[email protected]:5060>;tag=bd5e2567; to="WIRELESS CALLER"<sip:[email protected]:5060>;tag=ae63c105; RefTo=<sip:[email protected]: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:[email protected]:5060> failed. Reason: Not Registered
18:31:21.170  [CM503016]: Call(31): Attempt to reach <sip:[email protected]: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:[email protected]: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:[email protected]:5060]
18:31:21.121  [CM503001]: Call(31): Incoming call from Ext.IVRForward to <sip:[email protected]:5060>
18:31:21.112  [CM500002]: Info on incoming INVITE:
  INVITE sip:[email protected]: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:[email protected]:40600;rinstance=9d05019878bb7bf3>
  To: <sip:[email protected]:5060>
  From: "IVRForward"<sip:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]:5060]
18:31:12.598  [CM503002]: Call(30): Alerting sip:[email protected]:40600;rinstance=9d05019878bb7bf3
18:31:12.507  [CM503003]: Call(30): Call to sip:[email protected]:5060 has failed; Cause: 487 Request Terminated; from IP:68.156.94.252:36358
18:31:12.385  [CM503003]: Call(30): Call to sip:[email protected] 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:[email protected]:40600;rinstance=9d05019878bb7bf3]
18:31:12.319  [CM503005]: Call(30): Forwarding: Ext:Ext.IVRForward@[Dev:sip:[email protected]: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:[email protected]:5060]
18:30:54.448  [CM503002]: Call(30): Alerting sip:[email protected]:36358;rinstance=9c59c19afeda0ce2
18:30:54.234  [CM503025]: Call(30): Calling Ext:Ext.101@[Dev:sip:[email protected]:36358;rinstance=9c59c19afeda0ce2]
18:30:54.222  [CM503025]: Call(30): Calling Ext:Ext.101@[Dev:sip:[email protected]:5060]
18:30:54.166  [CM503004]: Call(30): Route 1: Ext:Ext.101@[Dev:sip:[email protected]:5060,Dev:sip:[email protected]:36358;rinstance=9c59c19afeda0ce2]
18:30:54.162  [CM503010]: Making route(s) to <sip:[email protected]:5060>
18:30:54.158  Refer: from=<sip:[email protected]:5060>;tag=184cc211; to="WIRELESS CALLER"<sip:[email protected]:5060>;tag=b2646d11; RefTo=<sip:[email protected]: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:[email protected]:40600;rinstance=cce340fb53b5631a
18:30:44.647  [CM503007]: Call(30): Device joined: sip:[email protected]: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:[email protected]:5060]
18:30:44.617  [CM503002]: Call(30): Alerting sip:[email protected]:40600;rinstance=cce340fb53b5631a
18:30:44.477  [CM503025]: Call(30): Calling Ext:Ext.800@[Dev:sip:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]:5060]
18:30:44.426  [CM503001]: Call(30): Incoming call from +1xxxxxxxxxx@(Ln.10000@nexVortex Inbound/Outbound) to <sip:[email protected]: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:[email protected] 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:[email protected]:5060;nat=yes;ftag=gK077bada8;lr=on>
  Contact: "WIRELESS CALLER"<sip:[email protected]:5060>
  To: <sip:[email protected]:5060>
  From: "WIRELESS CALLER"<sip:[email protected]:5060>;tag=gK077bada8
  Call-ID: [email protected]
  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:[email protected]:5060>;privacy=off

 

[nb]

Can you make a wireshark capture and send it?
Can you also send a backup of your system? [email protected]

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

 

[carolinainnovative]

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

 

[nb]

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%

 

[carolinainnovative]

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)

 

[nb]

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.

 

[carolinainnovative]

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.

 

[nb]

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?

 

[carolinainnovative]

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.

Eh - the range was 888-899 not 889 - but I went ahead and changed it to 888,889 to test... Same effect.

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.

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

 

[nb]

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.

 

[nb]

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!!

 

[nb]

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.

 

[carolinainnovative]

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.

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