Jon Heese

There are no FXO ports involved here, and as far as I know, star codes do not work on a PRI (and my testing bears this out). However, I will take your advice and contact Sangoma and see if there is any more documentation on exactly how I should go about disabling caller-id. Keep in mind that we're not talking about globally disabling outbound caller ID, but rather selectively disabling it for a specific call, or as a workaround, for a specific extension. Regards, Jon Heese

Any word on this? Regards, Jon Heese

I don't fully understand your first question (or are you talking about "Remote Party/Privacy Indication"?), and I've tried all the possible values in the "Remote Party/Privacy Indication" field, including "No Indication", all with the same results. That's what I meant when I said this: Regards, Jon Heese

Running pbxnsip v3.4.0.3201 (Win32) with a single trunk going to Netborder Express (running on the same server as pbxnsip), which talks to an internal Sangoma A101 single PRI card. Plugged into the Sangoma card we have a PRI from Nuvox Communications. Our issue is with blocking outbound caller ID. Optimally, we'd like to have a "*67" kind of feature, where we could selectively block outbound caller ID on a call-by-call basis, but I understand that the *67 code is a POTS feature, and won't work with a PRI. Instead, we need the switch (i.e. pbxnsip) to generate the proper signal to tell the PRI to block outbound caller ID. So, I'm testing the "Block outbound caller-ID" feature in the extension settings. When I enable that flag and watch the SIP packets, I see that there is an additional "Privacy: id" header added (if I'm using P-Asserted-Identity or P-Preferred-Identity) and an additional "privacy=full" added on to the end of the "Remote-Party-ID" field, if I enable that (I know, I know, it's a legacy option that shouldn't be used). However, the outbound caller ID is NOT being blocked, as it shows up on the callee side as normal. The Netborder logs show the same SIP headers for "privacy" turned on, but it still passes the ANI to the PRI (as it needs to in order for the call to be allowed by our provider). So, my question is: I've got three different players involved here (pbxnsip, Netborder/Sangoma, and Nuvox)... How do I figure out where the problem is? Thanks in advance for any help. Regards, Jon Heese

Okay, how do I turn it off? And will turning it off affect something else negatively? i.e. Is there a reason why it's set this way by default? Also, I don't follow what you mean when you say "the original From/To fields"... Do you mean the fields that show the call as being "To: 305-247-2227"? If so, please understand that this is exactly what we DON'T want. I'm trying to be positive about this, but this has got to be the most unclear, inattentive support I've ever received for a piece of software. I don't even know whether I'm speaking to one person or a bunch of different people. Do you have a real name I can refer to you by? If one of my clients had this issue (and they WILL, once we're confident enough to sell this product), and it took them this long just to explain the problem to tech support, let alone come back with an answer, they would quickly dump me and go with someone else. Regards, Jon Heese

Okay, so consider the following call routing: Incoming PSTN call | v Patton gateway | v Auto-attendant | v Hunt group | v Extension Since the above call came through an auto-attendant, shouldn't it at least show the hunt group as the final destination, not the PSTN/DID number of the company? Regards, Jon Heese

Any word on this? Regards, Jon Heese

That's exactly what I've been trying to tell you! Can you explain this comment a little more? Are you saying that the auto-attendant changes the "To" header to reflect the dialed extension, but the ring group doesn't do this? If so, is there a reason why it behaves this way? Is there any way to make the ring group change the "To" header to properly reflect the extension that picks up the call? It's really quite useless to say that a call was made "To: 305-247-2227", considering that ALL of our incoming calls were made to that number, and what we really want to see is the extension that the caller spoke to. No, we're not using any logging besides the standard "e-mail call logs every night at 12 midnight". No SOAP/CSV/etc. at all. This is purely a call header issue, not something to do with the separate logging mechanism. I can also show this fact by looking at the "Current Calls" page in the web interface. When a call comes in through the ring group, and the caller is speaking with the extension that picked up, you can see in this screen that the "To" header shows "305-247-2227". Regards, Jon Heese

