I should also make an addition to this, in regards to the hopefully permissive nature of the receiver; if the 3 E bit packets belonging to the same event have a sequence number in their RTP header that is consecutive, the receiving system should be able to deduce the fact that no packet loss has occurred. Then, ideally, it should couple this knowledge with the identical timestamp header present in all of the E bit packet's RTP headers in order to decide that it should accept these packets as related to the same event, even though they don't seem to follow RFC.
Joel Gerber Network Specialist Network Operations Eastlink E: [email protected] T: 519.786.1241 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Joel Gerber Sent: March-01-13 8:21 AM To: [email protected] Subject: Re: [Sip-implementors] RFC 4733 question Hello Jeff; To start, let's look at the definition of the Duration Field itself. RFC 4733 Section 2.3.5 states "The duration field indicates the duration of the event or segment being reported, in timestamp units, expressed as an unsigned integer in network byte order." With this in mind, a value in the duration header should define the current observed length of the specified event. Next; let's look at the definition of the E bit. Section 2.3.2 states "the 'end' bit indicates that this packet contains the end of the event..." With this in consideration, the E bit should only be sent when the observed event has been finalized. Section 2.5.1.4 gives this description of the "Final Packet": "the final packet for each event and for each segment SHOULD be sent a total of three times at the interval used by the source for updates." And then in the last paragraph of that section: "Once the sender has set the E bit for a packet, it MUST continue to set the E bit for any future retransmission of that packet." This gives the definite idea that multiple versions of an E bit packet (the final packet) should be recognized as a retransmission, and so its telephone-event payload should be consistent as you would expect in any retransmitted packet, being that only the sequence number in the RTP header should change, and the payload should remain consistent for each retransmission. If you put all of this together, you'll see that it would make sense that the duration field shouldn't increase for each retransmission of the "final" E bit RTP telephone-event payload packet. These retransmissions are retransmissions, and are sent multiple times to ensure that the receiving endpoint recognizes the end of an event, even in the event of minor packet loss being present on the network, once the end of the event has been detected. With this said; the receiving equipment should be as permissive as possible. Section 2.5.1.2 gives some additional logic that should prevent the receiving equipment from erroneously sending multiple tones when it states in the second paragraph that "An audio source SHOULD start transmitting event packets as soon as it recognizes an event and continue to send updates until the event has ended. *The update packets MUST have the same RTP timestamp value as the initial packet for the event*, but the duration MUST be increased to reflect the total cumulative duration since the beginning of the event." I added the *'s to denote the section of special interest to this discussion. With this statement in mind, a robust solution on the receiving end should be able to tell the difference between separate events by taking into consideration the timestamp field in the RTP header. If this value is consistent with all 3 of the E bit specified packets, even though they have an increasing duration which does seem to go against the standard as interpreted by myself, the receiver should be able to deduce that they belong to the same event. The 9th paragraph in 2.5.2.2 also reiterates this point. I hope this helps. I should also note that you can't send attachments to this list. Hopefully my detailed descriptions will help you to better analyze the capture file you have on hand. Joel Gerber Network Specialist Network Operations Eastlink E: [email protected] T: 519.786.1241 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bowers, Jeff S [NTK] Sent: February-28-13 1:50 PM To: [email protected] Subject: [Sip-implementors] RFC 4733 question All, I have a question concerning the event duration in relationship to the e-bits. Can the event duration change or increment in the three e-bits? We are seeing a behavior in which the event duration is incrementing in the three e-bits and the term end PBX is considering each of these e-bit as three separate events and triplicating the tones. The PBX vendor is stating that the carrier is in violation of RFC 4733, however I don't see that clearly written in the RFC stating that the event duration can't increment. I am not sure why the focus is on the event duration and in reading the RFC is appears the focus should be on the m-bit and the time stamp and once the e-bit is received then the rest of the packets should be ignored. I have enclosed a wireshark capture illustrating what we are seeing in the e-bits. Any guidance in this matter will be greatly appreciated. Thank you, Jeff Bowers Sprint ________________________________ This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
