2011/7/27 Leo Leo <[email protected]>: >>>Or should the UAS reply a "491 Request Pending" for the BYE? Anyhow >>>section 14.2 in RFC 3261 just indicates that 491 is useful when there >>>is a pending re-INVITE from A to B and B sends a re-INVITE to A. In >>>that case A should reply 491.
> A re-INVITE must not be forked, as RFC says in section 14. It's not common, but a UAS could reply 200 OK with a domain in the Contact URI. If so, the proxy responsible for such domain MAY need to perform registration lookup and generate N branches. 100% uncommon however, but SIP allows it. There is no constrains on how a top Route or the RURI must look in a re-INVITE. >>> The unique transaction which remains is the BYE transaction for sending >>> another 200 OK for some retransmission. >>> >>> > Although, the UAC may send some final response (i.e. 487) before > sending the 200 OK for the BYE. In matter fact, there is some > homologating procedures which requires this behaviour. > >>If the BYE is supposed to "magically" terminate all the pending >>transactions within the dialog (without requiring a final response for >>them) then I see no reason to send a 487 (maybe it would fail as the >>UAC would already terminate the client transaction for the initial >>INVITE). > > As the BYE terminates all transactions, it not really necessarilly. However, > it is desired to send the final response in order to avoid retransmissions or > unexpectable behavour . I think that's why some homologating procedures > requires that. Sending the final response (i.e.487) before 200 OK is reliable. Also note that the 487 matches the INVITE transaction while the 200 would match the BYE transaction, so there is no problem. I consider it the best way. Thanks a lot. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
