I went to chrome://webrtc-internals/ to copy the sdp. Overall, I'd like to understand the meaning.
setRemoteDescription
type: answer, sdp: v=0
o=mozilla...THIS_IS_SDPARTA-39.0 6618245136742574887 0 IN IP4 0.0.0.0
s=-
t=0 0
a=fingerprint:sha-256 27:8B:F6:1A:72:47:17:2B:23:C1:9A:85:AB:3A:E0:29:15:B9:F5:B0:B6:EA:17:C9:11:99:AA:B7:AB:45:A9:60
a=ice-options:trickle
a=msid-semantic:WMS *
m=application 9 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=sendrecv
a=ice-pwd:a33017ce6eae687d1afdae61c9f0db55
a=ice-ufrag:f8acf035
a=mid:data
a=sctpmap:5000 webrtc-datachannel 256
a=setup:active
Specifically, I'd like the understand the meaning of
a=sctpmap:5000 webrtc-datachannel 256
The format of the sctpmap attribute is defined as:
The sctpmap attribute maps from a port number (as used in an "m="
line) to an encoding name denoting the payload format to be used on
top of the SCTP association or the actual protocol running on top of
it.
The sctpmap MUST include the app parameter indicating the application
running on top of the association.
The sctpmap line should also contain the max-message-size parameter
indicating the maximum message size, in bytes, the endpoint is
willing to accept.
So the line a=sctpmap:5000 webrtc-datachannel 256 Is indicating port 5000, an application name of 'webrtc-datachannel' and a message size of 256 bytes.
This is in your generated SDP because your application is making use of datachannels on your PeerConnection.
Related
In a WebRTC video call
A->B a SDP offer, it means that A supports VP8, VP9 and H264
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 127 124 125
a=sendrecv
a=rtpmap:96 VP8/90000
...
a=rtpmap:98 VP9/90000
...
a=rtpmap:100 H264/90000
while B->A answered a SDP answer, it also means that B supports VP8, VP9 and H264
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 127 124 125
a=sendrecv
a=rtpmap:96 VP8/90000
...
a=rtpmap:98 VP9/90000
...
a=rtpmap:100 H264/90000
...
My question is in this case, which codec will be used? How A or B knows another choice?
Thanks
The answer can be found in RFC3264.
Section 5.1:
If multiple formats are listed, it
means that the offerer is capable of making use of any of those
formats during the session. In other words, the answerer MAY change
formats in the middle of the session, making use of any of the
formats listed, without sending a new offer.
The offerer will list the supported codecs in order of preference in the m-line. The answerer will most likely honor that preference, but is not obliged to do so. See Section 6.1:
Although the answerer MAY list the formats in their desired order of
preference, it is RECOMMENDED that unless there is a specific reason,
the answerer list formats in the same relative order they were
present in the offer.
Section 7:
When the offerer receives the answer, it MAY send media on the
accepted stream(s) (assuming it is listed as sendrecv or recvonly in
the answer). It MUST send using a media format listed in the answer,
and it SHOULD use the first media format listed in the answer when it
does send.
So in short: the offerer and answerer will most likely use the first codec in the answerer's m-line and this may change during the media session.
B signals that it would prefer 96, i.e. VP8 since that is listed first in the m= line formats.
https://webrtc.github.io/samples/src/content/peerconnection/change-codecs/ has a sample allows you to change the order of codecs and inspect the results.
I do use peerjs https://peerjs.com to stablish connection between 2 peers.
Is there a way to force the use of H264 code instead of VP8 ?
Regards
Update:
You can use setCodecPreferences to achieve the same result, once browsers support it.
Old Answer:
You will have to edit the peerjs code to change codecs.
Basically you will have to update the SDP , more specifically, the video line in the sdp.
The video line will look something like
m=video 60372 UDP/TLS/RTP/SAVPF 96 98 100 101 116 111
The numbers 100 101 etc correspond to the various codecs that the peer support, they are represented by lines like the following:
a=rtpmap:98 VP9/90000
a=rtpmap:96 VP8/90000
So you have to first get the sdp and find out the number for the H264 codec, next move the number to the beginning of the list in the video line.
For example, if 100 is the number of the H264 codec, you need to change the above video line to
m=video 60372 UDP/TLS/RTP/SAVPF 100 96 98 101 116 111
For the caller side, modify the sdp after creating the offer but before setting the localDescription
pc.createOffer().then(function(offer) {
sdp = offer.sdp;
changedsdp = updateCodec(sdp) //Function to modify the sdp
offer.sdp = changedsdp
pc.setLocalDescription(offer)
For the answerer side, modify the sdp after create answer
pc.createAnswer(function(answer) {
sdp = answer.sdp;
changedsdp = updateCodec(sdp) //Function to modify the sdp
answer.sdp = changedsdp
pc.setLocalDescription(answer)
I wrote a simple code for testing RTCPeerconnection
peer = new RTCPeerconnection(...);
peer.onicecandidate = function(evt){
console.log(evt.candidate);
// into the console
// RTCIceCandidate {candidate: "candidate:... 1 udp ", sdpMLineIndex:0, sdpMid:"data"}
// RTCIceCandidate {candidate: "candidate:... 2 udp ", sdpMLineIndex:0, sdpMid:"data"}
}
i want send it to signaling server but i receive it 2 times and 2 different values.
Have i to record all candidate values?
When i receive candidate information from signaling server, have i to receive all the values about the same peer?
I have too, localDescription
// {type: "offer", sdp: "v=0↵o=- 6483...48 2 IN IP4 ...}
Have i to send it to signaling server and receive the description of other peer?
I think you need to do bit more reading up on WebRTC, for a single PeerConnection, there could be many ICE candidates, you usually send it to remote peer through some signaling server, no point storing it in server, as they probably expire after a period of time.
this and this might be good place to read up on the basics.
i would modify the content of Data in the UDP Packet read from a pcap file and send it on the network.
In the following example i write a string "User data" and it work correctly but if my data require more space than the previous payload opened, i get error, how i can increase dimension of payload data taken from the original pcap file?
Pcap pcap_off = Pcap.openOffline(fileName, errorBuf); //open original packet
PcapPacket temp= new PcapPacket(JMemory.Type.POINTER);
pcap_off.nextEx(temp); //only one UDp packet
JBuffer buff=new JBuffer(temp.size());
Ethernet eth=temp.getHeader(new Ethernet());
Ip4 ip=temp.getHeader(new Ip4());
Udp udp=temp.getHeader(new Udp());
Payload data=temp.getHeader(new Payload());
InetAddress dst = InetAddress.getByName("10.0.0.10");
ip.destination(dst.getAddress()); //modify ip dst
ip.checksum(ip.calculateChecksum());
eth.transferTo(buff);
ip.transferTo(buff, 0, ip.size(), eth.size());
*byte[] userdata = new String("User data").getBytes();*
*data.setByteArray(0,userdata);*
*data.transferTo(buff, 0, data.size(), eth.size() + ip.size()+ udp.size());*
int cs = udp.calculateChecksum(); //ricalcolo il checksum UDP
udp.setUShort(6, cs); //correct UDP checksum
udp.transferTo(buff, 0, udp.size(), eth.size() + ip.size());
JPacket new_packet =new JMemoryPacket(JProtocol.ETHERNET_ID,buff); //new packet
Many thanks to any answer.
You can't resize the buffer. You have to allocate a bigger buffer then the original packet so you have room to expand.
In your code, copy the packet from pcap buffer to jbuffer first, possibly one header at a time instead of the entire packet at once and make your changes as you go, one header at a time. The bigger buffer will give you room to include payload of any size.
For efficiency on windows systems you can also use the sendqueue which will allow you to compose many packets in a single large buffer.
I've found out that when I send an UDP datagram that gets fragmented (over 1452 bytes with MTU=1500), according to tcpdump, all the fragments are received on the target machine but then no message is received on the socket. This happens only with IPv6 addresses (both global and link-local), with IPv4 everything works as expected (and with non-fragmented datagrams as well).
As the datagram is discarded, there is this ICMP6 message:
05:10:59.887920 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 69) 2620:52:0:105f::ffff:74 > 2620:52:0:105f::ffff:7b: [icmp6 sum ok] ICMP6, destination unreachable, length 69, unreachable port[|icmp6]
There's some repeated neighbour solicitation/advertisements going on and I see that it gets to the ARP cache (via ip neigh).
One minute later I get another ICMP6 messages saying that the fragment has timeout out.
What's wrong with the settings? The reassembled packet should not be discarded, when it can be delivered, right?
System is RHEL6 2.6.32-358.11.1.el6.x86_64