Look at 61 page of RFC1889
about your question:
"is how seq number is chosen"
when device sending first RTP packet of the session, seq number must be random, to make known-plaintext attacks on encryption more difficult , in next packets seq is just increment
"B first problem is here", there is no problem, A tell to B, that A has recieved ack of the last B packet(which was seq 23)
"and now B acknowledge A seq:24 with ack:24???", yes ;-), B acknowledge to A, that seq 24 was recieved, by sending ack 24
there is last version of Enhanced Interior Gateway Routing Protocol
The following sequence number rules must be met for the reliable
EIGRP protocol to work correctly:
o A sender of a packet includes its global sequence number
in the sequence number field of the fixed header. The
sender includes the receivers sequence number in the
acknowledgment number field of the fixed header.
o Any packets that do not require acknowledgment must be
sent with a sequence number of 0.
o Any packet that has an acknowledgment number of zero (0)
indicates that sender is not expecting to explicitly
acknowledging delivery. Otherwise, it is acknowledging
a single packet.
o Packets that are network layer multicast must contain
acknowledgment number of 0.
But, in the rfc, there is no info about first seq number, so i`ve tested this on hardware. And as i see, seq number is starting from 1(not random, like in RTP). And it is intresting, looks like, that the seq number will be increment, until we will reboot device or restart eigrp process("no router eigrp"). "clear ip eigrp nei" wasnt drop seq num to zero, hm