Jon Heese Posted May 14, 2009 Report Share Posted May 14, 2009 Running pbxnsip v3.3.1.3177. We noticed that incoming calls that come through our main hunt group show up in the calls as being "to" anonymous, even though they connected and spoke with an extension via the hunt group. This is quite annoying for us, because when looking at the call logs, we can't see exactly who an incoming caller spoke with, unless they dialed that person's extension directly, which is rare. Is this intended behavior? A bug? Any way for us to change it to log the final connected extension as the recipient, instead of the "anonymous" hunt group? I set the log level to 7, enabled sip logging and placed a couple test calls, one via the hunt group and one via direct extension dial in the AA. Sure enough, the two log snippets differ in the fact that the hunt group call shows <sip:anonymous@192.168.10.2;user=phone>" in the To: header the whole time, where the direct extension call shows "To: 'Jon Heese' <sip:24@st2.st-aubin.com>" starting at the point where the caller dials my extension. The "From-Header" field on the hunt group is set to "Calling-Party", which I believe is the default. Plus it seems like we're having an issue with the "To:" header, not the "From:". You can see the issue in the attached log files, the message where they start to differ is on line 80 of both. You can see that the "Contact" field is set to <sip:24@72.17.170.196:5060;transport=udp> in both, but the To: header is showing "anonymous" on the hunt group call. Any ideas? Thanks in advance for any assistance you can provide. Regards, Jon Heese call_to_extension.txt call_to_hunt_group.txt Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted May 14, 2009 Report Share Posted May 14, 2009 At the beginning of the trace there is a packet received by the PBX from 192.168.10.240 where the To is already set to "anonymous". The PBX just "happily" passes that on. Check the gateway, maybe there is the DID number setup missing or somehow screwed up... In the telecom world, a "anonymous" destination is not possible yet! I want to call you, but I don't want to let you know which number I called . Quote Link to comment Share on other sites More sharing options...
Jon Heese Posted May 14, 2009 Author Report Share Posted May 14, 2009 At the beginning of the trace there is a packet received by the PBX from 192.168.10.240 where the To is already set to "anonymous". The PBX just "happily" passes that on. Check the gateway, maybe there is the DID number setup missing or somehow screwed up... In the telecom world, a "anonymous" destination is not possible yet! I want to call you, but I don't want to let you know which number I called . 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 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted May 14, 2009 Report Share Posted May 14, 2009 I would really try to nail it down at the To-header that leaves the gateway. There is no way the gateway can have a To-header "anonymous" in the PSTN world (in the SIP world, it would be possible). Maybe you just need to assign a DID number to a port and you accidentially forgot it. And the gateway right now just falls back to "anonymous" because it has nothing better. Quote Link to comment Share on other sites More sharing options...
Jon Heese Posted May 14, 2009 Author Report Share Posted May 14, 2009 I would really try to nail it down at the To-header that leaves the gateway. There is no way the gateway can have a To-header "anonymous" in the PSTN world (in the SIP world, it would be possible). Maybe you just need to assign a DID number to a port and you accidentially forgot it. And the gateway right now just falls back to "anonymous" because it has nothing better. 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 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted May 14, 2009 Report Share Posted May 14, 2009 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. Even if you have one number that is rolling over, the carrier has a DID number assigned to each of the FXO lines. You can put these numbers in (they are sometimes visible when you place outbound calls, depending on your carrier uses them). I am not sure if the Patton has a problem if you assign the same number to all lines. That might also be worth a shot. Some carriers signal not only the Caller-ID also the called number. Maybe that is a problem here and we have a kind of "interop" problem on the FXO side. Though I would give this only a low probability. Quote Link to comment Share on other sites More sharing options...
Jon Heese Posted May 15, 2009 Author Report Share Posted May 15, 2009 Even if you have one number that is rolling over, the carrier has a DID number assigned to each of the FXO lines. You can put these numbers in (they are sometimes visible when you place outbound calls, depending on your carrier uses them). I am not sure if the Patton has a problem if you assign the same number to all lines. That might also be worth a shot. Some carriers signal not only the Caller-ID also the called number. Maybe that is a problem here and we have a kind of "interop" problem on the FXO side. Though I would give this only a low probability. Okay, so any idea how to do any of this in the Patton interface? Regards, Jon Heese Quote Link to comment Share on other sites More sharing options...
Jon Heese Posted May 17, 2009 Author Report Share Posted May 17, 2009 Okay, so any idea how to do any of this in the Patton interface? 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 Quote Link to comment Share on other sites More sharing options...
Jon Heese Posted May 18, 2009 Author Report Share Posted May 18, 2009 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 Any word on this issue yet? Regards, Jon Heese Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted May 18, 2009 Report Share Posted May 18, 2009 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. If you get something else that "anonymous" then that's progress. Maybe you can just post the INVITE message that the PSTN gateway sends to the PBX, and then we should get close! Quote Link to comment Share on other sites More sharing options...
Jon Heese Posted May 19, 2009 Author Report Share Posted May 19, 2009 If you get something else that "anonymous" then that's progress. Maybe you can just post the INVITE message that the PSTN gateway sends to the PBX, and then we should get close! 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 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted May 19, 2009 Report Share Posted May 19, 2009 Now we can pull the destination out of the Request-URI. Now the rules in http://wiki.pbxnsip.com/index.php/Inbound_Calls_on_Trunk apply. You can now also just assign an alias name to the extension, and then the PBX will send the call to the right destination. Progress is not success, I agree. Quote Link to comment Share on other sites More sharing options...
Jon Heese Posted May 21, 2009 Author Report Share Posted May 21, 2009 Now we can pull the destination out of the Request-URI. Now the rules in http://wiki.pbxnsip.com/index.php/Inbound_Calls_on_Trunk apply. You can now also just assign an alias name to the extension, and then the PBX will send the call to the right destination. Progress is not success, I agree. 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 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted May 22, 2009 Report Share Posted May 22, 2009 Oh, okay. No, I was not aware it was a logging (CDR) issue. What you see in the web interface are the From/To headers of the call. The auto attendant changes the from/to headers when you place a call to an extension, so that it looks like the call originally went to that extension. "Supposed to be a feature", but I agree it is not very systematically. The CDR record (see the XML file in the cdr directory) contains more detailed information. There you would find the information that you need where exactly the call went to. If you are sending the CDR out (in whatever way) you can transport that information. Are you using SOAP, CSV file or some other mechanism to send the CDR from the PBX? Maybe then the problem can be addressed easily. Quote Link to comment Share on other sites More sharing options...
Jon Heese Posted May 26, 2009 Author Report Share Posted May 26, 2009 What you see in the web interface are the From/To headers of the call. That's exactly what I've been trying to tell you! The auto attendant changes the from/to headers when you place a call to an extension, so that it looks like the call originally went to that extension. "Supposed to be a feature", but I agree it is not very systematically. 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. Oh, okay. No, I was not aware it was a logging (CDR) issue. The CDR record (see the XML file in the cdr directory) contains more detailed information. There you would find the information that you need where exactly the call went to. If you are sending the CDR out (in whatever way) you can transport that information. Are you using SOAP, CSV file or some other mechanism to send the CDR from the PBX? Maybe then the problem can be addressed easily. 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 Quote Link to comment Share on other sites More sharing options...
Jon Heese Posted June 1, 2009 Author Report Share Posted June 1, 2009 Any word on this? Regards, Jon Heese Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted June 1, 2009 Report Share Posted June 1, 2009 Any word on this? Well, at the moment it is a feature. When you use the auto attendant that AA fixes the outside's callers inability to directly call and extension and it shows the call went right to the extension. For other calls like hunt groups, it should which number was dialled. In the CDR record you have more information so you can figure out where the call actually went. The alternative is that the auto attendant does not change headers. But then the headers would usually only show that the call went to a DID number of the company; IMHO that would be worse than changing the headers. BTW there is a flag in the domain settings that tells the PBX not to change the headers, did you try that out? Quote Link to comment Share on other sites More sharing options...
Jon Heese Posted June 2, 2009 Author Report Share Posted June 2, 2009 Well, at the moment it is a feature. When you use the auto attendant that AA fixes the outside's callers inability to directly call and extension and it shows the call went right to the extension. For other calls like hunt groups, it should which number was dialled. In the CDR record you have more information so you can figure out where the call actually went. The alternative is that the auto attendant does not change headers. But then the headers would usually only show that the call went to a DID number of the company; IMHO that would be worse than changing the headers. BTW there is a flag in the domain settings that tells the PBX not to change the headers, did you try that out? 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 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted June 4, 2009 Report Share Posted June 4, 2009 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? What you will get is a CDR "fragment" for each segment of the call. Because it is impossible to summarize the whole call when going from one segment to another, the PBX generates a CDR record for each segment. That's the idea behind those internal CDR. In order to make the Auto Attendant look better, it pretends that the original destination was the extension. That part is debatable. However, we still have this option weather the PBX should change the From/To-fields. If you turn it off, then chances are that the original From/To fields make it through this CDR chain. Quote Link to comment Share on other sites More sharing options...
Jon Heese Posted June 5, 2009 Author Report Share Posted June 5, 2009 What you will get is a CDR "fragment" for each segment of the call. Because it is impossible to summarize the whole call when going from one segment to another, the PBX generates a CDR record for each segment. That's the idea behind those internal CDR. In order to make the Auto Attendant look better, it pretends that the original destination was the extension. That part is debatable. However, we still have this option weather the PBX should change the From/To-fields. If you turn it off, then chances are that the original From/To fields make it through this CDR chain. 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 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.