Hi, 'Padding' data should not contain 'call' data. So even if other parties drops padding data, call quality should not be effected. Padding generally useful for cryptographic functionality.. eg., A typical algorithm may enforce, data must be aligned to 4 byte boundary.
Hence no padding by default. On Wed, Feb 20, 2013 at 12:14 AM, Nahum Nir <[email protected]>wrote: > 10xs venu. > > If the other client is not supporting padded data and will "just" process > the rest of the data he will probably loss half of the data and the call > will be worthless. > Speaking of padded data most clients and termination servers send by > default unpadded data. Why not pad by default? > > On Mon, Feb 18, 2013 at 3:09 PM, venu Y <[email protected]> wrote: > >> As for as I know, there is no SDP parameters associated with it. >> >> May I know what do you mean by, other part not supporting it? >> >> If it can't understand your padded data, it should simply discard based >> on length, and proceed with the rest of the data, as normal packet; if p=1. >> >> >> On Sun, Feb 17, 2013 at 12:04 AM, Nahum Nir <[email protected]>wrote: >> >>> Hi Everyone, >>> >>> In case that the other client is not supporting RTP padding will my >>> client >>> be notified in any way? >>> >>> 10xs, >>> Nahum >>> _______________________________________________ >>> Sip-implementors mailing list >>> [email protected] >>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>> >> >> >> >> -- >> With Regards >> Venu >> 93484 89945 >> [email protected] >> > > -- With Regards Venu 93484 89945 [email protected] _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
