> My doubt in RFC 3312 is about 183 response for a re-INVITE. > Do user-agents respond with 18x for a re-INVITE and accept > 183 in re-INVITE?
RFC 6141 section 3.1 discusses a situation potentially involving a user interaction. > What is the call state? How should 3pcc AS support 183 > in re-INVITE? Should it pass it on to the other leg? The behavior would depend upon how it needs to behave associated with the other dialog. For instance if A actually sent the re-INVITE (such as within RFC 6141 section 3.1), you can relay the received 18x; however I assume that isn't the call flow of concern. > Have only seen 200 OK response for a re-INVITE. Me too (except during testing). On Friday, 22 July 2016 9:57 PM, Brett Tate <[email protected]> wrote: Preconditions within re-INVITE is discussed within RFC 3312, RFC 6141, and RFC 4032. RFC 3725 may also be of interest since your use case sounds like 3PCC. RFC 4032 section 4 discusses a 3PCC situation that you might hit. > -----Original Message----- > From: [email protected] [mailto:sip- > [email protected]] On Behalf Of amrita chaudhary > Sent: Friday, July 22, 2016 11:10 AM > To: [email protected] > Subject: [Sip-implementors] Precondition negotiation in re-INVITE > > Hi, > Is it possible to do precondition negotiation in re-INVITE when first leg > of > the call is established?Scenario: AS connects A-party to C-party after B- > party (which was in conversation with A) is released.A, B and C are VoLTE > terminals. > Does anybody has done this in their implementation. > > Regards,Amrita > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
