> Whether below mentioned scenarios correct from > Offer/Answer model point of view ? > > 1. INVITE/18x (Reliable) for Offer/Answer1. > > 200 OK (INVITE)/ACK for Offer/Answer2.
No. > 2. INVITE/18x (Reliable) for Offer/Answer1. > > PRACK/200 OK (PRACK) for Offer/Answer2. Yes. > 200 OK (INVITE)/ACK for Offer/Answer3. No. > 3. INVITE/18x (Reliable) for Offer/Answer1. > > UDPATE/200 OK (UPDATE) for Offer/Answer2. Yes. > 200 OK (INVITE)/ACK for Offer/Answer3. No. > 4. INVITE/18x (Reliable) for Offer/Answer1. > > PRACK/200 OK (PRACK) for Offer/Answer2. Yes. > UDPATE/200 OK (UPDATE) for Offer/Answer3. Yes. > 200 OK (INVITE)/ACK for Offer/Answer4. No. > My doubt is mainly for the case, where Offer is > received in 200 OK (of INVITE) (later Answer in ACK), > as already the offer/answer exchange has happened > for that SIP transaction via INVITE/18x(reliable). > I have read somewhere, that there should be only > one offer/answer exchange for a SIP transaction. Yes; however because of forking, there can be more (i.e. 1 per dialog). RFC 3261 section 13.2.1: o Once the UAS has sent or received an answer to the initial offer, it MUST NOT generate subsequent offers in any responses to the initial INVITE. This means that a UAS based on this specification alone can never generate subsequent offers until completion of the initial transaction. RFC 6337 provides additional details. _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
