2

So, below is the response I get from x.x.x.x (webRTC) when calling from y.y.y.y (SIP). The call establishes, however only with video and not audio, with 100% consistency. My question is does anyone know what the final two sdp headers in the body mean? Why does x.x.x.x respond initially with proper ports and available codecs to use but then also suggest the opposite:
"m=video 0 RTP/AVP
m=application 0 RTP/AVP"

Any help would be greatly appreciated :)
The offer: 

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

The response: 

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   

----------------------------
jeand
  • 2,325
  • 14
  • 12
hipkiss
  • 197
  • 2
  • 19

2 Answers2

2

In RFC 3264 Section 6

For each "m=" line in the offer, there MUST be a corresponding "m=" line in the answer. The answer MUST contain exactly the same number
of "m=" lines as the offer. This allows for streams to be matched up based on their order. This implies that if the offer contained zero
"m=" lines, the answer MUST contain zero "m=" line

and

An offered stream MAY be rejected in the answer, for any reason. If a stream is rejected, the offerer and answerer MUST NOT generate media (or RTCP packets) for that stream. To reject an offered
stream, the port number in the corresponding stream in the answer
MUST be set to zero. Any media formats listed are ignored. At least one MUST be present, as specified by SDP.

Also RFC 3264 Section 8.2

Existing media streams are removed by creating a new SDP with the
port number for that stream set to zero. The stream description MAY
omit all attributes present previously, and MAY list just a single
media format.

So my guess is that you are offering

  • one audio stream (that gets accepted)
  • one video stream (that gets accepted)
  • a second video stream (that gets rejected)
  • one application stream (that gets rejected)

Not entirely sure why rejecting the second video stream causes the first video stream to not be shown or not be used.

Community
  • 1
  • 1
jsantander
  • 4,972
  • 16
  • 27
  • @hipkiss, `o=` line, there's only one because it describes the session. `c=` lines there can be at the top level (i.e. before any `m=` line) as default for any media stream or specific to a media stream (i.e. after a `m=` line) Refer to [Section 5.7 of RFC4566](https://tools.ietf.org/html/rfc4566#page-14) – jsantander Apr 24 '15 at 08:36
  • Ok so checking the offer, your assumption is indeed correct. Comparing the logs from this call and a previous one with a different client results in the response including this line: **a=fmtp:112 minptime=10** But this all results in the video working and the audio not working. Thank you for the RFC references. – hipkiss Apr 24 '15 at 08:42
  • I'm still getting the hang of not pressing enter on here! haha. I realised that the o= and c= didn't need to be repeated. – hipkiss Apr 24 '15 at 08:42
0

@jsantander , thank you for the additional information. It led me to realise that the offer and response for audio codecs didn't actually match, opus and PCMU respectively, and thus didn't establish that stream. I know that the question states that this is not the case, but when looking at the call on a basic level through the media broker it became apparent.

Setting opus the priority codec for establishing audio streams between clients has resulted in audio stream establishment of 100% over a few dozen calls.

hipkiss
  • 197
  • 2
  • 19