I read through that wiki page a few times and I truly don't understand how it relates to this issue. Just to be clear, we are not having an issue with call routing. Calls are going exactly where we want, when we want. We are having an issue with call *logging*. When an outside caller calls our PBX through our PSTN lines (connected via a 4-port Patton 4114), they are sent directly to an auto-attendant, which allows them to dial an extension or wait to be connected to a ring group. If they dial an extension at that point, they are sent to that extension and the call logs show the caller as being connected to the user whose extension they dialed, like this: Time From To Duration 2009/05/19 09:59:46 COMPANY XYZ ((305)555-4339) Jon Heese (24) 08:07 If they do not dial an extension, and instead they just wait, they are sent to the ring group, and the call logs show a call that looks like this: Time From To Duration 2009/05/19 09:57:34 COMPANY XYZ ((305)555-4339) (305)247-2227 05:36 Both calls above came through the *exact* same PSTN lines, the *exact* same Patton gateway, the *exact* same trunk in pbxnsip, and the *exact* same auto-attendant, and the first place they differ is whether they come through a ring group or go directly to an extension. This is why I think the problem is with the ring group, NOT the gateway or trunk setup. Please confirm that you understand my description above, as I feel like you may be chasing a problem that we don't have. I'm sorry if I seem dense or pedantic, but I just don't understand your logic here. Regards, Jon Heese

Please forgive my skepticism, but I really don't see how this is progress at all. All we've done is change one static field ("anonymous") for another ("305-247-2227"). I just want to make sure that you realize that this number is just our main phone number here in the office, so seeing that all incoming calls (that came through the hunt group) in the logs spoke with "305-247-2227" is really quite uninformative. It seems to me that we're barking up the wrong tree, since the problem only occurs when the call comes through the hunt group. I don't quite follow how that could be an issue with our gateway configuration, since all of the calls come through the gateway the same way, but some calls are logged properly (direct extension dials) and some are not (hunt group calls). Anyway, here are the INVITE messages that show up in the logs on an incoming call: [7] 2009/05/19 10:59:50: SIP Rx udp:192.168.10.240:5060: INVITE sip:3052472227@192.168.10.2 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.240:5060;branch=z9hG4bKf5a01bcd5 Max-Forwards: 70 Content-Length: 224 To: sip:3052472227@192.168.10.2 From: Elite Security <sip:3052455266@192.168.10.2>;tag=ec6505bcbf825e7 Call-ID: ffadce9d8dd6cdf4c231441a0e045cb6@192.168.10.2 CSeq: 597804336 INVITE Route: <sip:192.168.10.2;lr> Supported: timer Remote-Party-ID: Elite Security <sip:3052455266@192.168.10.2>;party=calling;screen=no;privacy=off Content-Type: application/sdp Contact: sip:3052455266@192.168.10.240:5060 Supported: replaces User-Agent: Patton SN4114 JO EUI MxSF v3.2.8.45 00A0BA03DC02 R4.2 2008-03-11 H323 SIP FXS FXO v=0 o=MxSIP 0 147 IN IP4 192.168.10.240 s=SIP Call c=IN IP4 192.168.10.240 t=0 0 m=audio 5158 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv [7] 2009/05/19 10:59:50: SIP Tx udp:192.168.10.240:5060: SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.10.240:5060;branch=z9hG4bKf5a01bcd5 From: Elite Security <sip:3052455266@192.168.10.2>;tag=ec6505bcbf825e7 To: <sip:3052472227@192.168.10.2>;tag=f47b8af437 Call-ID: ffadce9d8dd6cdf4c231441a0e045cb6@192.168.10.2 CSeq: 597804336 INVITE Content-Length: 0 [5] 2009/05/19 10:59:50: Trunk Patton SN4114 (global) sends call to account 80 in domain st2.st-aubin.com [7] 2009/05/19 10:59:50: SIP Tx udp:192.168.10.240:5060: SIP/2.0 200 Ok Via: SIP/2.0/UDP 192.168.10.240:5060;branch=z9hG4bKf5a01bcd5 From: Elite Security <sip:3052455266@192.168.10.2>;tag=ec6505bcbf825e7 To: <sip:3052472227@192.168.10.2>;tag=f47b8af437 Call-ID: ffadce9d8dd6cdf4c231441a0e045cb6@192.168.10.2 CSeq: 597804336 INVITE Contact: <sip:3052472227@192.168.10.2:5060;transport=udp> Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: pbxnsip-PBX/3.3.1.3177 Content-Type: application/sdp Content-Length: 216 v=0 o=- 52396 52396 IN IP4 192.168.10.2 s=- c=IN IP4 192.168.10.2 t=0 0 m=audio 55578 RTP/AVP 0 8 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=sendrecv [7] 2009/05/19 10:59:50: Last message repeated 2 times [7] 2009/05/19 10:59:50: SIP Rx udp:192.168.10.240:5060: ACK sip:3052472227@192.168.10.2:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 192.168.10.240:5060;branch=z9hG4bKd689046f8 Max-Forwards: 70 Content-Length: 0 To: sip:3052472227@192.168.10.2;tag=f47b8af437 From: Elite Security <sip:3052455266@192.168.10.2>;tag=ec6505bcbf825e7 Call-ID: ffadce9d8dd6cdf4c231441a0e045cb6@192.168.10.2 CSeq: 597804336 ACK Contact: sip:3052455266@192.168.10.240:5060 User-Agent: Patton SN4114 JO EUI MxSF v3.2.8.45 00A0BA03DC02 R4.2 2008-03-11 H323 SIP FXS FXO Thanks for your help so far. Regards, Jon Heese

