Custom Query (2195 matches)

Based on the ​RFC 3265:

A NOTIFY request is considered failed if the response times out, or a non-200 class response code is received which has no "Retry-After" header and no implied further action which can be taken to retry the request (e.g., "401 Authorization Required".)

However, our current implementation terminates the subscription for ALL non-200 with no retry-after, even for 401/407, which shouldn't be the case.

Reported that when calling a video echo server and video is switched off and on repeatedly every ~10s, sometimes there are issues like:

• taking a while for incoming video echo to be shown after video restart,
• frame rate hiccups after video restart, e.g: a video frame is shown, but then stopped still for sometime, then resumed with higher frame rate (catching up the delay), and eventually played at normal frame rate.

Log file showed strange frame rate change events:

Decoding format changed: 352x288 I420<- 90000/431010(~0)fps
Decoding format changed: 352x288 I420<- 90000/365760(~0)fps
...or..
Decoding format changed: 352x288 I420<- 90000/2610(~34)fps
Decoding format changed: 352x288 I420<- 25/1(~25)fps

Currently the video stream continuously performs frame rate detection, and it should only publish a format-changed event when frame rate is increasing. But the log shows that it also publishes a format-changed event even when it sees frame rate down to zero, which should not happen.

Thank you Giorgio Alfarano for the report.

When pjsua_handle_ip_change() is called, update contact might be done after listener restart. If listener restart fail, then updating contact should not be attempted since it will also fail.