SRS早就具备了SFU的能力，比如一对一通话、多人通话、直播连麦等等。在沟通中，一对一是常用而且典型的场景，让我们一起来看看如何用SRS做直播和RTC一体化的一对一通话。
SRS对音视频的媒体抽象是流（Stream），前一篇《劳动节之一：SRS中RTC基于流的场景应用，RTC和RTMP流互相转换》做了详细介绍，仔细考虑下完全可以支持各种直播和RTC的业务场景，而且这是非常合理的云架构的直播和RTC一体化的服务抽象。
今天通过一系列的DEMO和Wiki（请点文末阅读原文直达Wiki），可以了解如何使用SRS的不一样的更合理的SFU能力：目前音视频需要的是一个直播和RTC一体化的开源架构。
先看疗效
在本机启动一对一的DEMO，打开两个页面：
注意这个不是WebRTC推流和播放，而是两个人一对一的通话。
这个DEMO可以在内网打开，将localhost换成IP就可以，当然也可以部署在公网上，不过要注意设置SRS的Candidate，以及使用HTTPS和WSS，详细请参考Wiki：
https://github.com/ossrs/srs/wiki/v4_CN_WebRTC#sfu-one-to-one
纠结的信令
SRS的定位一定是做媒体流的处理，信令是一个非常业务的能力，SRS应该内置一个信令，还是外挂信令（新建另外一个项目）？我们在SRS技术委员会展开了讨论。
SRS内置信令会导致SRS变复杂，而内置的信令由于功能不足，也难以真正使用，就像GB28181的简单SIP信令，方便把DEMO跑起来，但是最终还是需要自己实现SIP信令。
外挂信令让SRS保持媒体处理的能力，可以解耦媒体和信令，信令和SRS之间可以没有强依赖关系。客户端可以推流后，将推流的状态更新到信令，这样信令就不依赖于SRS的回调。客户端的WS断开，可以认为是客户端关闭了页面，当然更好的做法是使用超时。
信令是和业务耦合非常紧的，如果是快速DEMO可以用非常简单的信令，而不同场景下可能也使用不同的信令，因此外挂信令可以非常灵活的适应各种不同场景的DEMO。我们最终选择了外挂信令的方式，如下图所示：
如果是本机(localhost)访问，那可以走左边链路，用HTTP和WS访问。
如果是非本机访问，比如局域网访问，或者部署在公网，则必须走右边链路，额外部署一个httpx-static，支持HTTPS和WSS。
signaling和httpx-static这两个项目，代码都放在了SRS的3rdparty目录，不依赖网络就可以编译（依赖Go环境），参考：
https://github.com/ossrs/srs/wiki/v4_CN_WebRTC#sfu-one-to-one
单流转直播
也可以开启WebRTC转RTMP，将每路流转成RTMP直播，请参考之前的文章《劳动节之一：SRS中RTC基于流的场景应用，RTC和RTMP流互相转换》。
合流转直播
可以将一对一通话的流，合并成一个直播流，对外广播，这个话题会在后续会议转直播的文章中给出，请关注公众号的推送。
