Replies: 2 comments
-
It'd be worth trying |
Beta Was this translation helpful? Give feedback.
0 replies
-
I looked into that, the dispose() method calls that with it's own reason string. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Something is persisting in the background after a call is answered, hung up, and then a new call is answered. It generates a lot of warning logs like these. The audio end point doesn't really have a way to discern if the RTP session it's trying to forward to is "closed" and as far as my code goes I don't think there should be anything left around after the first call ends.
It's probably some part of the Sip Sorcery stack I am using wrong.
So my question is, does anything in my SipClient stand out as obviously wrong for idling to handle incoming calls that would cause the SendRtpRaw warning?
2025-05-22 12:37:28.426 -05:00 [WRN] SendRtpRaw was called for a "audio" packet on a closed RTP session.
2025-05-22 12:37:28.427 -05:00 [DBG] [LocalVoiceAudioEndPoint] Forwarded encoded sample: 160 bytes, 160 RTP units
Here are the relevant parts of my sip client code,
Beta Was this translation helpful? Give feedback.
All reactions