Actually, if I remember correctly, this (or similar) came up before and the answer was:
use forking. do this by using a different to-tag in the 200 OK to that used in the 183: --- INVITE SDP-1 -------------------------------> <-- 183 Session Progress SDP-2 with to-tag=1---- <-- 200 OK SDP-3 with to-tag=2------------------ --- ACK --------------------------------> One issue here is that when the 200 OK comes in the leg relating to the 183 will get a CANCEL so this would have to be handled. Regards, Attila -----Original Message----- From: Attila Sipos Sent: 25 January 2007 09:57 To: '[EMAIL PROTECTED]'; [email protected] Subject: RE: [Sip-implementors] Two offer/answer cycles during session setup I don't think you can do this. The problem is that RFC3261 (13.2.1 Creating the Initial INVITE) 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. Strictly, after you've sent the 180 with SDP, the 200 SDP should be ignored (although, in practice, some UA's will try to use the last SDP it received). Also, you should really use PRACK after the 180 with SDP. (You want to make sure the 183 gets to the UAC) And I don't think there are any UA's which would send an ACK with SDP after originally sending an INVITE with SDP. In practice you might be able to do: UAC Proxy --- INVITE SDP-1 ------------------> <-- 183 Session Progress SDP-2 ----- <-- 200 OK SDP-3 -------------------- --- ACK ----------------------> But you have to do so with a lot of caution. From a standards point-of-view the above is not really allowed. I can't say I'd recommend it. (I don't know why it's not allowed, there must be some reason. Perhaps someone can enlighten us here) Regards, Attila -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Franz Edler Sent: 25 January 2007 08:34 To: [email protected] Subject: [Sip-implementors] Two offer/answer cycles during session setup Hi, I would like to use two offer/answer cycles during session setup (without using UPDATE) and ask for feedback if the following sequence will work. This is the sequence seen from UAC perspective. UAC Proxy --- INVITE SDP-1 ------------------> <-- 183 Session Progress SDP-2 ----- <-- 200 OK SDP-3 -------------------- --- ACK SDP-4 ----------------------> The point is that 200 OK carries a new SDP (SDP-3, the actual SDP of the Session Partner), while 183 carries the SDP-2 of an announcement. SDP-1 / SDP-2 is the first offer/answer SDP-3 / SDP-4 is the second offer/answer (expectation SDP-4 = SDP-1). >From my interpretation of RFC3264 the sequence could work. The Caller gets a special announcement before cut through. My doubts & questions are now: - Will UACs follow the change of SDP during session setup? - Will SDP-4 be identical to SDP-1? Who knows how UAs might behave? Cheers Franz _______________________________________________ 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
