There’s not enough information to diagnose your problem, but the 488 reply means in many cases that there is a problem with the codecs, like missing something essential on the complaining side.
Got answer from yealink support it seems that it’s not a problem on that phone:
The normal process is Phone send 183 session to server/doorphone then server/doorphone send video preview stream to phone. It is RFC 3261 standard. Yealink also obey this rule (see screencapture 2). But from the pcap file, we find server/doorphone didn't send video preview stream to phone when phone send 183 session to server/doorphone.
The Fanvil phone send 200 OK to server/doorphone then server/doorphone send the video preview stream to phone. The phone did not pick up the call at this time.
Note: Once phone send 200 OK, it means phone pick up the call.
So it seems that there’s a problem on the PBX, now to answer to my previous question:
I’m a really bad user, yealink support take a long time to answer, but they provide detailed informations.
This product got some issues, but it’s hard to find out where the issue came from pbx or from the phone itself.
Now if anyone here can help to provide this info to yealink support:
For video preview:
1. Please check why server/doorphone didn't send the video stream to phone when phone send a 183 session to server/doorphone?
2. Is it because doorphone is not sent or the server is not forwarding?
3. Does the doorphone have to receive 200OK to send the video stream?
For video issues:
About video stream, it need the same slice between caller and callee normally. It is also a standard.
From the pcap file, server/doorphone send packetization-mode = 1 to phone (see screencapture 3), it means single slice. But we find Fanvil response multi slice (screencapture 4). And they establish a video normally, actually this is not up to the standard.
Meanwhile, we also modify the Yealink phone to single & multi slice and find Yealink phone call door phone noramlly, so we think it need multi slice to establish a normal video with server/doorphone.
Kindly note: packetization-mode = 0 (multi slice); packetization-mode = 1 (single slice); packetization-mode = 1,0 (single & multi slice)
packetization-mode = empty (multi slice)
Please check if the doorphone/server could send multi slice or single & multi slice to phone. If it could do so, the issue could be fixed.
I’ve found out that with direct ip the video preview is working as the yealink phone after the 183 send backt to doorphone INFO, but trought PBX this never happens, any help is appreciated.
Yes, if I signal a single phone, but I prefer to let a couple of phones ring. Meanwhile I prefer the setup where the door stations are also hooked up to a video server and I have monitors in several rooms so I always see what is going on outside and there are typically 2-4 different video streams visible.
Thank you for the reply @jgttgns, mine is a minimal setup, don’t have another video server.
I’ve started a topic on the asterisk forum specifically for the video preview, it’s seems that there’s not a single way to manage it, may I ask you a package log of sip flow from the axis and yealink?
For the ones how wonder how official Yealink support closed this case:
I've replied the Issue 2022-04-29 17:48:43
Thank you for your reply:
For issue 1:
1. I can confirm the 18x is not working on Fanvill too (but it is correct as the PBX isn't sending that SIP message), it display a black screen with the name of the caller, and when pickup it show immediately in full screen the fluid incoming video (user doesn't have to wait 5 seconds like on T58 for full screen).
2. Yealink option Enable Preview was already activated for all of the configured doorphone.
For issue 2: a public list of known working compatible devices would help in this case.
We've recently discovered that T58A that we've bought appositly for this project is obsolete and replaced by T58W.
Just few days ago we've spent 250€ for a technical course, that resulted in few commercial informations.
...
Thanks, BR
Received support reply today:
Discussed with our RD and PM team. Since our current commercial infromation is not enought to push our RD to change standard mechnism and do more unstandard compatible with 18x message. Hope your kind understanding.
Yealink: Never again.
P.s. never trust Certified IP engineers: distributors sells this piece of paper with a fake “advanced course”.
If Fanvil also doesn’t work, then it is even more likely a configuration error. Actually, initially it was pointed out that the 488 reply usually has to do with codec configuration problems. You never really checked that. If you do not supply the correct information and go through this step by step, you’ll never get anything to work that doesn’t work right out of the box. This is also not a site where help for commercial products is offered, i.e. you have to do the work yourself. You might get some useful information, though.
Main problem is that each phone vendor develop his closed operating system, with behaviors that are not known by itself.
I’m just trying to get the state of art, i.e. to get a working video preview:
RFC doesn’t say how video preview MUST be handled.
Yealink says should work with 18x, but it’s not a standard mechanism.
Fanvill can manage both codes: 18x (this is supposed to not work, as you can read in the asterisk post) and 2xx (with this method video preview works, but Yealink doesn’t offer this mechanism at all).
Akuvox: video preview on the Yealink works only on web call to direct ip that are not allowed to be executed with push button.
About the 488 reply I don’t understand how to debug it, Yealink support hasn’t reply anything about it at all.
The codecs I’m using with all of those devices are always the same:
ulaw:40&h264
For sure things need to be configured to work, can you please point me out to “the site where helo for commercial products is offered”?
I believed that phone vendor ticket system was supposed to manage this kind of informations.
There is no such thing. You need to study the SIP signalling messages and possibly the RTP streams. There are simply too many moving parts involved.
There are a number of websites that describe how to do analyze SIP messages. There are actually a number of options here as well. “pjsip set logger on” and “rtp set debug on” is sometimes sufficient. I myself like to have a HEP server (homer7) running in parallel so that I can get all the necessary information backwards if necessary. Other contributors here seem to have a preference for Wireshark/sngrep.
In essence, unless you provide your topology, your configuration and meaningful pcap traces everybody can only guess. That said, it is quite possible that the persons who answer are also still learning. I very recently found out that comedia is actually something entirely different than I thought it was. It is probably an iterative process in most cases and there is no “start of art” that just someone happens to know.
Thank you @jgttgns for reply, I believe sip flow trace are present in previous posts in this topic.
You’ve previously said that you’ve got working video preview, but didn’t provide any configuration template.
Anyway I was able to get video preview only with a 2N doorphone, and to do this an official user guide from Yealink exist.
I bellieve the only one that can turn to work some feature (like the video preview) is the manufacturer, you can be good in configuration as you can, but if the feature is not supported, there’s nothing to do.
