SIP для вызова WebRTC. SIP sdp body/анонсы содержимого сообщения

Question

Итак, ниже ответ получен от x.x.x.x (webRTC) при звонках из y.y.y.y (SIP). Вызов устанавливает, однако, только с видео, а не с аудио, с 100% -ной согласованностью. Мой вопрос: кто-нибудь знает, что означают последние два заголовка sdp в теле? Почему хххх реагирует первоначально с соответствующими портами и доступными кодеками для использования, но затем также свидетельствует об обратном:
«м = видео 0 RTP/AVP
м = приложение 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 

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

Answer 1

В RFC 3264 Section 6

Для каждого «т =» линии в предложении, должен быть соответствующий «м =» линия в ответ. Ответ ДОЛЖЕН содержать точно такое же число
линий «m =» в качестве предложения. Это позволяет сопоставлять потоки по их заказу. Это означает, что, если предложение содержали ноль
«м =» линии, ответ должен содержать ноль «т =» линия

и

Предлагаемый поток может быть отклонен в ответ, для любая причина. Если поток отклонен, оферент и ответчик НЕ ДОЛЖНЫ генерировать носители (или пакеты RTCP) для этого потока. Чтобы отклонить предложенный поток
, номер порта в соответствующем потоке в ответе
ДОЛЖЕН быть установлен на ноль. Любые медиаформаты, перечисленные, игнорируются. По крайней мере один ДОЛЖЕН присутствовать, как указано SDP.

Также RFC 3264 Section 8.2

Существующие мультимедийные потоки удаляются путем создания нового SDP с номером
порта для этого потока, установленным на нуль. Описание потока MAY
опустить все атрибуты, представленные ранее, и МОЖНО перечислить только один формат
.

Так что я думаю, что вы предлагаете

• один звуковой поток (который получает принятый)
• один видеопоток (который получает принято)
• второй видеопоток (который отвергается)
• один поток приложения (который отвергается)

Не е совершенно очевидно, почему отказ от второго видеопотока заставляет первый видеопоток не отображаться или не использоваться.

Answer 2

@jsantander, благодарю вас за дополнительную информацию. Это заставило меня понять, что предложение и ответ на аудиокодеки на самом деле не совпадают, opus и PCMU соответственно, и поэтому не установили этот поток. Я знаю, что в этом вопросе говорится, что дело обстоит не так, но при взгляде на вызов на базовом уровне через посредника средств массовой информации стало очевидным.

Установка Opus в приоритете кодека для создания звуковых потоков между клиентами привела к аудиопотоку созданию 100% в течение нескольких десятков звонков.