Modbus function 2B "Encapsulated Interface Transport" has encapsulated MEI type 0E "Read Device Identification". Server responce for this request has "Number Of Objects" field that is described as "Number of identification Object returned in the response (for an individual access, Number Of Objects = 1)".
If the response packet has no enough space to place all identification objects, transaction may be splitted to separate packets. In this case the field "More Follows" must be equal to FF, the field "Next Object Id" must be equal to number of first object that weren't placed into this packet. But what the field "Number of objects" must be equal to?
Modbus Application Protocol Specification has an example:
First transaction:
Request
Response
Field Name
Value
Field Name
Value
Function
2B
Function
2B
MEI Type
0E
MEI type
0E
Read Dev Id Code
01
Read Dev Id Code
01
Object Id
00
Conformity Level
01
More Follows
FF
Next Object Id
02
Number Of Objects
03
Object Id
00
Object Length
16
Object Value
"Company identification"
Object Id
01
Object Length
1C
Object Value
"Product code XXXXXX"
Second transaction:
Request
Response
Field Name
Value
Field Name
Value
Function
2B
Function
2B
MEI Type
0E
MEI type
0E
Read Dev Id Code
01
Read Dev Id Code
01
Object Id
02
Conformity Level
01
More Follows
00
Next Object Id
00
Number Of Objects
03
Object Id
02
Object Length
05
Object Value
"V2.11"
In this example both responses have "Number of object" = 3, so this field must be equal to entire number of objects for selected Read Dev Id Code. There the very bad Modbus feature goes to scene: Modbus ADU doesn't contains full packet length. When identification packet has "Number of objects" = 3, calculating of actual packet size is impossible. Specification doesn't contains any explanation of what Number of objects must be equal when MoreFollows==FF. Is it error in Modbus Application Protocol Specification?
I examined several Modbus libraries for this subject. Most libraries have not implemented Modbus Encapsulated Interface, so I found only two convient libraries.
pymodbus
https://github.com/riptideio/pymodbus/blob/dev/pymodbus/mei_message.py
Constructing responce:
Line 181
When this lib constructs device identification response it places number of objects that is actually presented in packet.
Parsing response:
Line 194
When this lib parses device identification response it reads number of object from corresponding packet field, after that reads each object until packet ended.
Qt
https://github.com/qt/qtserialbus/blob/dev/src/serialbus/qmodbusdeviceidentification.cpp
Parsing response:
Line 213
When this lib parses device identification response it reads number of objects from corresponding packet field, after that reads Number Of Object objects.
Qt has no identification response constructor.
So, we have at least two libraries that implements identification response putting actually presented number of objects.
Your opinions, what Number of objects must be equal to when More Follows == FF?
The document I referenced:
https://modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf
From a client we receive an UPDATE message which contains the below media with fmt properties as below.
m=video 0 RTP/SAVP 0
Their aim is to close video media but it is causing us problems.
Is their message correct?
The usual format of closing video stream which we can correctly handle is
m=video 0 RTP/AVP 96 97 98
This is correct. According to the RFC 3264:
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.
This makes sense, because when a participant doesn't want to have a video stream, it doesn't matter which formats it would be willing to use. m=video 0 RTP/SAVP 0 simply means "no video stream" or "terminate the video stream".
And there is no obligation that the media format in this case should make any sense. Just like in the message you received: the format 0 stands for PCMU, which is not even a video format.
Imagine an offer SDP that has one line of "m" with codecs 8 and 101 for DMTF and marked as sendrecv:
m = audio 35904 RTP/AVP 8 101
a = rtpmap:8 PCMA/8000
a = rtpmap:101 telephone-event/8000
a = fmtp:101 0-15
a = sendrecv
The offered SDP is answered by a SDP with one line of "m" containing codecs 8 and 120 for DTMF similarly marked as sendrecv:
m = audio 1235 RTP/AVP 8 120
a = rtpmap:8 PCMA/8000
a = rtpmap:120 telephone-event/8000
a = fmtp:101 0-15
a = sendrecv
From RFC 3264:
For streams marked as sendrecv in the answer, the "m=" line MUST
contain at least one codec the answerer is willing to both send and
receive, from amongst those listed in the offer. The stream MAY
indicate additional media formats, not listed in the corresponding
stream in the offer, that the answerer is willing to send or
receive (of course, it will not be able to send them at this time,
since it was not listed in the offer).
Above part of the RFC3264, proves that sending a different DTMF fmtp(120 to 101) in answer SDP complies with RFC3264 since the codec 8(G711a) matches with the offer SDP.
Is it okay to say the codec exchange is completed successfully and DTMF exchange will okay or is DTMF is not expected to work at this point?
In general:
RTP payload type numbers 0-95 identify a static media encoding. E.g. payload type 8 means PCMA audio with a clock rate of 8000 Hz (RFC3551). As such, this description doesn't have to (but should) be included in the media format description of the SDP offer/answer, using the "a=rtpmap:" and "a=fmtp:" attributes (RFC4566).
Payload type numbers 96-127 are dynamic. These can be used to negotiate encodings that aren't included in the static list. When using one of these numbers, an encoding specification has to be included in the media format description to specify the exact encoding parameters.
Both negotiating parties can choose their own dynamic payload type number to represent the same media encoding, this doesn't have to be the same number. This can be useful when a party already assigned a particular dynamic payload type number to another encoding. In your example one party uses 101 in the m-line and the other one uses 120, but these numbers represent the same media encoding (see "a=rtpmap:" lines). Each party tells the other 'when you send RTP using encoding X you must include payload type number Y in the RTP packet headers.
The payload type number is included in the PT field of RTP packets headers (RFC 3550)
In this case:
The "a=fmtp:" attribute in the answer specifies 101 as payload type number instead of 120. That means it doesn't apply to the telephone-events payload and no information is available as to which DTMF events are supported (RFC 4733). I think this is an implementation error and the fmtp attribute is meant to apply to the telephone-events payload.
It is an indication that you should expect DTMF issues. But it could also all work fine. Give it a try...
SDP RFC is silent on the sequence of codecs . so my question is can we send FMTP line above RTPMAP?
There is no any standard for this as it is codec dependent. If your software includes also codec's, then you should pass these parameters to your codec interface or configure your codec accordingly. Each codec expects different parameters, so there is no any high-level format that should be respected.The processing differs from codec to codec. Sometime it contains values that can be omitted, sometimes contains important parameters which must be used accordingly.
The format is like this: a=fmtp PAYLOADNUMBER PARAMETERS_SEPARATED_BY_SEMICOLON
For example for G.723 you can have something like this:
a=fmtp:4 bitrate=6.3;annexa=yes
Or for G.729:
a=fmtp:18 annexb=yes
Or for speex:
a=fmtp:105 mode=8;mode=any
My question pertains to DIX (Ethernet II) and Ethernet: what is the link layer difference, if any? I don't see the link layer in the standard lists, but when doing, for instance, a pcap capture I see that wireshark will frame them differently (I'm not going to post pcap, but I'm sure the standards are posted).
source: http://www.tcpdump.org/linktypes.html
The Ethernet header has, in order:
a 6-octet destination address;
a 6-octet source address;
a 2-byte field.
In the original DEC/Intel/Xerox ("DIX") Ethernet specification, the 2-byte field was specified as a type field, giving an Ethernet type value specifying what protocol was running atop Ethernet; for example, a value of hex 0800 is used for IPv4.
In the original IEEE 802.3 specification, however, it was specified as a length field, giving the length of the payload following the Ethernet header. (Ethernet frames less than 64 octets, including the FCS, are padded to 64 octets; the length field allows the padding to be ignored. Some protocols, such as IPv4 and IPv6, include their own length field, so the padding can be ignored even without the Ethernet length field.)
If the 2-octet field isn't a type field, that leaves no mechanism for indicating what protocol is running atop Ethernet. The IEEE specified the IEEE 802.2 header, which follows the link-layer header in IEEE 802.x LANS (802.11, 802.5 Token Ring, 802.3 Ethernet, etc.), as well as FDDI; it includes 1-octet Destination Service Access Point (DSAP) and Source Service Access Point (SSAP) fields that can be used to specify the protocol running atop Ethernet.
So the difference between "DIX" Ethernet and "IEEE 802.3" Ethernet was, originally, that, in DIX Ethernet, the 2-octet field was a type field and there was no IEEE 802.2 header following the Ethernet header, whereas in IEEE 802.3 Ethernet, the 2-octet field was a length field and there was an IEEE 802.2 header following the Ethernet header.
The maximum length of an Ethernet frame is 1518 octets, including the 14-octet Ethernet header and the 4-octet FCS, so the maximum length of the Ethernet payload is 1518-(14+4) = 1500 octets. This means that the maximum value of an Ethernet length field is 1500.
The minimum value for an Ethernet type is hex 0600, or 1536. If the 2-octet field's value is between 0 and 1500, the field is a length field, and if it's greater than 1536, it's a type field. (If it's between 1501 and 1535, it's an invalid Ethernet frame.) This allowed DIX and IEEE 802.3 frames to be used on the same Ethernet segment.
IEEE Std 802.3x-1997 changed IEEE 802.3 so that it specified that the 2-octet field could either be a type field or a length field, and all subsequent versions of IEEE 802.3 have included that, so, starting at some point in 1997, DIX frames were also valid IEEE 802.3 frames.
Novell also ran their protocols directly atop IEEE 802.3, with no 802.2 header; their frames began with two hex FF octets, which meant that they would look like frames with the DSAP and SSAP values both set to hex FF. Hex FF is not a valid SSAP, as it has the "group address" bit set, so Novell frames without 802.2 ("Ethernet 802.3" frames) and 802.3 frames with an 802.2 header ("Ethernet 802.2" frames) can be distinguished from one another.
The DSAP and SSAP fields aren't sufficient to handle all protocol types, so the Subnetwork Access Protocol (SNAP) was devised. If the DSAP and SSAP in the 802.2 header are both hex AA, then the 802.2 header is followed by a SNAP header, which has a 3-octet Organizationally Unique Identifier (OUI) followed by a 2-octet Protocol ID (PID). The OUI is a number given out to organizations by the IEEE; it's used as the first 3 octets of MAC (Ethernet, 802.11, Token Ring, FDDI) addresses assigned to that organization (an organization can have multiple OUIs, so if they run out of MAC addresses in one OUI's range, they can assign more). The PID's interpretation is dependent on the OUI value. An OUI of 0 means that the PID is an Ethernet type value; other OUIs mean that it's a value assigned by the organization to whom that OUI belongs.
IPv4 and IPv6 packets sent over 802.x networks other than Ethernet, and over FDDI, have the link-layer header, the 802.2 header with the DSAP and SSAP both being AA, and a SNAP header with an OUI of 0 and an Ethernet type of hex 0800 (IPv4) or hex 86dd (IPv6). Over Ethernet, they'll have 0800 or 86dd in the type/length field, and no 802.2 header.
For more information, and some history about why all those frame types exist, see Don Provan's Ethernet Frame Types: Provan's Definitive Answer (archived at Wayback Machine).
The link-layer header types in pcap and pcapng files, as listed in the tcpdump.org link-layer header types page, correspond to formats for the octets that appear at the beginning of the packet data. LINKTYPE_ETHERNET/DLT_EN10MB, as that page says, corresponds to "IEEE 802.3 Ethernet", with a 6-octet destination address, a 6-octet source address, and a 2-byte type/length field, in order, so packets with a type field and packets with a length field are both covered by LINKTYPE_ETHERNET. They are not distinguished by the link-layer header type value; they are distinguished by the range in which the type/length field value appears (valid length field, valid type field, invalid field).
(And, yes, perhaps Wireshark shouldn't make as big a distinction between Ethernet frames with a type field and Ethernet frames with a length field; it should perhaps show them both as Ethernet frames, and show the 2-octet field as a type field if it's a type, a length field if it's a length, and as a "none of the above" field if it's invalid.)