Thanks for your replay, guys. Markus, 4xx is just one of re-INVITE failure examples.
Gary, I have questions on your answer. 1. Do you mean that UA can't initate INVITE client transaction if there is uncompleted or uncomfimed INVITE server transaction? For example, if there is uncompleted or uncomfimed INVITE server transaction, UA can't initiate re-INVITE for session timer request? 2. Even though B2B has INVITE server transaction related with UA1, there is no pending transaction between B2B and UA2. What happen in UA2 if B2B sends 491 although all previous INVITE transactions between B2B and UA2 completed? Thank you in advance. Sumin. On 10/11/06, Gary Cote <[EMAIL PROTECTED]> wrote: > On 10/10/06, Sumin Seo <[EMAIL PROTECTED]> wrote: > > > > UA1 --------------- B2B --------------- UA2 > > > > After session refreshment, UA1 sends re-INVITE and B2B responses 4XX > > error to UA1. > > You probably already know this, but it might be worth repeating. The B2BUA > implements two dialogs - one between UA1 and B2B, and the other between > B2B and UA2. The B2BUA must be sure that each of the two dialogs correctly > conforms to the rules of the protocol. > > A B2BUA is simple in concept, but the "unusual" cases introduce complexity. > You've uncovered just such a case: one of the UA sends a re-INVITE. It fails > for some reason. While that's going on, the other UA sends a re-INVITE. > > > > > While B2B waits for ACK from UA1, can B2B send re-INVITE to UA1 > > if UA2 sends re-INVITE to B2B? > > > > No ... B2B cannot send a re-INVITE to UA1 until the first invite server > transaction reaches the confirmed or terminated state (see RFC 3261, > Section 14.1). Your transaction is still in the completed state. > > > > > If B2B doesn't want to process re-INVITE from UA2 before previous > > re-INVITE transaction between UA1 and B2B completes, what kind of > > final response should B2B send to UA2 as final response? > > > > You might consider a 491 Request Pending response. > > Or, perhaps even better ... > > B2B could delay sending the re-INVITE from UA2 until it receives the ACK > from UA1. B2B could start a timer. If it receives the ACK before the timer > expires, then simply forward the re-INVITE on. If the timer expires, then > send a 491 response to UA2. > > Hope that helps. > > -- > Gary Cote > Award Solutions, Inc. > www.awardsolutions.com > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
