----- Original Message ----- From: "Christer Holmberg" <[EMAIL PROTECTED]> To: "Sarju Garg" <[EMAIL PROTECTED]> Cc: "Bob Penfield" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 6:42 AM Subject: Re: [Sip-implementors] Use of INFO before sending ACK
> > 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. You should not send an INFO before you receive a 1xx with a To tag. According to section 12.2 in bis-05: Once a dialog has been established between two UAs either of them MAY initiate new transactions as needed within the dialog. A dialog (a.k.a. call-leg) is not "established" until the UAC receives a 1xx or 2xx response. The 1xx response MUST have a tag in the To header. > > >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? If the UAC refrains from sending the INFO before the dialog is established, this issue is avoided. > > 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. I agree. This is not a "Conflict", there is no existing dialog/call-leg state for it to conflict with. The dialog/call-leg does not exist yet. > > >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 > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
