Jump to content

Exchange 2007


Model12

Recommended Posts

Hope you don't mind a long post!

 

Once a call is transferred from PBXnSIP to Exchange ... it might be nice to transfer it back at some point.

 

I can do that but every time PBXnSIP tells me audio_en/ex_permission.wav ...

 

It is transferring from an ext# 8002 on the ExchangeServer which is not valid on the PBXnSIP box (actually I made an 8002 ext just incase but it didn't help) to 2502 which is a valid ext.

 

After I get the message that I don't have perms ... it asks if I want to use a diff ext#.

 

I can tell it I want to use a diff ext# and enter my PIN# and it'll actually let me dial out (and tells me to push # when I'm done) but won't let me dial just an ext#.

 

I'm not sure what's up ...

 

I have a log capture showing the event unfolding ...

 

Anywhere you see apollo.test.com the IP = 192.168.11.4 and viceversa ... that is the Exchange server

 

Anywhere you see pbx.test.com the IP = 192.168.11.5 and viceversa ... that is the PBXnSIP server

 

Anywhere you see the IP = 192.168.10.106 ... that's the phone

 

***

 

I read the bit about "How the PBX identifies the trunk" but how can you tell in the log file which trunk it thinks it is using?

 

If you can glean any info from these log entries ... any help would be greatly appreciated!

 

PS: apollo.test.com and pbx.test.com do resolve to the proper private IPs listed on our test server

 

[7] 2007/06/27 14:17:20: SIP Rx tcp:192.168.11.4:5065:

REFER sip:2502@192.168.11.5:5060;transport=tcp SIP/2.0

FROM: <sip:8002@apollo.test.com;user=phone>;epid=C1-FB-4C-98-B4;tag=68e0d24c7f

TO: <sip:2502@apollo.test.com>;tag=22017

CSEQ: 1 REFER

CALL-ID: 5e333c44@pbx

MAX-FORWARDS: 70

VIA: SIP/2.0/TCP 192.168.11.4:5065;branch=z9hG4bK5d77c932

CONTACT: <sip:apollo.test.com:5065;transport=Tcp;maddr=192.168.11.4>

CONTENT-LENGTH: 0

REFER-TO: <sip:2502@192.168.11.5:5060;transport=tcp;user=phone>

USER-AGENT: RTCC/2.0.6017.0

Referred-By: sip:8002@apollo.test.com;user=phone

 

 

[8] 2007/06/27 14:17:20: Resolve destination 2203: tcp 192.168.11.4 5065

[8] 2007/06/27 14:17:20: Send Packet 202

[7] 2007/06/27 14:17:20: SIP Tx tcp:192.168.11.4:5065:

SIP/2.0 202 Accepted

Via: SIP/2.0/TCP 192.168.11.4:5065;branch=z9hG4bK5d77c932

From: <sip:8002@apollo.test.com;user=phone>;epid=C1-FB-4C-98-B4;tag=68e0d24c7f

To: <sip:2502@apollo.test.com>;tag=22017

Call-ID: 5e333c44@pbx

CSeq: 1 REFER

Contact: <sip:2502@192.168.11.5:5060;transport=tcp>

User-Agent: pbxnsip-PBX/2.0.3.1715

Content-Length: 0

 

 

[5] 2007/06/27 14:17:20: Redirecting call to 2502

[8] 2007/06/27 14:17:20: Resolve destination 2204: a Tcp 192.168.11.4 5065

[8] 2007/06/27 14:17:20: Resolve destination 2204: Tcp 192.168.11.4 5065

[8] 2007/06/27 14:17:20: Send Packet BYE

[7] 2007/06/27 14:17:20: SIP Tx tcp:192.168.11.4:5065:

BYE sip:apollo.test.com:5065;transport=Tcp;maddr=192.168.11.4 SIP/2.0

Via: SIP/2.0/TCP 192.168.11.5:5060;branch=z9hG4bK-4a1059d8db06faa2122a27c1235fc72f;rport

From: "Test User" <sip:2502@apollo.test.com>;tag=22017

To: <sip:8002@apollo.test.com;user=phone>;tag=68e0d24c7f

Call-ID: 5e333c44@pbx

CSeq: 15517 BYE

Max-Forwards: 70

Contact: <sip:2502@192.168.11.5:5060;transport=tcp>

RTP-RxStat: Dur=19,Pkt=628,Oct=108016,Underun=18

RTP-TxStat: Dur=18,Pkt=914,Oct=156116

Content-Length: 0

 

 

[8] 2007/06/27 14:17:20: Play audio_en/ex_permission.wav

