4 Dec
2020
4 Dec
'20
9:36 p.m.
Hmm..that's interesting. You would guess that the rtpengine binary process
shouldn't start connecting ICE candidates once the SIP part is fully
negotiated, which should trigger the rtpengine module on the Kamailio to
tell rtpengine binary.."ok..you can start associating now..."
On Fri, Dec 4, 2020 at 1:30 PM Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 04/12/2020 13.10, Andrew Chen wrote:
--
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
achen@ <achen(a)thinkingphones.com>fuze.com
--
*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*
So from a SIP point of view, the 200 OK should of
sent the final
negotiation of SDP once the client ACK's it right?
The requirement to send an updated offer once ICE has completed with the
final negotiated candidates existed in the original ICE RFC, but I
believe it has been removed in the newer ICE RFC (I'm not 100% sure
about that though). For rtpengine that requirement certainly doesn't
exist and it's happy to negotiate and conclude ICE without a final
updated offer. Also rtpengine itself cannot trigger such an updated
offer since it's not directly in the SIP path, so that would have to be
left up to the clients. So in short, a single offer/answer exchange is
enough to get ICE started and it can complete negotiation out of band
without further signalling.
Cheers
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users