Jump to content

Call logs all Hunt Group calls as to:"anonymous"


Jon Heese
 Share

Recommended Posts

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

Link to comment
Share on other sites

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 :P .

Link to comment
Share on other sites

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 :P .

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

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.

 Share

×
×
  • Create New...