From: "Steve Langstaff" <[EMAIL PROTECTED]> In the following trace (hopefully anonymised) I can't see how endpoint B can expect to receive or send audio, since it appears to negotiate away all but the telephone-event (101) codec.
It's clearly an error (in the practical sense) on the part of B, though it's standard-compliant. I know that the IETF does not define the user-facing behaviour of the endpoints, just the protocol interactions, but can anyone suggest what endpoint A should do in this case? Hanging up seems a good choice. It has been suggested that it should roll back to using the audio codec list previously negotiated, but is that correct? No -- endpoint B has not given A permission to send with any codec other than telephone-event. There aren't even any valid payload types for doing so. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
