(09-30-2016 11:59 PM)Yealink_kevin Wrote: (09-26-2016 06:33 PM)Chris Barron Wrote: (09-23-2016 09:27 AM)Yealink_kevin Wrote: Dear Chris
This is Kevin from Yealink support team, nice to know you.
For this issue, We replace the phone as character, such as T46:A; T41:B; caller phone:C.
Then let us check again with the sutiation:
B set BLF to monitor A, then C call A, B phone will display A<-C;
A set BLF to monitor B, then C call B, A just display B<-B, right?
Let me know if any misunderstanding. Also, please send the pacp,syslog,config.bin files to me , then i can do more trouleshooting. For how to get them, please refer to the FAQ:http://support.yealink.com/faq/faqInfo?id=311
NOTE:please reproduce the issue and send files to me. You should reproduce the 2 sutiation and send all fies to me, then i can do a comparison.
BR
Kevin
HI Kevin,
thanks for the quick response - yes the logic you describe is how i've set it up. Strangely, since i first tested on thursday the situation has changed. On the T46 its no longer showing the inbound number.
I've attached pcap traces from the phone and pcap traces from a local network capture via a bridge so i see both directions. The detail in the SIP notify shows only the extension number not the calling party's number. I tried changing the CID settings and it made no difference, the calling party did not appear in the notify messages however I set it.
Am I right in thinking that the phone presents the called party's name by referencing the extension number in the blf key and pulling back the name rather than relying on it being sent by the server. Because we are seeing the called extension number appearing in the Notify message for the called and call party then its showing Barry<<Barry.
I;ve got a tech case running with the third line support guys on the server side so I will update you.
Also I think I may have missed the syslog files - will end those later - chris
Dear Chris
Thanks for the files. I check the files and also test in my side. Here is reply to you.
1.please see the test result in my side, please kindly see the pacp in the link: http://ftp.yealink.com/?ShareToken=EDABD...0F943A69A9
Please filter 'sip and ip.addr==10.2.10.13' in the wireshark.
100 monitor 101, then use 102 to call 101, and 100 will display 101-<102. It is correct.
The server will send NOTIFY packet to the 100 with xml. In the xml, there is local identity and remote identity, then 100 will display 101-< 102 on the base of local and remote identity.
2.I check the file of you.
134 monitor 939, then use 308 to call 939, the server send a NOTIFY packet with xml. in the xml, we can see that remote identity and local identity are the same.
So please ask your server provider for help to change it on the server side.
Let me know if any udpate.
Due to the national holiday is upcoming, our office will be temporarily out of duty from Oct 1st to Oct 7th.
BR
Kevin
Kevin,
I have got to the bottom of this problem and have a solution but its not straightforward. Our server provider (Asterisk) are bicom systems. They advised that it's not possible for incoming caller details to be inserted into the xml string. The problem lies with Context. At the trunk level the call carries a different context before its passed into the dial plan where it would be answered. It might be possible to search for the identity of the call across all trunks or try to change the trunk context, but the fix is as follows: ( may only apply to the Bicom version of Asterisk)
If the call is answered at an extension and then blind transferred, the CLI is displayed correctly.
In the Bicom PBXware it's not uncommon to direct DiD calls onto a ring group rather than straight to the target user extension. This is so internal and external calls can be given different treatment, quite a common dial plan feature. The ring group is normally set to be transparent, passing the the call to be answered at the extension. However the ring group can be made to auto answer the call and insert music or ring tone to the caller until the extension answers. The caller does not know their call has been pre-answered.
This device puts the call into the correct context and the CLI is extracted and passed to the XML.
Chris