> From: Adam Frankel (afrankel) [afran...@cisco.com] > > I am seeing a scenario for an established call in which an outbound > reINVITE is being done, the far end is sending a TRYING and then a REFER > immediately. We are rejecting this REFER with a 400 Bad Request because > the INVITE transaction has not been completed. > > I am not clear whether REFER is allowed mid reINVITE or if the far end > should wait for the 200OK/ACK to complete before sending the REFER. > I took a look a RFC3515 but it does not appear to state either way > whether this is allowed. Can anyone comment?
Of course, each request is part of its own transaction and requires its own response. Conceptually, the REFER is compatible with the re-INVITE, because the re-INVITE is just modifying the existing dialog, whereas the REFER (if it finishes successfully) will replace the dialog entirely. Until the new INVITE succeeds, the current dialog will be unchanged; when the new INVITE succeeds, the current dialog will be terminated. As far as I know, this is the approach the RFCs take. In practice, I can see how this would be hard to implement, as it doesn't conform to the usual model of a finite state machine, which requires that only one update to the dialog's state can be in-progress at a time. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
