4.14.媒体协商

那今天呢?我们来看一下是如何进行媒体协商的。开始之前呢,我们再来回顾一下媒体协商的过程。这张图呢,展示的就是媒体协商的过程,那通过这张图,我们可以看到那第一步呢,它首先要调用create offer。创建offer信息对吧?那创建完offer信息之后呢?进行第二步调用set local description。

将offer信息设置到自己的缓存中之后,再将这个信息发送给被呼叫端。当被呼叫端收到这个信息之后呢,首先调用set remote description,将它也缓存到自己的本地缓存中。然后调用create answer创建应答消息。当应答消息创建好之后,执行第六步也就是set local description这样的呼叫端,就可以进行媒体协商了。然后调用s将应答消息传回呼叫端,呼叫端收到answer消息之后,调用remote description。开始媒体协商,这就是整个媒体协商的一个完整的过程。一共通过八步对吧?

其中比较关键的是creo fer。create answer set local description以及set remote description这四个函数,那相信大家对这个过程啊,已经十分了解了,对吧?我们今天只是简单再回顾一下好,那除此之外呢,我们还要了解一个接口类,这个类呢,就是create session。它有两个方法,第一个方法呢,是on success,第二个方法呢,是on filler,

它的意思是当我们创建offer或者answer消息的时候呢?如果成功了,就会回调on success,失败了呢,就会调用on filler,这就是它两个接口的这个作用。那了解了这个接口类之后呢,我们再来看看谁是它的实现实际,我们猜也能猜到对吧?就是conductor它是继承自。create session description,observe接口类。所以,在conductor中呢,一定是实现了on success和on filler这两个接口。

那还有一个关键的信息是在create offer的时候来指定回调接口对象,实际上就是把conductor对象当做一个参数。传入到create offer API中,这样当我们创建offer成功的时候,就会回调on success这个接口。好,了解完这个信息之后呢,我们接下来再来看一下时序图,我们要知道啊,媒体协商的过程是在多个线程之间完成的。就是这张图所展示的这样。那一开始的时候呢,我们是在主线程调用create offer来创建offer信息的,但在create offer API内部呢。会进行一次线程的切换,

那个时候呢,它会切换到子线程,进行真正的offer消息的构造。当offer消息构造好之后呢,它会回调on success,这个API将offer消息传回应用层。在此时,我们要知道。on success函数是在子线程中执行的,也就是说,对于conductor对象来说呢,它有一部分代码是在主线程中运行,有一部分代码呢是在子线程中运行。而回调接口on success就是在子线程中完成的,那在on success中呢?

它会调用site local description,首先将offer信息保存到自己的缓冲区中。对吧,之后呢,调用send message将offer信息呢,传给新令服务器。OK当被呼叫端发送wait信令,到信令服务器的时候呢?信令服务器就会将呼叫端传给它的offer消息。返回给被呼叫端,通过这张示意图呢,我们可以知道媒体的协商过程是在不同的线程中完成的,每一个线程呢,都完成它自己的那一部分。对吧,

这就是我们这张示意图主要表达的含义好,最后呢,我们再来看几个关键点,那第一个关键点呢,就是我们什么时候?调用create offer对吧?那实际呢?就是调用connect to peer这个方法的时候去调用create offer是最好的时机。那对于这个API实际,我在前面已经向你做过介绍了,这个函数的作用实际上就是向对端发送offer answer candidate等这一类消息,对吧?那第二个关键点呢是on success,也就是说当我们调用create offer创建offer信息成功之后呢?fr tc底层呢?

会回调on success,这个回调接口。这是第二个关键点好,第三个关键点呢是on message from peer通过这个函数的名字,我们也可以知道。它就是从服务端获取对端给我们发来的消息offer answer,以及candidate这一类的消息,对吧?那了解了这三个关键的API之后呢啊,我们现在就来看一下peer connection client端。它代码是如何实现的?好,我们在介绍代码之前呢,先在刚才介绍的几个关键函数的地方设置断点,这样更有利于我们进行后面的分析,

对吧?第一个呢,是connect图片。OK,那我们先在这块儿呢,设一个断点,这是第一个断点,那第二个断点呢是on success。好在这我们也设置一个断点,那第三个呢是?from好在这个函数这儿呢,我们也设一个断点OK?那下面呢,我们就可以进行单步调试了,对吧?