[7] 2007/06/27 14:17:20: SIP Rx tcp:192.168.11.4:5065:

SIP/2.0 200 OK

FROM: "Test User"<sip:2502@apollo.test.com>;tag=22017

TO: <sip:8002@apollo.test.com;user=phone>;tag=68e0d24c7f;epid=C1-FB-4C-98-B4

CSEQ: 15517 BYE

CALL-ID: 5e333c44@pbx

MAX-FORWARDS: 70

VIA: SIP/2.0/TCP 192.168.11.5:5060;branch=z9hG4bK-4a1059d8db06faa2122a27c1235fc72f;rport

CONTENT-LENGTH: 0

SERVER: RTCC/2.0.6017.0

 

 

[5] 2007/06/27 14:17:20: BYE Response: Terminate 5e333c44@pbx

[7] 2007/06/27 14:17:20: Other Ports: 1

[7] 2007/06/27 14:17:20: Call Port: cbd543da-aa44bd0d-e66441b8@192.168.10.106#7e9372ddb6

[8] 2007/06/27 14:17:23: UDP: recvfrom receives ICMP message

[7] 2007/06/27 14:17:23: SIP Rx udp:192.168.10.106:5060:

BYE sip:88002@192.168.11.5:5060;transport=udp SIP/2.0

Via: SIP/2.0/UDP 192.168.10.106;branch=z9hG4bK9ef929f07D8BC593

From: "Test User" <sip:2502@pbx.test.com>;tag=B33CA89B-99603676

To: <sip:88002@pbx.test.com;user=phone>;tag=7e9372ddb6

CSeq: 3 BYE

Call-ID: cbd543da-aa44bd0d-e66441b8@192.168.10.106

Contact: <sip:2502@192.168.10.106>

User-Agent: PolycomSoundPointIP-SPIP_430-UA/2.1.0.2708

Max-Forwards: 70

Content-Length: 0

 

 

[8] 2007/06/27 14:17:23: Resolve destination 2205: a udp 192.168.10.106 5060

[8] 2007/06/27 14:17:23: Resolve destination 2205: udp 192.168.10.106 5060

[8] 2007/06/27 14:17:23: Send Packet 200

[7] 2007/06/27 14:17:23: SIP Tx udp:192.168.10.106:5060:

SIP/2.0 200 Ok

Via: SIP/2.0/UDP 192.168.10.106;branch=z9hG4bK9ef929f07D8BC593

From: "Test User" <sip:2502@pbx.test.com>;tag=B33CA89B-99603676

To: <sip:88002@pbx.test.com;user=phone>;tag=7e9372ddb6

Call-ID: cbd543da-aa44bd0d-e66441b8@192.168.10.106

CSeq: 3 BYE

Contact: <sip:88002@192.168.11.5:5060;transport=udp>

User-Agent: pbxnsip-PBX/2.0.3.1715

RTP-RxStat: Dur=22,Pkt=1068,Oct=182604,Underun=590

RTP-TxStat: Dur=21,Pkt=790,Oct=135880

Content-Length: 0

 

 

[8] 2007/06/27 14:17:23: Resolve destination 2206: url sip:2502@192.168.10.106

[8] 2007/06/27 14:17:23: Resolve destination 2206: udp 192.168.10.106 5060

[8] 2007/06/27 14:17:23: Send Packet NOTIFY

[7] 2007/06/27 14:17:23: SIP Tx udp:192.168.10.106:5060:

NOTIFY sip:2502@192.168.10.106 SIP/2.0

Via: SIP/2.0/UDP 192.168.11.5:5060;branch=z9hG4bK-d99bd20584c988d989912af2f4291624;rport

From: <sip:2502@pbx.test.com>;tag=69d97dcb93

To: "Test User" <sip:2502@pbx.test.com>;tag=73C94BE-E7463B91

Call-ID: 20735995-bd184780-3bc6a9a3@192.168.10.106

CSeq: 29923 NOTIFY

Max-Forwards: 70

Contact: <sip:192.168.11.5:5060;transport=udp>

Event: dialog

Subscription-State: active;expires=109

Content-Type: application/dialog-info+xml

Content-Length: 152

 

<?xml version="1.0"?>

<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="56" state="full" entity="sip:2502@pbx.test.com"></dialog-info>

 

[7] 2007/06/27 14:17:23: SIP Rx udp:192.168.10.106:5060:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.168.11.5:5060;branch=z9hG4bK-d99bd20584c988d989912af2f4291624;rport

From: <sip:2502@pbx.test.com>;tag=69d97dcb93

