So I have two peers, Alice and Bob. Alice wants to receive video from Bob but not send her own. Bob does not support VP8/9, only h.264. Currently the webrtc connection is established without errors, but Alice sees a purple mess for video. The video displays correctly after modifying the offer m line.
In more detail.. Alice creates an offer with the following m line and sends to Bob. Stream ids 96 - 101 use vp8 or vp9 codecs. ids > 101 use h.264.
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 122 127 121 125 107 108 109 124 120 123 119 114 115 116
Since Bob does not support vp8 or vp9, his answer contains the following m line:
m=video 9 UDP/TLS/RTP/SAVPF 102 122 127 121 125 107 108 109 114 115 116
Alice receives the answer from Bob, calls setRemoteDescription, then gets the ontrack callback, and then the setRemoteDescriptionFinished callback.
I would expect Alice’s browser (Chrome 79.0.3945.130, Mac) to choose 102 and use an h.264 decoder. The purple, garbled video looks suspiciously like video data being decoded by the wrong decoder.
So as an experiment I removed the entries in the 96 - 101 range from Alice’s offer before setLocalDescription and before sending to Bob. With this change the video displays correctly.
Does someone more knowledgable about webrtc have any idea what might cause Chrome to choose a stream not present in the peer answer?
I am in the process of testing this on other browsers and simplifying the code for more testing.
Also worth noting is that only the offer passed to setLocalDescription needs to be modified. If the unmodified offer is then sent to Bob, video is still displayed correctly.
According to webrtc-internals, Alice's Chrome is indeed selecting 96 (VP8) as the format of the inbound-rtp stream, even though it is H264.
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 have a Web performance Script in Visual Studio. I have turned this into Coded Webtest in VB by clicking on the Generate Code button.
In my web test there are a 5 functions. Apart from the 1st the others are for SQL Procedures.
Among a few things, I need a web request that does a certain action. Based on that action, In the response body - it generates a Unique Id.
I need this Id to make it accessible across all the functions.
The Response body is something like this :
0x00000000 7B 22 69 64 22 3A 36 35 33 30 36 36 33 7D {"id":2133221}
Now I wanted to know, how do I do it. I just need 2133221.
I tried
using the Context Parameter name and appending it to a .to string...it did not work. I tried doing by looking over the net and trying out a few options. I'm lost now. Can anyone help.
The simplest solution is the below one.
str = "0x00000000 7B 22 69 64 22 3A 36 35 33 30 36 36 33 7D {""id"":2133221}"
arr = Split(str, ":")
strID = Left(arr(1), len(arr(1)) - 1)
msgbox strId
However, If you still need a more robust one, try regex
See access the response from a web coded performance test for how to access the response ina coded test. While it is in C# the VB style is similar.
For your case the displayed string shows a hex dump of the actual body. Th ebody does not include the 0x00000000 7B 22 69 64 22 3A 36 35 33 30 36 36 33 7D part.
A simple approach to getting the wanted Id string is to use a Extract text extraction rule with a Start with of "id": and an Ends with of ". This will need to be done on the ".webtest" file.
I strongly recommend against converting web tests to coded tests. It loses all the high level structure of the ".webtest" format. The Web Test Editor has many facilities for easily enhancing and changing tests, all of them are lost when changing to a coded test. A little learning about extraction and validation rules gives you many facilities. If you are happy working with the VB of a coded test then you should also be happy to write plugins so look at web test request plugins and web test plugins.
I was wondering if anyone could help me understand difference between ISO 8583 Field 22 i.e. POS Entry Mode. I already know that:
52 means ICC Card
80 in case of fallback
But what I want to know is difference between
22 (Magnetic Stripe)
and 90
Can anyone help me on this?
The length of Field 22 usually 3-digits (or 4-digits in case it is BCD packed into two Bytes) in protocols based on ISO 8583:1987 or 12-digits in case protocols based on ISO 8583:1993 version. Customized protocols could use different sub-fields content and values meaning behind.
While you use short values in the requested question, I guess, your Field 22 based on ISO 8583:1987 version and you lost the leading and/or ending zero. So, your sample values becomes 3 digits length - 052, 800, 022, and 090 or 900.
Usually the 3-digits Field 22 splited into two sub-fields:
Position 1 and 2 - Personal Account Number (PAN) Entry (or capability);
Position 3 - Personal Identification Number (PIN) Entry (or capability);
Here are the possible interpretations:
02 - PAN auto-entry via magnetic stripe, track data is not required, 2 - no PIN.
05 - PAN auto-entry via chip, 2 - no PIN.
09 - E-Commerce, 0 - unknown PIN capability.
80 - Fallback to magnetic stripe, 0 - unknown PIN capability.
90 - PAN auto-entry via magnetic stripe, track data should be transmitted within the authorization request, 0 - unknown PIN capability.
etc.
90 used in case track data present in the ISO 8583 request message, 02 - if, for same reason, acquirer or terminal device not qualified to transfer track data in the request messages.
Depending of protocol requirements could be exceptions with Field 22 values. It is usually checked during the terminal device and communication interface certifications.
I will elaborate few things here. From above comments I can see that 09 is for E commerce transactions,but as per my knowledge for E commerce transactions we should use PAN Entry mode as 01(manual entry). Because for card not present transactions entry mode has always in manually.
POS Entry mode says whether the particular transaction is E commerce or POS. The possible values are :
01 Manual entry
02 Magnetic Stripe,track 2 data will ignore
05 Smart card,track 2 data required
90 Magnetic stripe no track 2 data
91 contactless card
95 Smart card , track2 data not required
Thanks share your ideas on this
I'm writing an web server with Lisp to handler HTTPS request. I followed TLS 1.2 and already completed the handshake process. The Cipher Suite I chose is TLS_RSA_WITH_RC4_128_SHA. I already calculated client_write_MAC_secret, server_write_MAC_secret, client_write_key, server_write_key. These keys seems are correct, because I can decrypt "Finished" message from browser and validate the data inside. I also validate the HMAC of the record layer. Then I send a "Change Cipher Spec" and "Finished" from server. So far everything seems working fine.
Then I got the message from browser start with #(23 3 3 1 61 ...). 23 means it's an application data. #(3 3) means TLS 1.2. #(1 61) means length is 256+61=317 which is correct because the data left is really 317 bytes long. Here comes my question: I decrypted these 317 bytes with RC4 using the "client_write_key" then I got data like #(148 104 81 182 67 111 28 201 202 50 207 57 126 209 19 ...) which can't be converted to text. I thought I should get something like GET / HTTP/1.1. What do I get wrong?
Thanks.
RC4 is a stream cipher and, according to RFC 5246, section 6.2.3.1, "For stream ciphers that do not use a synchronization vector (such as RC4), the stream cipher state from the end of one record is simply used on the subsequent packet."
So, the first record you decrypt is the FINISHED message and the first application data you decrypt should be with the RC4 state as it was left after decrypting the FINISHED message.