首先将程序运行起来。先连接新令服务器,我们选中一个要连接的端点,之后我们就来到了connect to pier这个API。实际这个API呢,我们在前面儿都做过一次介绍了,那这次呢,我们关注的是它是如何进行媒体协商的是吧?我们弹幕执行那一开始的时候呢,它会调用initialize peer connection这个API。那在这个API中呢?它会将peer connection对象创建好,当peer connection对象创建成功之后呢,就进入到。if语句里边儿,

那在这个函数里边儿呢?会调用create offer这个API。我们继续执行啊。那当我们调用create offer API的时候。我们可以知道,它要传入两个参数,那第一个参数呢,就是observe这个对象的类型是create session description observe。那实际上就是在创建offer的时候,我们要给它传入一个观察者,当我们创建offer成功之后呢,它就会通过观察者。将我们构造好的offer消息。传回给应用。所以这个observe的作用就是拿到底层创建好的offer。

我们再回到create offer调用的这个语句,可以发现它的observe参数呢,就是this。而这次是谁呢?就是conductor对象,所以当offer创建成功之后呢,一定会回到conductor对象的on success这个API。那刚才呢?我们已经在on success设置了断点。当创建成功之后呢,程序呢,就会跳到on success处执行好,这是第一个参数,那第二个参数呢,就是我们要构造消息的类型,

我们再回去看一下啊。那在这里呢,我们设置的是rt coffer answer options函数,通过这个函数呢,它就会自动返回一个合适的类型,继续执行,当offer创建成功之后呢。就会回调on success这个API在on success中呢,它第一步执行的是peer connection site local description。将创建的offer类型的消息设置到内存中,这与我们前面介绍的媒体协商的过程的步骤是一致的。当offer设置好之后呢,它会调用这些对象,将offer消息呢。放到json中,

最后呢,调用send message,将这个消息发送出去,好最后一个呢,是on message from peer,这个是什么时候触发呢?当对端收到我们的offer消息之后。会创建answer,并且把answer呢传回给呼叫方。那这个时候我们就可以通过on message from peer来获取到对方发送来的answer消息了,对吧?好,我们单步执行一下。在收到对方发回的answer消息之后呢,这个API首先还是通过json对象对消息进行解析。

解析好之后呢,我们就可以看到,目前我们拿到的就是一个消息,对吧?那接着它会根据对方发来的消息,重新构造一个sdp消息。那有了这个对象之后呢,就会调用set remote description将这个消息呢设置到缓存区中。最终呢,在底层进行媒体协商对吧?那当然,他在这里边儿呢,还要做一下判断,如果传来的消息类型是offer。也就是说,

我们本端是被呼叫端的时候,它要调用create answer去创建一个answer消息,对吧?那如果我们是呼叫端,此时呢,我们收到的就是暗示消息,所以这一步呢,就不会执行,那直接就向下执行了是吧?那至此呢,整个媒体协商的这个过程就算完成了,那通过上面的讲解呢,你应该已经知道整个媒体协商的过程其实还是非常简单的。对吧,那在我们整个媒体协商过程中啊,

有一点是难以理解的,就是整个的媒体协商是由不同的线程组合完成的。而不是像我们想象的是顺序完成的,这可能是大家理解起来稍微有一点儿难度的地方。不过,通过上面的介绍,相信你已经清楚,那它什么地方是在主线程中执行的,什么地方是在子线程中执行的。那我们知道这些之后呢?我们在进行媒体协商的时候,就知道该怎么做了,那以上呢?就是我们这节课内容,那在这节课中呢?

我主要是带你又重新回顾了一下媒体协商。它的一个过程之后呢重点向你介绍了整个媒体协商,它是需要多个线程来完成的。那最后呢,是带大家看了一下peer connection clan端是如何进行媒体协商的?那这样一个完整的过程,大家应该非常清楚了。那有任何的问题呢,你可以到讨论区或者是群里去给我留言,我在那里呢,给你做详细解答,那我们今天呢,就到这里,谢谢。

你可能感兴趣的:(webrtc)