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
----------------------------
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
Not entirely sure why rejecting the second video stream causes the first video stream to not be shown or not be used.