Jump to content

OCS identify outgoing user


Markus Oestreicher
 Share

Recommended Posts

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

Link to comment
Share on other sites

  • 2 weeks later...
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.

Link to comment
Share on other sites

"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

Link to comment
Share on other sites

  • 1 month later...

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 5 months later...

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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:

Link to comment
Share on other sites

 

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...