【问题标题】:SIP to WebRTC call. SIP sdp body/message content anomaliesSIP 到 WebRTC 呼叫。 SIP sdp 正文/消息内容异常
【发布时间】:2015-07-01 17:44:12
【问题描述】:

所以,下面是我从 y.y.y.y (SIP) 呼叫时从 x.x.x.x (webRTC) 得到的响应。通话建立,但只有视频而不是音频,具有 100% 的一致性。 我的问题是有人知道正文中最后两个 sdp 标头是什么意思吗?为什么 x.x.x.x 最初会使用正确的端口和可用的编解码器做出响应,但随后又提出相反的建议:
"m=video 0 RTP/AVP
m=应用程序 0 RTP/AVP"

任何帮助将不胜感激:)
报价:

2015-04-20 18:54:32,291 : Inbound Message
Transport: TCP: ip=x.x.x.x, port=60118, secure=false

INVITE sip:1234@x.x.x.x SIP/2.0
Via: SIP/2.0/TCP x.x.x.x:5060;branch=z9hG4bKa877nh3hd5624lJ1o2E-pc16vl-1194
Via: SIP/2.0/TCP y.y.y.y:5060;branch=z9hG4bKa877nh3hd5624lJ1o2E-pc16vl;rport=49528
From: "Alacrity City" <sip:2312@y.y.y.y>;tag=14295560721021025240-F--5c-4f-6a-11
To: <sip:1234@x.x.x.x>
Contact: <sip:2312@y.y.y.y;transport=tcp>
Call-ID: -119405323313131523-c16c-B2BUA@y.y.y.y
CSeq: 1 INVITE
Supported: timer,sip-stun,outbound,replaces
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,REFER,NOTIFY,UPDATE,MESSAGE
Max-Forwards: 69
User-Agent: M
X-FS-Support: update_display
Session-Expires: 1800;refresher=uac
Content-Type: application/sdp
MSS_Initial_Remote_Addr: y.y.y.y
MSS_Initial_Remote_Port: 49528
MSS_Initial_Remote_Transport: tcp
Content-Length: 1304
v=0
o=Magor 1429539042 1429539044 IN IP4 y.y.y.y
s=Magor
c=IN IP4 y.y.y.y
b=TIAS:2048000
b=AS:2048
b=CT:2048
t=0 0
m=audio 20052 RTP/AVP 115 9 120 6 70 0 8 99 97 112 101
a=rtpmap:115 G7221/32000
a=fmtp:115 bitrate=48000
a=rtpmap:9 G722/8000
a=rtpmap:120 SILK/24000
a=fmtp:120 useinbandfec=1; usedtx=0
a=rtpmap:6 DVI4/16000
a=rtpmap:70 L16/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:99 isac/32000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:112 opus/48000/2
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
m=video 20056 RTP/AVP 96 97
b=TIAS:2048000
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016; max-fs=8192; max-mbps=244800
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=64e016; max-fs=8192; max-mbps=244800
a=content:main
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=rtcp-fb:* nack pli
m=video 20060 RTP/AVP 96 97
b=TIAS:2048000
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016; max-fs=8192; max-mbps=244800
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=64e016; max-fs=8192; max-mbps=244800
a=content:slides
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=rtcp-fb:* nack pli
m=application 20064 UDP/BFCP *
a=floorctrl:c-only
a=setup:passive
a=connection:new
a=bfcpver:1

回复:

2015-04-20 18:54:35,523 : Outbound Message  
Transport: TCP: ip=x.x.x.x, port=60118, secure=false  

SIP/2.0 200 OK  
To: <sip:1234@x.x.x.x>;tag=7-mobi-15398169_ada14cd5_e63f04c4-9dbc-4e91-b908-fa42b01af3e4_3  
Via: SIP/2.0/TCP x.x.x.x:5060;branch=z9hG4bKa877nh3hd5624lJ1o2E-pc16vl-1194;rport=60118  
Via: SIP/2.0/TCP y.y.y.y:5060;branch=z9hG4bKa877nh3hd5624lJ1o2E-pc16vl;rport=49528  
CSeq: 1 INVITE  
Call-ID: -119405323313131523-c16c-B2BUA@y.y.y.y  
From: "Alacrity City" <sip:2312@y.y.y.y>;tag=14295560721021025240-F--5c-4f-6a-11  
Contact: <sip:x.x.x.x:5060;transport=tcp>  
Content-Type: application/sdp  
Min-SE: 400  
Session-Expires: 1800;refresher=uac  
Allow: UPDATE,ACK,INVITE,PRACK,CANCEL  
Require: timer  
Supported: timer,100rel  
Content-Length: 542  

