To add a detail: Any offer can only get ONE answer from the SAME client. Remember that a SIP INVITE can fork, so one offer can get one answer in 183 from one device and a different one in 200 OK from *another* device. That's valid. This is covered in more detail in the RFCs covering the SIP Offer/Answer model than in RFC 3261.
/O 10 okt 2012 kl. 04:24 skrev Paul Kyzivat <[email protected]>: > On 10/9/12 7:45 PM, [email protected] wrote: >> thanks for your response. I added my comments inline. >> >> thanks >> Sam J >> ________________________________________ >> From: [email protected] >> [[email protected]] On Behalf Of Paul Kyzivat >> [[email protected]] >> Sent: Tuesday, October 09, 2012 11:03 PM >> To: [email protected] >> Subject: Re: [Sip-implementors] different SDPs in 18x and 200 OK >> >> On 10/9/12 1:44 PM, [email protected] wrote: >>> Hello Guys, >>> >>> Different SDP in 183 and 200_OK is a protocol violation or implementation >>> dependent? >>> >>> I am seeing some previous discussions on this topic, but the answers are >>> not quite convincing to me. I am unable to find SIP RFCs to see how this >>> scenario is handled. >>> >>> 1)SIP-Server sends a SIP INVITE(offer) to SIP-SS7-Gateway >>> 2)SIP-SS7-Gateway converts a SIP INVITE to IAM and sends IAM out >>> 3)SIP-SS7-Gateway receives ACM (Lets say the far SS7 end opens up voice >>> path upon ACM rather than ANM, may be a kind of announcement server. I >>> guess, i can calls this Early-Media) >>> 4)SIP-SS8-Gateway converts ACM into 183 sends 183(answer) to SIP-Server >>> 5)SIP-Server sends back PRACK to SIP-SS7-Gateway >> >> So the 183 was a reliable provisional response. >> >>> 6)SIP-SS7-Gateway sends 200 OK (PRACK) to SIP-Server >>> 7)SIP-SS7-Gateway receives ANM (from SS7 network perspective, the CIC is >>> same for this call, so opening voice path after ACM or ANM makes no >>> difference) >>> 8)SIP-SS7-Gateway converts ANM into 200_OK and sends 200_OK(different >>> answer) to SIP-Server >> >> There are two things that are legal to send in the 200 INVITE: >> >> - no SDP. This is preferred. The O/A was completed by the reliable 183. >> >> - the *same* SDP that was sent in the reliable provisional. >> This is legal because of how 3261 is worded. >> >> It is *not* legal to send *different* SDP in the 200 in this case. >> BUT 3261 says it is to be ignored, so it may not be detected as a problem. >> >> Sam>> can u point me to the section in 3261 where it says to ignore the sdp? > > 13.2.1 says: > > o If the initial offer is in an INVITE, the answer MUST be in a > reliable non-failure message from UAS back to UAC which is > correlated to that INVITE. For this specification, that is > only the final 2xx response to that INVITE. That same exact > answer MAY also be placed in any provisional responses sent > prior to the answer. The UAC MUST treat the first session > description it receives as the answer, and MUST ignore any > session descriptions in subsequent responses to the initial > INVITE. > > 6337 explains this in more detail and gives references. > > Thanks, > Paul > >> There is nothing written that says or implies that you may send two >> different answers to the same offer and have them both acted on. >> >> (I'm assuming all the messages above have the same from- and to-tags. If >> that is not so then it gets more complicated.) >> >> You should take a look at RFC 6337. >> >> Thanks, >> Paul >> >>> ... >>> >>> >>> In the step8, SIP-SS8-Gateway sends a different answer in the 200 OK for >>> some internal reason (implementation dependent ,may be to intercept only >>> the user's voice or etc...) >>> >>> PS: Please do not quote the section 13.2.1 in rfc 3261. >>> >>> Thanks >>> Sam J >>> ________________________________ >>> _______________________________________________ >>> Sip-implementors mailing list >>> [email protected] >>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>> >> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