Any word on this issue yet? Regards, Jon Heese

Okay, I figured out how to change the "To:" header on incoming calls to the gateway, and I set it to the main number, 3052472227 (all the lines go through the same SIP interface, so there was only one place to set it and they all take that setting). However, all that did was change the "To:" header to "(305)247-2227", instead of "anonymous". Calls that have come through the hunt group still don't show who they spoke with, they just show "(305)247-2227". If the caller dials an extension directly from the AA, that extension does show up in the logs. I can post log snippets if you need to see the difference between the two call strategies. Any other ideas? Regards, Jon Heese

Okay, so any idea how to do any of this in the Patton interface? Regards, Jon Heese

Okay, I understand, but I have no idea how to do what you're describing. We have 4 lines coming in to the Patton SN-4114 gateway and all of them ring in a rollover pattern based on one incoming number, 305-247-2227. Do you know where in the Patton web interface I'm supposed to configure the ports to identify with this number? You understand what I mean when I say that I'm worried this will just replace the "anonymous" in our call logs with our company's phone number, right? Still quite useless. Regards, Jon Heese

Thanks for your reply! Hmmm... The gateway is a Patton SN-4114, and I have to be honest: I have no earthly idea what I'm doing in its web interface 90% of the time. There is nothing intuitive about it, and I feel like I should have gone through a 9 month training class before even touching it. The only way I've been able to configure it correctly in the past is with step-by-step guides in the wiki, etc. I have poked around there for a few minutes just now, but I don't see anything jumping out at me. Something else bothers me about this a little: If this issue is being caused by a setting in the gateway, through which all calls come in, then why is the issue only occurring with calls that come through the Hunt Group, and not calls that are directed to an extension directly? Is there some fundamental difference with the way the call is handled that causes pbxnsip to change the "To" header for direct extension dialed calls and not Hunt Group calls? Furthermore, wouldn't changing some setting in the gateway to show the DID number of the incoming lines (instead of "anonymous") just change our To header from "anonymous" to "305-247-2227"? That's no good either. All we want is for the system to properly modify that header upon transfer out of the Hunt Group and into the individual user that picks up the call. Is this possible? Any further suggestions are greatly appreciated. Regards, Jon Heese