To: "Test User" <sip:2502@pbx.test.com>;tag=73C94BE-E7463B91

CSeq: 29923 NOTIFY

Call-ID: 20735995-bd184780-3bc6a9a3@192.168.10.106

Contact: <sip:2502@192.168.10.106>

Event: dialog

User-Agent: PolycomSoundPointIP-SPIP_430-UA/2.1.0.2708

Content-Length: 0

Link to comment
Share on other sites

Yea, that is kind of frequently asked question about Exchange. Be sure to have "Accept Redirect" turned on on the trunk.

 

The problem here is that the PBX does not know what account to charge for the call and what dial plan to use. The charging works if the call got redirected to Exchange e.g. as a mailbox redirection. Do you have a default dial plan for the domain? Does that extension has the right to place such an outbound call?

Link to comment
Share on other sites

We do have accept redirects turned on ... I followed the Exchange setup in the Wiki.

 

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

 

The only diff is that I'm using 8$u instead of 7$u ...

 

All I really want is for folks that are "in" the Exchange server to be able to transfer to an ext on the PBXnSIP server ... not necessarily make an outbound call.

 

I don't really understand how it supposed to happen so I don't even know if the SIP REFER I see leading the log file entries above is what should be taking place.

 

And ... because I do have Accept Redirects enabled on that trunk makes me wonder if PBXnSIP really thinks that is the trunk it should be using.

 

The only other trunk I have is for the PRI and it has no entry in the Domain field which may cause PBXnSIP to pick that trunk instead during an Exchange transfer ...

 

I dunno how to debug it well enough to tell what's really happening.

 

Is there anyway to tell which trunk PBXnSIP thinks the call is coming from?

 

According to the rules here: http://wiki.pbxnsip.com/index.php/Inbound_Calls_on_Trunk

 

I would think the line: FROM: <sip:8002@apollo.test.com;user=phone>;epid=C1-FB-4C-98-B4;tag=68e0d24c7f would cause PBXnSIP to realize it is from the Exchange server and to utilize that trunk.

 

Both trunks I have are marked as SIP Gateways ... I'm not even sure I understand what a SIP Registration trunk is but it doesn't sound like what I'd need.

 

Thanks for the help!

Link to comment
Share on other sites

The only diff is that I'm using 8$u instead of 7$u ...

That might conflict with the direct mailbox prefix, which is also 8 by default.

 

All I really want is for folks that are "in" the Exchange server to be able to transfer to an ext on the PBXnSIP server ... not necessarily make an outbound call.

 

Maybe that's the problem. Does a transfer to an external number work?

 

The REFER looks fine to me - it is just that the dial plan seems not to be able to send the call to something useful. Maybe you can use the feature of the dial plan to sed a call to an extension. Also, the trunk identification should be fine - as the PBX initiated the call it does know that this Call-ID belongs to the Exchange trunk.

Link to comment
Share on other sites

You are 100% correct.

 

This was/is a dial plan issue.

 

Being a programmer of some sorts I would think that understanding dial plans both simple and regular expressions should be a breeze.

 

But ... guess what ... I am having trouble.

 

Take the following two scenerios for example:

 

All I want to do in this example is transfer to ext# 2502 and this works without a problem:

http://64.193.87.67/~kallman/pbxnsip/working.JPG

 

All I want to do in this example is transfer to the same 2502 but this time using wildcard/pattern matching:

http://64.193.87.67/~kallman/pbxnsip/notworking.JPG

 

*ugh*

 

Why does the second example not work?

 

And sometimes in the logfile when I have a bad replacement value I get this:

 

[5] 2007/06/29 11:09:11: Dialplan: i goes to extension

[5] 2007/06/29 11:09:11: Dialplan: i is not a known user in domain pbx.test.com

 

What the heck is i?

 

PS: I put the 8$u back to 7$u as you mentioned above just to make sure!

Link to comment
Share on other sites

I beat this and beat this until I got it to work.

 

I dunno why (and would still love it if someone explained) but I could never get the simple pattern matching to work.

 

So ... here's what I did:

 

Set the Pattern:

 

([2][0-9][0-9][0-9])@.*

 

Set the Replacement:

\1

 

Done and now all works and life is great!

Link to comment
Share on other sites

  • 2 weeks later...

Dang it ...

 

I thought I had it figured out!

 

But ... I cannot use Call Ext in the Dial Plans as it does not "behave" like the ext it is being sent to.

 

See: http://forum.pbxnsip.com/index.php?showtopic=202

 

So I'm back to beating this topic around again.

 

