我在启动媒体会话并将其与 SIP 客户端结合时遇到问题。我设计了一个递归 SIP 客户端，它根据 RFC 中注明的可接受序列以及我阅读的示例，重用相同的请求模板将下一个请求发送到服务器。据我所知，SIP 部分工作正常，可以向服务器邀请进行注册并进行身份验证。我还没有完成对客户端的任何调用，因为需要填写内容标头（我还没有填写，所以我从服务器收到了 503，我猜这是可以的）。
很长一段时间我不知道从哪里开始媒体会话，慢慢学会了如何使用JMF，并且我构建了一个处理RTP传输的对象，现在我站在十字路口，在一个一方面我有 SIP 信令，但它需要 SDP 内容标头来完成邀请，另一方面我有 RTP，它知道如何进行 p2p。
为了完成我的设计，我需要您帮助解决以下问题：
-
是否有简单//简单//实施 将音频/视频格式从 JMF 转换为 SDP 媒体头的方法？甚至是一个生成器，我可以输入内容标题的所有参数，它会快速生成内容标题，还是我必须自己实现这个？
-
一旦我完成了 SDK 的构建并且 SIP 已启动并运行，并且我从服务器收到了 OK 响应（在响铃之后），我该如何启动媒体会话？我是否根据我在 SIP 邀请中发送的呼叫者详细信息连接 p2p？
-
如果 2 正确，那么如何连接到固定线路？陆地线路是否知道一旦它们将 OK 发送回服务器，它们就会在特定端口上侦听/启动 RTP 会话？
还是我把一切都搞错了？ :-/
我真的很感谢我能得到的任何帮助，我到处寻找答案，但他们不清楚，他们忽略了问题 2，好像这是一个显而易见的事情，但对我来说，事实并非如此。
预先感谢，
亚当·泽哈维.
补充：
首先感谢您的回复以及您花时间帮助我。
我回到问题2：
一旦您收到“Ok”响应，您就会知道 SIP 用户代理服务器 (UAS) 正在侦听的 IP 套接字（您的意思是 ADDRESS:PORT 正确吗？）以及它接受的编解码器可以开始发送您的 RTP。
好的，我明白了，我想知道另一件事，在我向 UAS 发送 RTP 数据包的对话时间内，UAS 用作两个 UAC 之间的桥梁。
现在...我可以使用 SIP 实例化会话，然后将客户端信息从一台计算机发送到另一台计算机，并在两台计算机之间建立 P2P，无需任何中间人（UAS），然后处理 SIP 会话吗？
我希望我现在能更好地解释自己......
谢谢，
亚当.
I have a problem with starting a media session and to combine it with my SIP client. I've designed a recursive SIP client that reuse the same request template to send the next requests to server, according to the acceptable sequences noted in the RFC's, and examples that I read. as far as I could tell the SIP part is working fine registers to server invites, and authenticates. I didn't complete any calls to clients yet because of the content header needs to be filled up (which I didn't yet so I get a 503 from the server which is OK I guess).
for a long time I didn't know where to start with the media session, and slowly learned how to use the JMF and I've constructed an object that handles RTP transmitting, now I'm standing at the cross road, on the one hand I have my SIP signaling but it needs the SDP content header to complete the invite, and on the other I have the RTP which is knows how to p2p.
For me to complete my design I require your help with the following questions:
-
Is there an easy//a simple//an implemented way to convert the Audio/Video format from the JMF into SDP media headers? or even a generator that I would input all the parameters for the content header, and it would generate a content header fast, or do I have to implement this myself?
-
Once I've finished constructing the SDK and the SIP is up and running and I get an OK response from the server (after ringing and all), how do I start the media session? do I connect p2p according to caller details I send in the SIP invite?
-
If 2 is correct, then how does a connection to land lines would be? does land lines knows that once they send an OK back to server they listen/start RTP session on a specific port?
Or did I get everything wrong? :-/
I really appreciate any help I could I get, I looked every where for answers but they are not clear, they ignore question 2 as if it was an obvious thing, but for me it just isn't.
Thank in advance,
Adam Zehavi.
Added:
First thank you for you response and the time you take to help me.
I'll go back to question 2:
once you get an Ok response you will know the IP socket(you mean the ADDRESS:PORT correct?) that the SIP user agent server (UAS) is listening on and the codecs it accepts and can start sending your RTP.
Ok that I understand, I wanted to know another thing, during this conversation time that I send RTP packet to the UAS, the UAS uses as a bridge between both UAC's.
Now... could I instantiate the conversation using SIP, and then send the clients information from one to the other and establish P2P between two computer, without any middleman(UAS), and then dispose of the SIP session?
I hope I explained my self better now...
Thanks,
Adam.
发布评论
评论（1）
对于1，我对JMF一无所知，所以无法直接回答，但SDP实际上并不是一个复杂的标准，与SIP不同，因此构建SDP数据包应该不那么困难。构建 SDP 数据包至少需要您提供的编解码器以及您接受 RTP 的 IP 套接字。
对于 2，一旦您收到 Ok 响应，您就会知道 SIP 用户代理服务器 (UAS) 正在侦听的 IP 套接字及其接受的编解码器，并且可以开始发送 RTP。同时，您应该开始从 UAS 接收 RTP，因为它会在发送 Ok 的同时开始发送。当然，您还需要发送 SIP ACK 请求来响应 Ok 响应，否则某些 UAS 会认为响应未通过，并在一段时间后终止呼叫。如果您刚刚开始编写自己的 SIP 堆栈，那么还有很长的路要走！
对于 3，是的，尽管固定电话实际上指的是 SIP 到 PSTN 网关（PSTN 端将类似于 ISDN、SSL 或模拟）。 PSTN 网关的 SIP 端与任何其他 SIP UAS 相同，一旦它接受 INVITE 请求，它将开始向请求中指定的套接字发送 RTP，同样将开始在它放置在 Ok 中的套接字上侦听 RTP响应将被发送回您的 SIP 客户端。
更新
答案是肯定的，但您有点混淆了术语。已建立的 SIP 呼叫称为会话，并且始终位于用户代理客户端 (UAC) 和用户代理服务器 (UAS) 之间。每个 SIP 代理都应该能够充当 UAC 或 UAS 角色，这两个角色之间的主要区别在于 UAC 发起呼叫，UAS 应答呼叫。特定的 SIP 设备将在其发起的呼叫中担任 UAC 角色，在其应答的呼叫中担任 UAS 角色。
为什么此 UAC 和 UAS 描述相关？因为所有 SIP 通信都是点对点的。 SIP 不是客户端/服务器协议。这是一个点对点协议。现在它确实变得令人困惑，因为您将拥有运行 SIP 代理服务器 或 SIP PSTN 网关 的 VoIP 提供商，这使得 SIP 看起来好像确实在客户端-服务器模型上运行但事实并非如此。
所以我认为您实际上想问的问题是 UAC-to-B2BUA-to-UAS 之间是否可以进行 SIP 呼叫（这实际上是两个单独的呼叫或 SIP 会话：UAC-to-UAS/UAC-to-UAS）让媒体绕过 B2BUA，而是直接在两端的 UAC 和 UAS 之间传输。这个问题的答案是肯定的。像 Asterisk 这样的 B2BUA 有一个名为 canreinvite 的 SIP 配置选项，如果设置为 yes，将导致在应答后向呼叫的任一端发送 re-INVITE，以使 RTP 直接在呼叫端点之间流动，而不是通过自身桥接当然，如果需要编解码器转码、录制或等效功能，它不会尝试重新邀请。另一种不同的方法是传统的 SIP 代理方法，例如 OpenSER 使用的方法，它根本不是为了桥接媒体而设计的，并且通过它进行的所有呼叫始终会导致 RTP 直接位于呼叫两端的 SIP 设备之间。工作方式是 OpenSER 简单地将从 UAC 收到的请求转发到 UAS，除了添加和/或修改一个或两个额外的 SIP 标头之外，INVITE 请求就像 UAC 直接将其发送到 UAS 一样。
一切都像泥一样清澈吗？以下是一些可以帮助您进一步阅读的链接。
Tech-invite - 非常好的 SIP 场景示例，
RFC5359 会话启动协议服务示例 - 更多示例，
SIP 巫术论坛 - 我运营的公共服务论坛网站，如果您需要更深入的 SIP 问题，一些了解 SIP 事务的人会经常光顾该网站。
For 1, I don't know anything about JMF so can't answer directly but SDP is not actually a complicated standard, unlike SIP which is, so constructing an SDP packet shouldn't be that difficult. The minimum you need to build an SDP packet are the codecs you're offering and the IP socket you're accepting the RTP on.
For 2, once you get an Ok response you will know the IP socket that the SIP user agent server (UAS) is listening on and the codecs it accepts and can start sending your RTP. At the same time you should start receiving RTP from the UAS as it will start sending at the same time it sends the Ok. Of course you will also need to send a SIP ACK request in response to the Ok response otherwise some UAS's will assume the response did not get through and after some time will terminate the call. If you're just starting to write your own SIP stack there's still a long way to go!
For 3, yes, although by landlines you really mean a SIP-to-PSTN gateway (the PSTN side will be something like ISDN, SSL or analogue). The SIP side of the PSTN gateway is the same as any other SIP UAS and once it accepts an INVITE request it will start sending RTP tp the socket specified in the request and likewise will start listening for RTP on the socket it has placed in the Ok response that will be sent back to your SIP client.
Update
The answer is yes but you are confusing the terminology a little bit. An established SIP call is known as a session and is always between a User Agent Client (UAC) and a User Agent Server (UAS). Every SIP agent is supposed to be capable of acting in either role as a UAC or UAS and the main difference between the two roles is that a UAC intiates the call and the UAS answers it. A particular SIP device will be in a UAC role for calls it initiates and a UAS role for calls it answers.
Why is this UAC and UAS description relevant? Because all SIP communications are peer-to-peer. SIP is NOT a client/server protocol. It's a peer-to-peer protocol. Now it does get confusing because you'll have VoIP providers that operate SIP Proxy Servers or SIP PSTN Gateways which make it seem as if SIP does operate on a client-server model but it doesn't.
So I think the question you are actually wanting to ask is can a SIP call between a UAC-to-B2BUA-to-UAS (which is actually two separate calls or SIP sessions: UAC-to-UAS/UAC-to-UAS) have the media bypass the B2BUA and instead travel directly between the UAC and UAS at either end. The answer to that question is yes. A B2BUA like Asterisk has a SIP configuration option called canreinvite which if set to yes will result in it sending re-INVITEs to either end of the call once it's answered to get the RTP to flow directly between the call endpoints rather than being bridged through itself, of course if codec transcoding, recording or an equivalent feature is required it will not attempt the re-INVITE. A different approach is a traditional SIP Proxy approach such as used by OpenSER where it's not designed to bridge media at all and all calls through it will always result in the RTP being directly between the SIP devices at either end of the call. The way that works is OpenSER will simply forward the request it receives from the UAC through to the UAS and apart from adding and/or modifying an extra SIP header or two the INVITE request is exactly as if the UAC had sent it directly to the UAS.
All clear as mud? Here's some links to further reading that will help you.
Tech-invite - very good examples of SIP scenarios,
RFC5359 Session Initiation Protocol Service Examples - more examples,
SIP Sorcery forums - forum site for a public service I run which is frequented by a few people knowledgeable on SIP matters if you should have more in depth SIP questions.