Hi, Just adding some information, RFC3261 allows sending re-invite without SDP body. I don't think this is a good idea because the UA witch sends a re-invite with a new renegotiation should present its alternatives. I remmember that RFC says 'MAY', witch preciselly means it's possible but it's not a good idea.
Section 14.1 UAC Behavior (page 86) (...)It is important to note that the full description of the session, not just the change, is sent. This supports stateless session processing in various elements, and supports failover and recovery capabilities. Of course, a UAC MAY send a re-INVITE with no session description, in which case the first reliable non-failure response to the re-INVITE will contain the offer (in this specification, that is a 2xx response) Anyway, about the re-invite renegotiation, also from RFC 3261: 14.2 UAS behavior (page 88) If the new session description is not acceptable, the UAS can reject it by returning a 488 (Not Acceptable Here) response for the re- INVITE. This response SHOULD include a Warning header field. I've seen the signaling, and there is no problem with that. The INVITE goes with the SDP body and the 200 OK response confirms compability. In re-INVITE signaling the same thing happens. Then, reading the Johnson's description, if the PBX or the ISP doesn't support G.729, it should not accept any call at all. Not even for sending a new re-INVITE after. Although, some implemmentations actually does that. Agein, RFC 3261 recommends waht I'm talking about: 8.1.3 Processing Responses 8.1.3.5 Processing 4xx Responses (page 45) If a 415 (Unsupported Media Type) response is received (Section 21.4.13), the request contained media types not supported by the UAS. The UAC SHOULD retry sending the request, this time only using content with types listed in the Accept header field in the response, with encodings listed in the Accept-Encoding header field in the response, and with languages listed in the Accept-Language in the response. 21.4.13 415 Unsupported Media Type (page 187) The server is refusing to service the request because the message body of the request is in a format not supported by the server for the requested method. The server MUST return a list of acceptable formats using the Accept, Accept-Encoding, or Accept-Language header field, depending on the specific problem with the content. UAC processing of this response is described in Section 8.1.3.5. Then, assuming that the PBX or the ISP doesn't support G.729, it should have one of following two actions: 1) If it is specified in initial INVITE SDP body, it should respond with 200 OK accepting the call only with codec G.711 in SDP body. 2) If it is not specified in initial INVITE SDP body, it should respond the initial INVITE with 415 Unsupported Media Type with Accept header specifying codec G.711. Then, the UAC shall try a new call using G.711. Leonardo ________________________________ De: "Johnson, Michael A" <michael.a.john...@team.telstra.com> Para: "Worley, Dale R (Dale)" <dwor...@avaya.com>; "sip-implementors@lists.cs.columbia.edu" <sip-implementors@lists.cs.columbia.edu> Enviadas: Quinta-feira, 30 de Junho de 2011 20:45 Assunto: Re: [Sip-implementors] Re-Invite codec renegotiation. Sorry Dale, I thought it was clear. The PBX (Mitel) that sends the re-invite without SDP, that then accepts the offered G.729 codec from the ISP, despite not being able support the codec is the device I believe is as fault. The manufacturer however disagrees. As per the comment "Although it might look like we're not doing it correctly, we are. ACK is the proper msg to be sent to acknowledge a response (2xx-6xx) to an INVITE request as per RFC3261" I believe they should reject the G.729 offer. This does not appear to be clearly defined in the RFC -----Original Message----- From: Worley, Dale R (Dale) [mailto:dwor...@avaya.com] Sent: Friday, 1 July 2011 12:51 AM To: Johnson, Michael A; sip-implementors@lists.cs.columbia.edu Subject: RE: Re-Invite codec renegotiation. ________________________________________ From: Johnson, Michael A [michael.a.john...@team.telstra.com] Thanks Dale, The problem I have is that I cannot find anything definitive in RFC3261 that explicitly states that the system cannot accept the 200OK despite the fact it has no capability to handle the codec. The best I see in the RFC is 'SHOULD'. To get the code corrected, I really need a clearly documented breach in the way they handle the call. And while it is obvious that this is not correct behaviour, this is not what I get back from their design team: "Although it might look like we're not doing it correctly, we are. ACK is the proper msg to be sent to acknowledge a response (2xx-6xx) to an INVITE request as per RFC3261" They have implemented a dodgy work around, however I want a proper fix and was seeking assistance to find the exact RFC extract to prove they are in breach of the standards. ________________________________________ Please... You still haven't clearly stated which device you think is doing something wrong, and exactly what you think it is doing wrong. I can't afford to spend more time on this discussion until you make it clear *what the problem is*. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
