Sdp is not part of RFC3261. -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext Worley, Dale R (Dale) Sent: Thursday, June 30, 2011 9:51 AM To: Johnson, Michael A; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] 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
