On Wed, 2005-09-28 at 15:38 +0100, Stephen Paterson wrote: > After a successful session set up, a UAC initiates a re-INVITE for any > reason but has not yet received a response before it decides to clear the > session. This will also apply to any mid-session request but my current > concern is with re-INVITEs. > I've been unable to find any guidance on the RFC/draft pages and was hoping > for some help. > I've had a discussion with some of my colleagues and the following call flow > shows our thoughts on what should happen: > > UAC UAS > | | > | INVITE/200/ACK | > | <-------------------------------> | > | | > | Both way RTP established | > | | > | re-INVITE (CSeq 2) | > | --------------------------------> | > | re-INVITE (CSeq 2) | > | --------------------------------> | > | BYE (CSeq 3) | > | --------------------------------> | > | 487 (CSeq 2) | > | <-------------------------------- | > | 200 (CSeq 3) | > | <-------------------------------- | > | ACK (CSeq 2) | > | --------------------------------> |
There seem to be a number of different cases. Case 1: The re-INVITE and all retransmissions are lost before they reach UAS. Eventually, UAC will receive (or internally generate) a 408 for CSeq 2. UAS, when receiving BYE CSeq 3, will process it normally (because the CSeq is larger than the last CSeq it saw -- RFC 3261, section 12.2.2, paragraph 7, which seems to be the core specification for handling CSeqs). UAS sends 200 for CSeq 3, which UAC receives. Case 2: The re-INVITE gets to UAS in a timely manner, but the response to it (and all retransmissions) are lost before they reach the UAC. Eventually, UAC will receive (or internally generate) a 408 for CSeq 2. UAS, when receiving BYE CSeq 3, will process it normally against the dialog as modified by the re-INVITE. UAS sends 200 for CSeq 3, which UAC receives. Case 3: UAS receives BYE CSeq 3 before receiving a retransmission of re-INVITE CSeq 2. The BYE is processed normally as above, and UAC receives 200 CSeq 3 for it. The re-INVITE is rejected with 500 CSeq 2 (per the paragraph cited above). In this case, UAC has positive knowledge that the re-INVITE was not processed. In the first two cases, it does not, because it received 408 responses. This probably doesn't matter for re-INVITEs, but for some messages (e.g., MESSAGE), it might be significant at the user level. Clearly, if the user-situation that caused UAC to generate BYE means that the user no longer cares if earlier requests are seen by UAS or not, then UAC can cease retransmitting earlier requests once the BYE is sent. But in the general case, it probably should continue attempting retransmission of earlier requests until the response to the later request is received. (After that point, UAS must respond 500 to any earlier requests that it receives, so retransmission becomes pointless.) Dale _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
