Hi,
>UAC sends INVITE and then INFO. INFO can be sent before receiving 1xx or 200 >response or sending ACK. It CAN be sent before you have received 1xx, but I am not sure it's a very good thing to do so. >UAS on receiving INFO should check the call state. If the UAS has received >INVITE and sent 200 or 1xx then handle INFO properly. If have received >INVITE but not processed it, then sent 481. I don't understand what you mean by "received INVITE but not processed it". I think it's an IMPLEMENTATION issue when you consider that you have some kind of call state. If you don't have it - no matter what you have sent or received - you send 481. >Issue is that when UAC will receive 481, it should realize this situation >and retransmit the INFO message. Also if multiple INFO are send, then >sequencing and reordering of INFO messages will come in place? This is also an implementation issue. And, if you wait for the 1xx before sending the INFO it shouldn't happen. >I think INFO RFC says that INFO must only be sent in session ESTABLISHED >state. That is because the RFC was released before it was realized that INFOs may be usable also before the session is fully established. >SO I feel 409 is the right message. I don't think so. Also, there is a discussion on if 409 should remain in the bis in the first place. >481 is not becoz call leg do exist. So, in that case, why would you send 481??? If you have call state, and accept the INFO, you send 200. >What 409 says is that "the request could not be completed due to >conflict with the current state of the resource". I interpret resource here >as call state. Again, if you have call state you should accept the INFO - no matter what the INFO RFC says. >What do others say? I have spoken :) Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
