On Wed, Jun 22, 2011 at 4:31 PM, Joegen Baclor <[email protected]> wrote: > Hi Tony, > > The cause of the 488 is now known. It is the fact that when SRTP is > enabled, Polycom offer two m-lines. One for the enrypted stream, and > the other the normal none-encrypted stream. Both are offered using the > same port. The normal answer from a compliant provider is to offer a > port with "0" value for the encrypted stream while sending an actual > port for the none encrypted stream (given that it doenst know how to > support the SRTP attributes). > > > However, there is yet another bug discovered in sipXbridge. It only > rewrites or process the first m-line and leaves the the second m-line > untouched. The other bug is that it choose to process the first m-line > (the encrypted one) and rewrote its port. however it omitted the SRTP > attributes rendering that stream corrupted even if negotiation succeeds. > We will be opening a new task for this. > > *** Take note that the offer from sipXbridge is still valid and must not > generate a 488. Only incompatible streams. This reveals that your > provider blindly generates a 488 if its sees multiple m-lines for audio > instead of choosing between them. > > disabling SRTP as the default should be the conclusion of 9699. We will > reference the new ticket in it.
http://track.sipfoundry.org/browse/XX-9713 I already committed fix for, meaning SRTP is disabled by default _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
