Add late SDP answer support for inbound calls. - #820
Conversation
There was a problem hiding this comment.
Note
This report is out of date. Scroll down for Devin Review's latest report on this PR.
Devin Review found 1 potential issue.
1 flag not posted on this PR by your GitHub settings — view it in Devin Review. (Configure)
| // Encryption is picked here, before the room is selected. | ||
| answerData, err = c.negotiateMedia(rawSDP) | ||
| var sdpResponseBody []byte | ||
| expectingLateAnswer := len(rawSDP) == 0 |
There was a problem hiding this comment.
Note
This report is out of date. Scroll down for Devin Review's latest report on this PR.
Devin Review found 2 new potential issues.
2 flags not posted on this PR by your GitHub settings — view them in Devin Review. (Configure)
109daae to
dde2f94
Compare
There was a problem hiding this comment.
Devin Review found 1 new potential issue.
2 flags not posted on this PR by your GitHub settings — view them in Devin Review. (Configure)
alexlivekit
left a comment
There was a problem hiding this comment.
Nice. Mostly a bunch of nits, but one concern to map out.
| if c.media.NegotiatedAudio() != nil { | ||
| return nil | ||
| } |
There was a problem hiding this comment.
Highly unexpected, no?
Can this happen on a re-invite?
There was a problem hiding this comment.
Yeah, this seems pretty unlikely and would involve a re-invite. We'd need to see a sequence like:
- INVITE comes in without an offer.
handleInvitesends an offer and waits for an ACK - A second INVITE comes with both an offer and a higher cseq than the first invite, and so
updateRemoteFromSDPis invoked, which sets up media. - ACK comes in for the first invite,
negotiateMediaForLateAnsweris eventually invoked, and this branch is hit.
Per spec, I think it's illegal for a client to send a second, new invite while the first invite's transaction hasn't closed, but, this is still probably something we should guard against. This would also affect initial INVITEs with offers, too. Given that this is a pre-existing thing, maybe we add guards against this in a follow-up PR?
alexfish8
left a comment
There was a problem hiding this comment.
thanks for the review!
| if c.media.NegotiatedAudio() != nil { | ||
| return nil | ||
| } |
There was a problem hiding this comment.
Yeah, this seems pretty unlikely and would involve a re-invite. We'd need to see a sequence like:
- INVITE comes in without an offer.
handleInvitesends an offer and waits for an ACK - A second INVITE comes with both an offer and a higher cseq than the first invite, and so
updateRemoteFromSDPis invoked, which sets up media. - ACK comes in for the first invite,
negotiateMediaForLateAnsweris eventually invoked, and this branch is hit.
Per spec, I think it's illegal for a client to send a second, new invite while the first invite's transaction hasn't closed, but, this is still probably something we should guard against. This would also affect initial INVITEs with offers, too. Given that this is a pre-existing thing, maybe we add guards against this in a follow-up PR?
|
Still need to write tests and handle the ACK issue. |
|
PR updates:
|
acceptCallfunction variable (defined inhandleInvite)acceptCallAndWaitForMedia,acceptCall, andwaitForMedia