I've got to get this figured out ... so much so that I'm supposed to be on vacation this week but I'm taking any time needed to try and finish this problem.

 

I don't mean to offend anyone but I need answers so badly that I'm willing to pony up some cash if that is what it takes ...

 

Prev said:

 

"The REFER looks fine to me - it is just that the dial plan seems not to be able to send the call to something useful."

 

Here's what the first packet looks like again (slightly modified to reflect current settings):

 

[7] 2007/06/27 14:17:20: SIP Rx tcp:192.168.11.4:5065:

REFER sip:2502@192.168.11.5:5060;transport=tcp SIP/2.0

FROM: <sip:2400@apollo.test.com;user=phone>;epid=C1-FB-4C-98-B4;tag=68e0d24c7f

TO: <sip:2502@apollo.test.com>;tag=22017

CSEQ: 1 REFER

CALL-ID: 5e333c44@pbx

MAX-FORWARDS: 70

VIA: SIP/2.0/TCP 192.168.11.4:5065;branch=z9hG4bK5d77c932

CONTACT: <sip:apollo.test.com:5065;transport=Tcp;maddr=192.168.11.4>

CONTENT-LENGTH: 0

REFER-TO: <sip:2502@192.168.11.5:5060;transport=tcp;user=phone>

USER-AGENT: RTCC/2.0.6017.0

Referred-By: sip:2400@apollo.test.com;user=phone

 

Let's break this down if possible.

 

 

The packet is from the exchange server apollo (192.168.11.4).

 

Not sure what a REFER is supposed to do but Apollo is contacting the PBXnSIP server at 192.168.11.5 and asking for 2502 which is the extension I'm trying to transfer to.

 

REFER sip:2502@192.168.11.5:5060;transport=tcp SIP/2.0

 

On the exchange server the ext# it is coming from is 2400.

 

FROM: <sip:2400@apollo.test.com;user=phone>;epid=C1-FB-4C-98-B4;tag=68e0d24c7f

 

Not sure why this packet shows the TO: as apollo again. I'd kinda expect this to be for the PBXnSIP server?

 

TO: <sip:2502@apollo.test.com>;tag=22017

 

So more SIP mombojumbo.

 

CSEQ: 1 REFER

CALL-ID: 5e333c44@pbx

MAX-FORWARDS: 70

 

Coming via TCP from 192.168.11.4 (the exchange server).

 

VIA: SIP/2.0/TCP 192.168.11.4:5065;branch=z9hG4bK5d77c932

 

More SIP info.

 

CONTACT: <sip:apollo.test.com:5065;transport=Tcp;maddr=192.168.11.4>

CONTENT-LENGTH: 0

 

Looks like a good chance this is correct as I'm trying to transfer to 2502 on 192.168.11.5 the PBXnSIP server.

 

REFER-TO: <sip:2502@192.168.11.5:5060;transport=tcp;user=phone>

 

More SIP stuff.

 

USER-AGENT: RTCC/2.0.6017.0

 

Coming from 2400 on the Exchange server.

 

Referred-By: sip:2400@apollo.test.com;user=phone

 

*****

 

Does anything stick out in this packet that would lead one to believe that the rest of the conversation should not workout?

 

All I want to do is send a call to PBXnSIP from Exchange just like the PRI gateway sends a call to the PBX server.

 

Seems like the way Exchange wants to do it is via a REFER ...

 

Any ideas?

Link to comment
Share on other sites

Here's a brand new log file with all current changes:

 

The 301xxxxxxx is my home phone calling work ... I blanked it out for obvious reasons.

 

Here's the line on down in the log that makes me think I'm so close:

 

/* snippet

[5] 2007/07/08 14:47:18: Redirecting call to 2502

*/

 

That's where I wanna go ... I'm trying to transfer back to 2502. And if I try a transfer to another person their ext# shows up instead of mine.

 

So ... PBXnSIP knows where I'm trying to get to ... but ... for some reason I always get ex_permission.wav ...

 

PS: Sorry for the long posts but this is the call from start to finish as Exchange UM performs the REFER.

 

 

[7] 2007/07/08 14:47:18: SIP Rx tcp:192.168.11.4:5065:

REFER sip:301xxxxxxx@192.168.11.5:5060;transport=tcp SIP/2.0

FROM: <sip:2424@apollo.test.com;user=phone>;epid=46-F6-C5-D5-61;tag=5941401e1e

TO: <sip:301xxxxxxx@apollo.test.com>;tag=24016

CSEQ: 1 REFER

CALL-ID: e09cfa91@pbx

MAX-FORWARDS: 70

