> B2BUA IMS B2BUA > | | | > ------> | ------> | | > INVITE | INVITE | | > | | | > | | ------> | ------> > | | INVITE | INVITE > | | | > | | <------ | <------ > | | 200OK | 200OK > <------ | <------ | | > 200OK | 200OK | | > | | | (retransmit) > | | | 200OK (INV) > | | | > | | | (ACK timeout) > | | <------ | <------ > | | BYE | BYE > <------ | <------ | | > BYE | BYE | | > | | | > ------> | ------> | | > 200OK | 200OK | | > | | ------> | ------> > | | 200OK | 200OK > | | | > | <------ | <------ | ??????? > | 200OK(INV) | 200OK(INV) | > | | | > | | | > | | | > | | | > > > I think it's an error but I'm getting confused from the rfc ...
If timeout awaiting for ACK, something is wrong (configuration, network, bug, et cetera). RFC 3261 section 13.3.1.4 indicates the following. "If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is accomplished with a BYE, as described in Section 15." > 2nd question > If the B2BUA sends BYE and then incorrectly repeats > the 200 for INVITE should IMS forward it? Maybe. :) If "IMS" behaves as proxy (including maybe proxy-B2BUA), RFC 6026 section 8.3 deprecated relaying stray responses; thus it depends upon if the transaction is still available (see mentioned RFC). If "IMS" behaves as B2BUA (excluding maybe proxy-B2BUA), it typically shouldn't relay the 200 response since it looks like (excluding race conditions) the UA violated the following RFC 3261 section 15 snippet. However it does, it should at least avoid relaying stray responses similar to a proxy. "However, the callee's UA MUST NOT send a BYE on a confirmed dialog until it has received an ACK for its 2xx response or until the server transaction times out." _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
