OCS identify outgoing user

[Markus Oestreicher]

We have set up the integration with OCS using the Wiki page. Basically everything works fine.

 

I want to have different dial plans for different users for outgoing calls from OCS.

 

While setting up you have to set "Assume that call comes from user" to one of your extensions. This way all outgoing calls from OCS will have this user as caller-id and will use the same dial plan.

 

How should the trunk be configured that it can identify the extension on its own?

 

The calls from OCS seem to come from +xxx@<fqdn-of-mediation-server>. I need to map xxx to a local extension.

 

Thanks!

 

Markus

[Markus Oestreicher]

Can you give me some advice on this?

 

Do you need more information about the setup?

[Vodia PBX]

We have set up the integration with OCS using the Wiki page. Basically everything works fine.

 

I want to have different dial plans for different users for outgoing calls from OCS.

 

You can assign dial plans on per-extension basis. Is that the problem?

 

While setting up you have to set "Assume that call comes from user" to one of your extensions. This way all outgoing calls from OCS will have this user as caller-id and will use the same dial plan.

 

How should the trunk be configured that it can identify the extension on its own?

 

Well, the problem for the PBX is that the call comes in on a trunk and it goes out on a trunk. Someone needs to pay the bill... (and that extension dial plan is being used). Not sure how this problem can be solved in another way.

 

The calls from OCS seem to come from +xxx@<fqdn-of-mediation-server>. I need to map xxx to a local extension.

 

What about a tel:-alias? Does that solve the problem.

[Markus Oestreicher]

"Alias" was the right keyword. I have solved it using two things:

 

1. OCS uses E.164 format, so I added +900 as an Alias for extension 900

 

2. I have added the FQDN of the mediation server as an Alias for the SIP domain. This way an incoming OCS call with header "From: +900@<fqdn-of-ocs-med>" will be accounted to the local extension 900.

 

Now I have different Dial Plans dependant on the OCS user calling.

 

@pbxnsip: Can step 2 lead to unexpected problems I don't see currently?

 

Thanks

Markus

[Vodia PBX]

@pbxnsip: Can step 2 lead to unexpected problems I don't see currently?

 

No that's fine.

[coffee]

that sounds good, I exactly searched for that way.

But how do you call internal hunt groups from OCS user. In my configuration it allways looks for an outgoing trunk, even if I call a 4digit internal number.

I then implemented every 4digit in the dial plan as direkt extension call, but that does not work for hunt groups

Regards

Daniel

[Vodia PBX]

that sounds good, I exactly searched for that way.

But how do you call internal hunt groups from OCS user. In my configuration it allways looks for an outgoing trunk, even if I call a 4digit internal number.

I then implemented every 4digit in the dial plan as direkt extension call, but that does not work for hunt groups

 

Maybe you should reserve special prefix for hunt groups, extensions etc and then split it up in the dial plan.

 

The dangerous thing here are loops, make sure that such groups do not end up in endless call loops between OCS and the PBX. Those are really hard to deal with and instanteneously create the maximum number of allowed calls. Call it DoS if you want...

[coffee]

Maybe you should reserve special prefix for hunt groups, extensions etc and then split it up in the dial plan.

 

Can you give me an example for that?

the problem is, that in the dial plan I don't have the chance to set a hunt group as goal. I only can set extensions for direkt call, but pbxnsip don't accept a hunt group number as goal for direct extension call. I don't see a way, to tell him, if you get a call from OCS to 555 forward it to hunt group 555, it always goes to trunk xyz 555.

[Vodia PBX]

Can you give me an example for that?

the problem is, that in the dial plan I don't have the chance to set a hunt group as goal. I only can set extensions for direkt call, but pbxnsip don't accept a hunt group number as goal for direct extension call. I don't see a way, to tell him, if you get a call from OCS to 555 forward it to hunt group 555, it always goes to trunk xyz 555.

 

Okay, got it. That will be indeed difficult/impossible.

 

Hmm. The alternative could be to define a pattern in the trunk that tries to send the call to a hunt group, and if that fails it uses the dialplan. I am thinking about a pattern like this:

 

!555!555! ![0-9]*!\1!

 

Not sure if it really works, just a wild offline idea.

[Markus Oestreicher]

I need to re-open this topic with a new issue:

 

After implementing the two steps above, identifying the outgoing user works.

 

The only downside is, call forwarding does not work.

 

When the call is forwarded, pbxnsip receives the following request:

 

INVITE sip:forwarding-destination@pbxnsip;user=phone SIP/2.0

FROM: <sip:original-caller-id@ocs.domain;user=phone>;epid=68F4D0A0C6;tag=885932eb2

TO: <sip:forwarding-destination@pbxnsip;user=phone>

 

The problem lies in the From: field. It contains the original caller's number, so the user is not recognized locally:

 

[5] 2009/02/13 19:30:36: Trunk call: Could not identify user

 

Could you implement a feature like "Try to identify user, otherwise assume that call comes from user:" for this case?

 

bye

Markus

[pbx support]

Check out http://wiki.pbxnsip.com/index.php/Inbound_...s_the_extension and see that helps.

 

I need to re-open this topic with a new issue:

 

After implementing the two steps above, identifying the outgoing user works.

 

The only downside is, call forwarding does not work.

 

When the call is forwarded, pbxnsip receives the following request:

 

INVITE sip:forwarding-destination@pbxnsip;user=phone SIP/2.0

FROM: <sip:original-caller-id@ocs.domain;user=phone>;epid=68F4D0A0C6;tag=885932eb2

TO: <sip:forwarding-destination@pbxnsip;user=phone>

 

The problem lies in the From: field. It contains the original caller's number, so the user is not recognized locally:

 

[5] 2009/02/13 19:30:36: Trunk call: Could not identify user

 

Could you implement a feature like "Try to identify user, otherwise assume that call comes from user:" for this case?

 

bye

Markus

[hosted]

I need to re-open this topic with a new issue:

 

After implementing the two steps above, identifying the outgoing user works.

 

The only downside is, call forwarding does not work.

 

When the call is forwarded, pbxnsip receives the following request:

 

 

make sure you have a valid extension in the trunk field: Assume that call comes from user:

[Markus Oestreicher]

Check out http://wiki.pbxnsip.com/index.php/Inbound_...s_the_extension and see that helps.

 

The problem here is identifying the sender:

 

I have a trunk OCS->pbxnsip

 

In OCS there are different users. Each user has an extension with the same name on pbxnsip.

 

"Assume that call comes from user" is set to a fixed extension, all calls are accounted to the same user. However, I need different Dial Plans per User so I need to identfy the sending user.

 

Leaving "Assume that call comes from user" empty, pbxnsip can recognize "From: user-extension@mediation-server" as local extension and works properly (old problem solved, see above)

 

When call forwarding comes into play, OCS sends a "From: external-number@mediation-server" header. The numbers are completly random... For these numbers there is no local extensions, therefore error "Could not identify user"

 

For this to work, I need a behaviour:

 

if "From:" matches a known extension use this one, else "Assume that calls come from fixed extension xyz"

 

Do you have any idea?

 

Markus