VIA: SIP/2.0/TCP 192.168.11.4:5065;branch=z9hG4bK42702096

CONTACT: <sip:apollo.test.com:5065;transport=Tcp;maddr=192.168.11.4>

CONTENT-LENGTH: 0

REFER-TO: <sip:2502@192.168.11.5:5060;transport=tcp;user=phone>

USER-AGENT: RTCC/2.0.6017.0

Referred-By: sip:2424@apollo.test.com;user=phone

 

 

[8] 2007/07/08 14:47:18: Resolve destination 98700: tcp 192.168.11.4 5065

[8] 2007/07/08 14:47:18: Send Packet 202

[7] 2007/07/08 14:47:18: SIP Tx tcp:192.168.11.4:5065:

SIP/2.0 202 Accepted

Via: SIP/2.0/TCP 192.168.11.4:5065;branch=z9hG4bK42702096

From: <sip:2424@apollo.test.com;user=phone>;epid=46-F6-C5-D5-61;tag=5941401e1e

To: <sip:301xxxxxxx@apollo.test.com>;tag=24016

Call-ID: e09cfa91@pbx

CSeq: 1 REFER

Contact: <sip:301xxxxxxx@192.168.11.5:5060;transport=tcp>

User-Agent: pbxnsip-PBX/2.0.3.1715

Content-Length: 0

 

 

[5] 2007/07/08 14:47:18: Redirecting call to 2502

[8] 2007/07/08 14:47:18: Resolve destination 98701: a Tcp 192.168.11.4 5065

[8] 2007/07/08 14:47:18: Resolve destination 98701: Tcp 192.168.11.4 5065

[8] 2007/07/08 14:47:18: Send Packet BYE

[7] 2007/07/08 14:47:18: SIP Tx tcp:192.168.11.4:5065:

BYE sip:apollo.test.com:5065;transport=Tcp;maddr=192.168.11.4 SIP/2.0

Via: SIP/2.0/TCP 192.168.11.5:5060;branch=z9hG4bK-828172d8ed8622060a8fb41c6091c805;rport

From: "301xxxxxxx" <sip:301xxxxxxx@apollo.test.com>;tag=24016

To: <sip:2424@apollo.test.com;user=phone>;tag=5941401e1e

Call-ID: e09cfa91@pbx

CSeq: 12843 BYE

Max-Forwards: 70

Contact: <sip:301xxxxxxx@192.168.11.5:5060;transport=tcp>

RTP-RxStat: Dur=14,Pkt=467,Oct=80324,Underun=407

RTP-TxStat: Dur=14,Pkt=498,Oct=85656

Content-Length: 0

 

 

[8] 2007/07/08 14:47:18: Play audio_en/ex_permission.wav

[7] 2007/07/08 14:47:18: SIP Rx tcp:192.168.11.4:5065:

SIP/2.0 200 OK

FROM: "301xxxxxxx"<sip:301xxxxxxx@apollo.test.com>;tag=24016

TO: <sip:2424@apollo.test.com;user=phone>;tag=5941401e1e;epid=46-F6-C5-D5-61

CSEQ: 12843 BYE

CALL-ID: e09cfa91@pbx

MAX-FORWARDS: 70

VIA: SIP/2.0/TCP 192.168.11.5:5060;branch=z9hG4bK-828172d8ed8622060a8fb41c6091c805;rport

CONTENT-LENGTH: 0

SERVER: RTCC/2.0.6017.0

 

 

[5] 2007/07/08 14:47:18: BYE Response: Terminate e09cfa91@pbx

[7] 2007/07/08 14:47:18: Other Ports: 1

[7] 2007/07/08 14:47:18: Call Port: call-F167A001-8F0F-2A10-0B06-14B@192.168.11.6#0f519ce80a

Link to comment
Share on other sites

  • 2 weeks later...

Maybe this is a premature post but I'm ssoo happy I wanted to share.

 

Paul from PBXnSIP was nice enough to help me along by comparing logs and setup.

 

After making everything equal ... it worked!

 

So then we began to back off little by little to the config we were originally running.

 

Right now ... I'm placing the "blame" on the Domain setting in PBXnSIP.

 

I changed ours from the default "localhost" setting because for some reason our Polycom phones would not provision correctly.

 

Setting that to a FQDN that the phones could resolve to the PBXnSIP server seemed to make that problem go away.

 

But ... changing that back to localhost made Exchange transfers to an ext# work ... hooray!

 

So we left the Domain setting in PBXnSIP as a FQDN and added a localhost alias and it still works ... hooray^2!

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.

×
×
  • Create New...