Hello,
I have three PSTN (BRI/ISDN2) lines and one Siemens Gigaset 3070 connected directly to DMG4008BRI. And have OCS Mediation Server on top of DMG4008BRI.
I am configured Dual Forking for Test user: Enabled PBX Integration and set same number in Line URI for that user and same for one Gigaset handset. And DMG4008BRI routes this number from PSTN to OCS.
When I making call from Office Communicator (from other user) to configured number, Test user receives ring on both Office Communicator and on handset.
But when i place i call from PSTN, then ringing only on Office Communicator.
How can enable dual forking, when calling from PSTN, always managed by OCS?
Currently you will need to setup Communicator for simultaneous ring. In this case you can define another telephone number to dial and Communicator will make an outbound call. If you put in a number so that OCS routes the call to the DMG you can create a rule in the DMG to route the call to the Gigaset. You have quite a complex setup so be careful that you don't get calls going around in circles though..
In a future release of the DMG4000 we will support multiple ring/forking so the DMG will be able to be configured to call multiple destinations simultaneously. This will be a software upgrade and is due for release in Q2.
Vic,
This is somewhat related so rather than open a new thread i am postin here:
We have OCS 2007 R2 with a DMG4060 tied QSIG to our PBX then PRI's to PSTN.
Sim ring/redirect works through MOC with internal extensions (on the PBX or OCS), however sim ring/redirect fails to external (out of PBX).
I feel confident that the address map isnt processes and prepending the 9. It will work if i sim ring a 9XXX-XXXX number.
Any ideas???
Thanks,
Can you post a trace and also describe your address maps etc so we can see what is happening ?
Set SIPControl tracing to extended in SIPC/System configuration,
Run Start/Programs/Diva Server for Windows/Diva Server Diagnostic tool.
Click on the pictures of the cards in the left panel, then click on the B (for basic) button in the toolbar for each card. Now click on the red circle button to start trace, click on red X to clear trace.
Now make the call attempt.
After the failure go back to the Diva Server diagnostic tool and click on the black square button to stop the trace, then click on the 'eye' button to open the trace. Save the trace and attach it here using the Options tab.
Here are the traces that i did earlier:
Successful call from 3279 to 3476 Sim ringing 8476
Failed call *3476 (pbx) to 3476 (OCS) sim ringing 7693279
Sounds wierd i know, but the NEC PBX knows 3476 is the OCS and NEC is basically spoofing the called from address. Same happens for unique extensions.
As for the address maps. I have quite a few, to manipulate outbound DIDs if the internal extension has a DID.
The one in question is probably '4DIgits' which is:
Called address exp: ^(\d{4})
Called Addre Format: $1
Calling Address Exp: ^[NS\+]?
Rest is blank.
THANK IN ADVANCE!
The call is processed by 4Digits as you said
Apply rule "4Digits" (Called "7693279@10.1.1.51"->"7693279@10.1.1.51", Calling "3476;phone-context=OCSDialPlan.wakm.com@wakm.com>"->"3476;phone-context=OCSDialPlan.wakm.com@wakm.com>", 1st Redirect ->)
Then is sent out of the same ISDN line the original call came on (I assume that this is the PBX?) with called and calling numbers 7693279 and 3476.
Then the call is rejected with 'Incompatible destination'
I assume from your first post that this call will need to be prepended with a 9 for an outside line, which would explain the reason why the call is rejected.
Can just create a rule that will prepend the 9 ? If you need to distinguish between 4 digit calls and these calls with more numbers you can refine the 4digit rule to ^(\d{4})(@.*) so it only matches calls with 4 digits in the Invite and add a specific rule to match the external numebrs and prepend a 9.
That is correct. Only it doesnt look like it is processing the rules for the second (simultaneous ring) call. I did as you suggested and changed the 4 digit rule. The external calls already have rules based on the number of digits dialed (7,10, etc) they just dont appear to get picked up for the simultaneous ring calls.
I can't see the syntax of all your rules but they do appear to be being processed as in the trace you can see the 4Digits rule being applied. If this is the incorrect rule to be processed (which I assume it is as its not prepending a 9) then you should look at your rule syntax to make sure it is working as you require. As a simplified example. if you have two call types from SIP to ISDN, some with 4 digit that should remain unaltered and some with 7 digits that need a 9 prepended you could have something like this :
Address map CPN_digit.
Rule 1, 4Digit
^(\d{4})(@.*)
$1
Rule 2, 7 digit
^(\d{7})(@.*)
9$1
So this will match nnnn@IP_addresss and pass it unchanged and nnnnnnn@IP_addresss and pass 9nnnnnnn.
Sorry Vic, may need clarification, is this a seperate map containing only two rules or should these replace the existing. I tried that but it didnt work.
Interesting you say the trace is being applied because i just stumbled onto this scenario if MOC calls a MOC sim ring to a PSTN works, so i was thinking it was not processing becuase the (same call leg error). I will explain.
NEC Extension:3279 DID:769-3279
MOC extension: 4620 NO DID
Annother MOC extension:3476 DID 769-3476
Another NEC extension 8476 NO DID
Cell phone 240-1558
3476 -> 4620 sim ring to 240-1558 works.
8476->4620 sim ring to 2401558 doesnt work
*Attached is a detail of our address maps
Hope that helps.
THANK YOU FOR ALL YOUR HELP.
I think its a fairly straightforward issue. In the traces you sent you had two calls, working and non-working. The only difference between the calls is that the working call had 4 digit cpn, the non-working call had 7 digit cpn, otherwise the Invites from OCS are identical.
Both calls are processed and note the critical point is that both calls go through the '4digit' address map. This map doesn't do anything to the cpn so the 4 digit number comes through as 4 digits and the 7 digit as 7 digits.
Both calls go onto ISDN and the 7 digit call is rejected, the assumption being that is has no prepended 9 so the PBX rejects it.
So it seems the problem is that the 7digit rule conditions are not met so that rule is passed over and eventually the 4digit rule conditions are met so that rule is used. The reason that the 7digit rule is not used is I assume because the calling expression ^3(\d{3})@DMG4060.wakm.com does not match the calling string 3476;phone-context=OCSDialPlan.wakm.com@wakm.com.
So in general terms its worth checking your rules and making sure they are more explicit, ie ^(\d{4}) will match any number of 4 or more than 4 digits as you have not 'terminated' the expression, eg ^(\d{4})$ will only match 4 digits, or as this is a SIP call you need ^(\d{4})(@.*)
So my point was that if you want to distinguish between 4 digit and 7 digit cpn you could modify your existing 4 and 7 digit rules to use the more specific syntax to make sure that 7 digits calls are processed by the 7digit rule and the 9 prepended, and also remove/modify the calling party expression to make sure it matches the calls.
Thank you for your patience and taking the time to dumb down your answer for me. :)
You probably answered this higher in the thread, but i got what you meant and was able to insert a rule that fixed my issue.
Thhnks again!
No probs, we are here to help :-) Good to hear its working now.
