Chappo Posted March 22, 2012 Report Share Posted March 22, 2012 Guys, As per the title I am having issues with the Caller ID updating when an attended transfer occurs. When looking at the SIP trace on the receiving handset the P-Asserted Identity is always the person that initiated the transfer. It is not updating to be the external trunk ID. Received from tls:172.28.1.5:5061 at 22/3/2012 13:21:06:670 (489 bytes): PRACK sip:45@172.28.1.82:3120;transport=tls;line=8gg2i362 SIP/2.0 Via: SIP/2.0/TLS 172.28.1.5:5061;branch=z9hG4bK-786e1c01f663a1a0dcfcacc96a406222;rport From: "AS" <sip:40@pbx.domain.com.au>;tag=60344 To: "BC" <sip:45@pbx.domain.com.au>;tag=1b32s1jnpo Call-ID: f52b415a@pbx CSeq: 31620 PRACK Max-Forwards: 70 Contact: <sip:45@172.28.1.5:5061;transport=tls> RAck: 1 31619 INVITE P-Asserted-Identity: "AS" <sip:40@pbx.domain.com.au> Content-Length: 0 Current version info (Have also tried the latest beta with no change) Version: 2011-4.5.0.1016 Alpha Monocerotids (Win64) Created on: Dec 22 2011 14:15:39 License Status: snom ONE yellow Quote Link to comment Share on other sites More sharing options...
pbx support Posted March 22, 2012 Report Share Posted March 22, 2012 Can you see if there was an INFO message (instead of the PRACK) Quote Link to comment Share on other sites More sharing options...
Chappo Posted March 23, 2012 Author Report Share Posted March 23, 2012 There is no INFO messages in either the server log or the phone SIP log. Quote Link to comment Share on other sites More sharing options...
katerina Posted April 2, 2012 Report Share Posted April 2, 2012 In this case I think snom ONE sends the wrong caller ID in the P-Asserted-Identity. I am trying to get this fixed but for now the solution I found is to ignore this header. You can add this line in the provisioning template: <ignore_asserted_in_gui perm="RW">on</ignore_asserted_in_gui> Let me know if this helps. Quote Link to comment Share on other sites More sharing options...
Chappo Posted April 18, 2012 Author Report Share Posted April 18, 2012 Thank you Kat. That has allowed the phones to correctly display the Caller ID - However using ContactPad and/or Flexor Manager the Caller ID is not being updated. It is still showing as the extension that transferred the call. Is there anything else that can be done short of a snomone update to fix the issue? Quote Link to comment Share on other sites More sharing options...
katerina Posted June 8, 2012 Report Share Posted June 8, 2012 Hello, The issue was reproduced in our lab and a bug report was done (internal ID SONE-186) . We hope to have a fix soon. Quote Link to comment Share on other sites More sharing options...
pyroboynroses Posted June 13, 2012 Report Share Posted June 13, 2012 Hello, Thank you for these tests, I could'nt test it in my side. So, We hope there will be a bugfix soon. Quote Link to comment Share on other sites More sharing options...
Chappo Posted June 15, 2012 Author Report Share Posted June 15, 2012 Thanks Katerina, Can you please advise when you expect a release that fixes this issue? The CTI software that we are using is crippled whilst this issue is occurring. Quote Link to comment Share on other sites More sharing options...
pbx support Posted June 15, 2012 Report Share Posted June 15, 2012 Do you have the SIP trace from the 'working' and 'not working' conditions? Quote Link to comment Share on other sites More sharing options...
jim@itstod.se Posted June 17, 2012 Report Share Posted June 17, 2012 Thank you Kat. That has allowed the phones to correctly display the Caller ID - However using ContactPad and/or Flexor Manager the Caller ID is not being updated. It is still showing as the extension that transferred the call. Is there anything else that can be done short of a snomone update to fix the issue? As I understand it Chappo is referring to a problem that we have tried to fix in the ContactPad CTI software but we have not managed to solve it. Here it is: http://forum.snom.com/index.php?showtopic=1946. We have tried to make use of the Action URL setting "action_received_attended_transfer" but without luck. We would really appreciate if someone from Snom would explain how we should use this action URL to solve the issue. Best regards, Jim Quote Link to comment Share on other sites More sharing options...
Chappo Posted June 18, 2012 Author Report Share Posted June 18, 2012 I have attached a SIP trace of an attended transfer. The issue is as follows:- We are currently using Flexor Manager (But have also had the same issue with ContactPad) in which when an attended transfer is sent through to an extension the software only reports the internal caller which transferred the call through - It does not update for the external parties number. The attended_transfer action item is shown as - 172.28.1.73:4052/action_attended_transfer?local=$local&remote=$remote&callid=$call-id&csta=$csta_id&active_url=$active_url&active_user=$active_user&active_host=$active_host&displocal=$display_local&disprem=$display_remote We had the same issue on the phones where the external number would not show but changing the ignore_asserted_in_gui allows for the correct update - I presume that the "asserted number" is what is being passed to the Flexor/ContactPad software. It has only been an issue with the last couple of snomone releases. Is this what internal fault ID SONE-186 has been lodged for? SnomLog.txt Quote Link to comment Share on other sites More sharing options...
pbx support Posted June 18, 2012 Report Share Posted June 18, 2012 Not sure which message from that log really caused the wrong caller-id on Flexor (i.e., did not see any INVITE/INFO). Is the <presence> NOTIFYs causing the issue? In any case, we will see what is really wrong in the attended transfer case. Quote Link to comment Share on other sites More sharing options...
katerina Posted June 19, 2012 Report Share Posted June 19, 2012 We have a fix in which the P-asserted header has been removed. Would you like to test it (which OS)? You will no longer need the ignore_asserted_in_gui workaround. Quote Link to comment Share on other sites More sharing options...
Chappo Posted June 20, 2012 Author Report Share Posted June 20, 2012 Thanks Katerina. Yes we would be willing to test. Using Server 2008 R2. Quote Link to comment Share on other sites More sharing options...
pbx support Posted June 20, 2012 Report Share Posted June 20, 2012 Here are the 2 windows versions (32 and 64 bit) http://downloads.snom.net/snomONE/win32/v4.5/pbxctrl-4.5.0.1090.exe http://downloads.snom.net/snomONE/win64/v4.5/pbxctrl-4.5.0.1090.exe Quote Link to comment Share on other sites More sharing options...
Chappo Posted June 21, 2012 Author Report Share Posted June 21, 2012 The updated version still has not resolved the issue with Contact Pad / Flexor. I have been doing some more logging and have determined what the issue appears to be - This is more evident when answering an external call (It is just not occurring on attended transfers). As you can see from the logfile and SIP trace the initial http post sent to the PC includes a disprem with the star code pickup. It is only after a few seconds that the INFO message is received with the correct CLID. Sending post request host = 172.28.1.77:4052, file = /action_connected_url?local=45%40pbx.domain.com.au&remote=%2a6017&callid=08a9273c6eda-9rycw0bd21p6&csta=8&active_url=45%40pbx.domain.com.au&active_user=45&active_host=pbx.sgk.com.au&displocal=BC&disprem=%2a6017 The $display_remote key appears to be initially using the incorrect value. The disconnect action url has the correct CLID however by that stage it is too late. Edit: I have also attached the SnomONE log which correctly shows the CLID on the inbound call. Ex45 SIP Trace.txt Ext45 LOG.txt log-2012-06-21 - SnomONE Log.txt Quote Link to comment Share on other sites More sharing options...
pbx support Posted June 21, 2012 Report Share Posted June 21, 2012 The INFO is sent to update the caller id and I assume that is not ok for the flexor. BTW, do you have the log from the version that worked? We will compare the 2 and see what has changed and hopefully can take corrective action. Quote Link to comment Share on other sites More sharing options...
Chappo Posted June 22, 2012 Author Report Share Posted June 22, 2012 The INFO is sent to update the caller id and I assume that is not ok for the flexor. BTW, do you have the log from the version that worked? We will compare the 2 and see what has changed and hopefully can take corrective action. The problem from what I can gather is that the http action_connected_url is getting sent before the info message is being received - If this case no matter what software is in use on the PC it will not have the correct CLID. You can see in the logs that also each time that the phone call is placed on hold and retrieved that the CLID is the pickup star code again. Only when going into the hold or disconnected state and firing off the action_disconnected_url (and action_hold_url) that the CLID was correct - Which by this state is too late to update the CLID. Unfortunately no I do not have a log from when it was previously working. Quote Link to comment Share on other sites More sharing options...
Chappo Posted June 28, 2012 Author Report Share Posted June 28, 2012 Is there any more information that is needed to get this resolved? Quote Link to comment Share on other sites More sharing options...
pbx support Posted June 28, 2012 Report Share Posted June 28, 2012 Since you do not have the log from the working versions, we may have to recreate it on a older version here and verify the results. Since we do not have the flexor/contact pad in the lab, it is getting slower to see/test which version of PBX software made this to fail. Is this something that can be downloaded or shared for testing? This post sent to the phone I assume - 172.28.1.77:4052, file = /action_connected_url?local=45%40pbx.domain.com.au&remote=%2a6017&callid=08a9273c6eda-9rycw0bd21p6&csta=8&active_url=45%40pbx.domain.com.au&active_user=45&active_host=pbx.sgk.com.au&displocal=BC&disprem=%2a6017 Is that right? Quote Link to comment Share on other sites More sharing options...
Chappo Posted June 28, 2012 Author Report Share Posted June 28, 2012 That http post is sent from the phone to the client. This would appear to be an issue with the phone firmware and not the SnomOne. You shouldn't need to have the software installed. The below settings should give you the same result as it should still send the post result. action_dnd_on_url!: 172.28.1.81:4052/action_dnd_on_url?local=$local&remote=$remote&callid=$call-id&csta=$csta_id&active_url=$active_url&active_user=$active_user&active_host=$active_host&displocal=$display_local&disprem=$display_remote action_dnd_off_url!: 172.28.1.81:4052/action_dnd_off_url?local=$local&remote=$remote&callid=$call-id&csta=$csta_id&active_url=$active_url&active_user=$active_user&active_host=$active_host&displocal=$display_local&disprem=$display_remote action_incoming_url!: 172.28.1.81:4052/action_incoming_url?local=$local&remote=$remote&callid=$call-id&csta=$csta_id&active_url=$active_url&active_user=$active_user&active_host=$active_host&displocal=$display_local&disprem=$display_remote action_outgoing_url!: 172.28.1.81:4052/action_outgoing_url?local=$local&remote=$remote&callid=$call-id&csta=$csta_id&active_url=$active_url&active_user=$active_user&active_host=$active_host&displocal=$display_local&disprem=$display_remote action_connected_url!: 172.28.1.81:4052/action_connected_url?local=$local&remote=$remote&callid=$call-id&csta=$csta_id&active_url=$active_url&active_user=$active_user&active_host=$active_host&displocal=$display_local&disprem=$display_remote action_disconnected_url!: 172.28.1.81:4052/action_disconnected_url?local=$local&remote=$remote&callid=$call-id&csta=$csta_id&active_url=$active_url&active_user=$active_user&active_host=$active_host&displocal=$display_local&disprem=$display_remote Quote Link to comment Share on other sites More sharing options...
Chappo Posted July 2, 2012 Author Report Share Posted July 2, 2012 Any news? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 2, 2012 Report Share Posted July 2, 2012 Not sure if those settings there require a http:// in front of the IP address to form a URL.But the topic of the caller-ID update is on the action list (discussing if the from-change can be supported by the phones). Quote Link to comment Share on other sites More sharing options...
Chappo Posted July 3, 2012 Author Report Share Posted July 3, 2012 Not sure if those settings there require a http:// in front of the IP address to form a URL. They were removed so to prevent the forum code from messing up the http. But the topic of the caller-ID update is on the action list (discussing if the from-change can be supported by the phones). That's good to know. Any idea of time frames? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 3, 2012 Report Share Posted July 3, 2012 That's good to know. Any idea of time frames? "ASAP". We need a new firmware for the 7xx devices anyway. 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.