> ----- 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.
Just to clarify myself, A 1xx response is not required to have a To tag. A To tag is required to establish a dialog. A 1xx without a tag is still outside of a dialog. > > > > > >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 > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
