"Sylvester, Prasanth (NSN - IN/Bangalore)" <[email protected]> writes: > Thank you Paul. Your reply is much appreciated. > Just want to clear my doubt (just to see if my understanding is correct) > In my scenario, > > CLIENT --> SBC01 ---> SBC02 ---> Core > > When client sends a CANCEL & SBC01 sends 200 OK to the cancel (this happens > before it receives a 200 OK from SBC02) > SBC01 sends the CANCEL to SBC02 & SBC02 sends 200 OK to invite first & 200 OK > to cancel after that. > >>From SBC01 - It had received 200 OK for the invite; before it received the >>200 OK for the CANCEL (that is towards SBC02 leg); What should be the >>behavior of SBC01? > > - It should send an ACK to SBC02 for the 200OK for Invite & send a Bye > immediately after that. > - It should have send a 487 towards the client > > Is my understanding right?
You write as if there is one particular way the situation must be handled. There are multiple ways an SBC can operate in a situation like this. One way is to act much like a proxy would. That is, it sends a 200 response to the CANCEL that it received, and sends a CANCEL downstream. It then responds to the INVITE it received in the same way as the response it receives to the INVITE it sent downstream. In this way, it is delegating the question of how to handle the CANCEL to the UAS(s) downstream. Another way is to decide upon receiving the CANCEL that it will cancel the call. Again, it sends a 200 response to the CANCEL, and sends a CANCEL downstream. But since it has decided to cancel the call, it can immediately send a 487 response to the INVITE it received. It also waits for responses to the INVITE it sent downstream. Any failure responses it just ACKs. But if it receives 2xx responses, it has to ACK one and then send a BYE request to terminate each dialog. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
