Exchange VoiceMail caller-ID

[HappyUser]

Hello,

 

I have upgraded my pbxnsip server to version 2.1 and now when a call is send from pbxnsip to my Exchange 2007 voice mail I only see the extension number.

 

Ill use budgetphone as my phone provider and the phonenumer of the caller is visible on my phone like normal.

 

So the phone number of the caller is not passing to Exchange 2007. Exchange is reporting the phone extension/name instead.

 

The voicemail it self etc works fine but how can I Fix this problem?

 

Thanks,

Charl

[Vodia PBX]

Hmm. Maybe that problem is related to the reason for the transfer provided in the Divert header? What does the PBX say in the SIP packet sent to the Exchange?

[HappyUser]

Hmm. Maybe that problem is related to the reason for the transfer provided in the Divert header? What does the PBX say in the SIP packet sent to the Exchange?

 

this is the log

 

[5] 2007/10/16 22:26:59: Identify trunk (IP address/port and domain match) 2

[5] 2007/10/16 22:26:59: Trunk Linksys sends call to 900

[5] 2007/10/16 22:27:20: Dialplan: Match 777777@10.16.3.5 to <sip:777@10.16.3.39;user=phone> on trunk Exchange

[5] 2007/10/16 22:27:20: Using <sip:<number of caller>@10.16.3.5>;tag=a2b11b4584f9f748o1 as redirect from

[5] 2007/10/16 22:27:20: Charge user 900 for redirecting calls

[5] 2007/10/16 22:27:20: Opening a new connection

[5] 2007/10/16 22:27:20: Redirecting call

[5] 2007/10/16 22:27:20: Opening a new connection

[5] 2007/10/16 22:27:20: Connection refused on udp:10.16.3.39:5060

[5] 2007/10/16 22:27:27: BYE Response: Terminate d276578b@pbx

[5] 2007/10/16 22:27:43: SIP port accept from 10.16.3.39:1483

 

 

number 900 is my test extension

number 777777 is the numer of the exchange server, the dailplan change this to 777

[Valerio]

Hi,

please check the Exchange trunk if you're using TCP transport and set Remote Party/Privacy Indication to RFC3325 (P-Asserted-identity).

 

Hope this helps.

 

Valerio

[HappyUser]

Hi,

please check the Exchange trunk if you're using TCP transport and set Remote Party/Privacy Indication to RFC3325 (P-Asserted-identity).

 

Hope this helps.

 

Valerio

 

Thanks for this tip, it works perfectly.

This is also a good tip for de wiki site I think

 

http://wiki.pbxnsip.com/index.php/Microsoft_Exchange

Section: Configuring the pbxnsip Server for Exchange.

 

1. Create a new trunk to connect to Exchange: Using the pbxnsip Domain Administrator, select the Trunks tab. Name the new trunk "exchange gateway" and set its type to SIP Gateway. Click the create button. Click the edit icon next to the Exchange Gateway. In the Domain box, enter the FQDN or IP Address of your Exchange Server (i.e., exchange.company.com). In the outbound proxy box, enter: sip:exchange.company.com:5060;transport=tcp but replace exchange.company.com with the FQDN or IP Address of your Exchange Server and set Remote Party/Privacy Indication to RFC3325 (P-Asserted-identity).

The example below assumes the address is 100.200.100.200. Click the "Accept redirect" radio button and then click save.

Screenshot needs an update

[phsean]

Having the exact same problem here since a 2.1 upgrade, but the Assert-Identity toggle doesn't fix the problem, surprisingly (tried all five Remote Party/Privacy Indication settings, but no effect...).

 

I ran a call log and stripped out my test call: Log File

 

What's happening in the log: 2503 calls 2412, 2412 rejects call, 2503 receives "2412 is busy" message, hits 2 to leave a voicemail, and does so. (Exchange UM is running on port 5060 and PBXnSIP is running on the same machine, 192.168.11.4, port 5070)

 

Starting with Line 234, the From header changes from the calling extension 2503 to the recipient extension 2412 when the call is referred to the unified messaging server... why that translation takes place looks like the problem.

 

I have been doing some testing using a clean 2.1 install on a separate machine with a demo key, set up two test users with a completely new (3-digit) dial plan on the same Exchange server, used X-Lite to test, and the problem exists on the test server as well.

 

They've been patient, but the natives are getting restless... thanks for the help!

[Vodia PBX]

Well, this is the dust cloud around the caller-ID presentation when doing an external call.

 

It looks like it would be a good idea to use the original number also when the call gets diverted (even if internally). If you like, please try the following build (raw executable): http://www.pbxnsip.com/download/pbxctrl-2.2.0.2415.exe.

[phsean]

Well, this is the dust cloud around the caller-ID presentation when doing an external call.

 

Yessir. Put the new build on, and now toggling the Remote Party/Privacy Indication on the Exchange trunk to Asserted Identity has the bugger resolved.

 

What a great way to wind up the day... thanks!

[Valerio]

hi,

can you share what features are planned for 2.2 release ? anything on integration with ocs ?

 

maybe these two links can give ideas.....

 

http://www.microsoft.com/downloads/details...;displaylang=en

 

http://www.microsoft.com/downloads/details...;displaylang=en

 

let me know if I can be of any help..

[Alex Kasperavicius]

Had the same problem and setting Remote Party/Privacy Indication to RFC3325 (P-Asserted-identity) fixed the problem. Note this is not mentioned in the Wiki instructions for setup of Exchange interoperability.

 

Might you guys consider opening up your wiki to registered users? I mean, some of it is pretty sparse and I for one would be happy to add little corrections here and there. It certainly would be easier for you guys to monitor additions than having to type all that stuff yourself. I think you would be pleasantly surprised.

 

AK

[pbx support]

Had the same problem and setting Remote Party/Privacy Indication to RFC3325 (P-Asserted-identity) fixed the problem. Note this is not mentioned in the Wiki instructions for setup of Exchange interoperability.

 

Might you guys consider opening up your wiki to registered users? I mean, some of it is pretty sparse and I for one would be happy to add little corrections here and there. It certainly would be easier for you guys to monitor additions than having to type all that stuff yourself. I think you would be pleasantly surprised.

 

AK

 

Alex, Could you please PM to support@pbxnsip.com on this? thanks