Hi, using "early_announcement" application I've realized that when SEMS receives an INVITE with SDP containing "g729" (so non compatible with SEMS) them SEMS replies with:
606 could not find compatible payload I don't understand why SEMS replies with a dangerous 6XX code that breaks parallel and serial forking. Imaging for example that I configure my OpenSer with this logic: 1) A calls to B. 2) B is not available. 3) OpenSer proxies the request to SEMS. 4) INVITE just contains g729 so SEMS declinces the INVITE with 4XX. 5) OpenSer does again serial forking and proxies the request to a media server supporting g729. But the above example is IMPOSSIBLE with SEMS since it replies a 6XX in step 4 so OpenSer will not perform the step 5 (this is the RFC 3261 behaviour: a 6XX breaks any parallel or serial forking by definition). So, why this 606? why not a 488?: RFC 3261: 21.4.26 488 Not Acceptable Here The response has the same meaning as 606 (Not Acceptable), but only applies to the specific resource addressed by the Request-URI and the request may succeed elsewhere. A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request. Regards. -- Iñaki Baz Castillo [EMAIL PROTECTED] _______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
