Model12 Posted June 27, 2007 Report Share Posted June 27, 2007 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 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted June 28, 2007 Report Share Posted June 28, 2007 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? Quote Link to comment Share on other sites More sharing options...
Model12 Posted June 28, 2007 Author Report Share Posted June 28, 2007 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! Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted June 29, 2007 Report Share Posted June 29, 2007 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. Quote Link to comment Share on other sites More sharing options...
Model12 Posted June 29, 2007 Author Report Share Posted June 29, 2007 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! Quote Link to comment Share on other sites More sharing options...
Model12 Posted June 29, 2007 Author Report Share Posted June 29, 2007 PS: Thanks for all the help! Quote Link to comment Share on other sites More sharing options...
Model12 Posted June 29, 2007 Author Report Share Posted June 29, 2007 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! Quote Link to comment Share on other sites More sharing options...
Model12 Posted July 8, 2007 Author Report Share Posted July 8, 2007 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? Quote Link to comment Share on other sites More sharing options...
Model12 Posted July 8, 2007 Author Report Share Posted July 8, 2007 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 Quote Link to comment Share on other sites More sharing options...
Model12 Posted July 8, 2007 Author Report Share Posted July 8, 2007 This looks like a similar problem from a fella using SIPX: http://forums.microsoft.com/TechNet/ShowPo...7&SiteID=17 I'm not quite sure if this is "my same problem". If so ... then this is good info for someone smarter than myself! Quote Link to comment Share on other sites More sharing options...
Model12 Posted July 17, 2007 Author Report Share Posted July 17, 2007 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! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.