v=0  
o=- 2017325266 1 IN IP4 z.z.z.z (internal IP of server x.x.x.x)  
s=-  
c=IN IP4 x.x.x.x    
t=0 0  
m=audio 17050 RTP/AVP 112 101  
a=rtpmap:112 opus/48000/2  
a=fmtp:112 minptime=10  
a=rtpmap:101 telephone-event/8000  
a=sendrecv  
m=video 17002 RTP/AVP 97  
a=rtpmap:97 H264/90000  
a=fmtp:97 profile-level-id=42801E;packetization-mode=0;level-asymmetry-allowed=1  
a=rtcp-fb:97 nack  
a=rtcp-fb:97 ccm fir  
a=rtcp-fb:97 nack pli  
a=rtcp-fb:97 ccm tmmbr  
a=sendrecv  
a=imageattr:97 send [x=480,y=640] recv [x=480,y=640]  
m=video 0 RTP/AVP    
m=application 0 RTP/AVP   

----------------------------

【问题讨论】:

  • 你能发布报价 SDP 吗?
  • 已添加,上面有完整的报价和回复。
  • 你们是如何实施 BFCP 的?

标签: call webrtc sip sdp mobicents-sip-servlets


【解决方案1】:

RFC 3264 Section 6

对于报价中的每个“m=”行,必须有一个对应的“m=” 答案中的行。答案必须包含完全相同的数字
“m =”行作为报价。这允许匹配流 根据他们的顺序。这意味着如果报价包含零
"m=" 行,答案必须包含零 "m=" 行

无论出于何种原因,提供的流都可能在答案中被拒绝。 如果流被拒绝,提供者和回答者不得生成 该流的媒体(或 RTCP 数据包)。拒绝提供的
流,答案中对应流中的端口号
必须设置为零。列出的任何媒体格式都将被忽略。至少 按照 SDP 的规定,必须存在一个。

还有RFC 3264 Section 8.2

通过创建一个新的 SDP 来删除现有的媒体流
该流的端口号设置为零。流描述可能
省略之前存在的所有属性,并且可以只列出一个
媒体格式。

所以我猜你提供的是

  • 一个音频流(被接受)
  • 一个视频流(被接受)
  • 第二个视频流(被拒绝)
  • 一个应用程序流(被拒绝)

不完全确定为什么拒绝第二个视频流会导致第一个视频流不显示或不被使用。

【讨论】:

  • @hipkiss, o= 行,只有一个,因为它描述了会话。 c= 行可以在顶层(即在任何m= 行之前)作为任何媒体流的默认值或特定于媒体流(即在m= 行之后)参考Section 5.7 of RFC4566
  • 好的,所以检查报价,您的假设确实是正确的。将此调用的日志与之前使用不同客户端的日志进行比较,会得到包括以下行的响应:a=fmtp:112 minptime=10 但这一切都会导致视频正常工作而音频不工作.感谢您提供 RFC 参考资料。
  • 我仍然掌握不按 Enter 键的窍门!哈哈。我意识到 o= 和 c= 不需要重复。
【解决方案2】:

@jsantander,感谢您提供更多信息。它让我意识到音频编解码器的报价和响应实际上并不匹配,分别是 opus 和 PCMU,因此没有建立该流。我知道问题表明情况并非如此,但是当通过媒体经纪人从基本层面上看电话时,情况就很明显了。

设置 opus priority 编解码器用于在客户端之间建立音频流已导致在几十个呼叫中建立 100% 的音频流。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2010-11-20
    • 1970-01-01
    • 2014-12-07
    • 2011-08-26
    • 2015-11-12
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多