Thanks. SO to summarize,
UAC sends INVITE and then INFO. INFO can be sent before receiving 1xx or 200 response or sending ACK. 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. 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? I think INFO RFC says that INFO must only be sent in session ESTABLISHED state. SO I feel 409 is the right message. 481 is not becoz call leg do exist. 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. What do others say? Thanks Sarju ----- Original Message ----- From: Christer Holmberg <[EMAIL PROTECTED]> To: Bob Penfield <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; 'Sarju Garg' <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 12:17 PM Subject: Re: [Sip-implementors] Use of INFO before sending ACK > > Hi, > > Just to clarify. The INFO RFC says that the session must be established > when it's used. The possibility of using it also BEFORE the session is > established, ie the UAC has only received a provisional response, was > agreed upon on the SIP list. > > But, yes, 481 is what the UAS shall send if it receives something it > doesn't have any call state for. > > Regards, > > Christer Holmberg > Ericsson Finland > > > Bob Penfield wrote: > > > > ----- Original Message ----- > > From: "Ranjit Avasarala" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]>; "'Bob Penfield'" <[EMAIL PROTECTED]> > > Cc: "'Sarju Garg'" <[EMAIL PROTECTED]>; "'Christer Holmberg'" > > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > Sent: Monday, November 12, 2001 10:27 AM > > Subject: RE: [Sip-implementors] Use of INFO before sending ACK > > > > > Hi Munish > > > > > > How can you forget the INFO request, u need to acknowledge it right? > > > > I think that a 481 response is what RFC 2976 calls for when an INFO arrives > > when there is not an established call-leg (a.k.a. dialog). In any event, > > some 4xx response needs to be sent. > > > > > > > > Regards > > > Ranjit > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > > Sent: Monday, November 12, 2001 8:31 AM > > > To: Bob Penfield > > > Cc: Sarju Garg; Christer Holmberg; [EMAIL PROTECTED] > > > Subject: Re: [Sip-implementors] Use of INFO before sending ACK > > > > > > > > > > > > > > > Hi Bob.. > > > You are right... as Christer already pointed out INFO cannot not be used > > > for > > > Overlap dialing.. > > > I cannot think of any other scenerio in which INFO can be used before > > > the call > > > is established except for supporting services. > > > Then I think the only option left in Sarju's case is to send 200OK > > > response and > > > forget about the INFO request received. > > > > > > What do you suggest?? > > > > > > Rgds, > > > Munish > > > > > > > > > > > > > > > > > > "Bob Penfield" <[EMAIL PROTECTED]> on 11/12/2001 07:27:06 PM > > > > > > To: "Sarju Garg" <[EMAIL PROTECTED]>, Munish Chhabra/HSS@HSS, > > > "Christer > > > Holmberg" <[EMAIL PROTECTED]> > > > cc: [EMAIL PROTECTED] > > > > > > Subject: Re: [Sip-implementors] Use of INFO before sending ACK > > > > > > > > > > > > > > > If you take into account the dialog rules in bis-05, and INFO can only > > > be > > > sent for an early or established dialog and it must contain a From tag > > > and a > > > To tag. If a UAS received an INFO before it sent back a 1xx or 2xx with > > > a To > > > tag, it could consider it a non-existent call-leg (a.k.a. dialog), which > > > according to RFC 2976 MUST be responded to with 481. 409 has been > > > removed > > > from bis, and even if it had not, I don't think "Conflict" is the > > > correct > > > response. None of the other response codes seem to fit this case. > > > > > > cheers, > > > (-:bob > > > > > > Robert F. Penfield > > > Chief Software Architect > > > Acme Packet, Inc. > > > 130 New Boston Street > > > Woburn, MA 01801 > > > [EMAIL PROTECTED] > > > > > > ----- Original Message ----- > > > From: "Sarju Garg" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]>; "Christer Holmberg" > > > <[EMAIL PROTECTED]> > > > Cc: <[EMAIL PROTECTED]> > > > Sent: Monday, November 12, 2001 4:35 AM > > > Subject: Re: [Sip-implementors] Use of INFO before sending ACK > > > > > > > > > > Hi Munish, > > > > > > > > Can i send 409 in this case? I do not expect INFO during call > > > establishment > > > > phase and hence 409. > > > > > > > > sarju > > > > > > > > ----- Original Message ----- > > > > From: <[EMAIL PROTECTED]> > > > > To: Christer Holmberg <[EMAIL PROTECTED]> > > > > Cc: Sarju Garg <[EMAIL PROTECTED]>; > > > > <[EMAIL PROTECTED]> > > > > Sent: Monday, November 12, 2001 3:04 PM > > > > Subject: Re: [Sip-implementors] Use of INFO before sending ACK > > > > > > > > > > > > > > > > > > > > > > > Hi Christer.. > > > > > Another call scenerio in which INFO can be used before the call is > > > > established > > > > > is.. > > > > > For a Gateway - Gateway call > > > > > Overlap dialing from ISUP(ETSI) - SIP(T) , INFO message might > > > contain > > > > > embedded(tunneled) "SAM" message (more digits), which needs to be > > > > transmitted > > > > > just after sending INVITE. This might happen even before it has > > > received > > > > 18x. > > > > > Sarju, > > > > > I think in your kind of scenerio, you can send response to INFO > > > method > > > and > > > > just > > > > > ignore it (because all three options listed below might lead to call > > > > failure > > > > > incase INFO retransmission times out). > > > > > > > > > > Rgds, > > > > > Munish > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Christer Holmberg <[EMAIL PROTECTED]> on 11/12/2001 > > > > 02:44:40 PM > > > > > > > > > > To: Sarju Garg <[EMAIL PROTECTED]> > > > > > cc: [EMAIL PROTECTED] (bcc: Munish Chhabra/HSS) > > > > > > > > > > Subject: Re: [Sip-implementors] Use of INFO before sending ACK > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > The use of INFO for sending additional digits (if you are talking > > > about > > > > > overlap dialling) has also been discussed, and the general > > > understanding > > > > > then was that INFO should NOT be used for that. > > > > > > > > > > It is RECOMMENDED that overlap dialling is not done in SIP in the > > > first > > > > > place, but there is a draft (draft-ietf-sip-overlap-01.txt) on it. > > > > > > > > > > Regards, > > > > > > > > > > Christer Holmberg > > > > > Ericsson Finland > > > > > > > > > > > > > > > Sarju Garg wrote: > > > > > > > > > > > > Thanks for your quick response. I think this scenario is useful in > > > cases > > > > > > where all the digits are not known and the INVITE is sent. > > > Additional > > > > digits > > > > > > can be send in INFO message. But if I am building a UA for an end > > > > terminal > > > > > > user, then it should not receive INFO in such cases. What do you > > > say > > > in > > > > this > > > > > > case? How should I take in my UA call model? > > > > > > > > > > > > - sarju > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: Christer Holmberg <[EMAIL PROTECTED]> > > > > > > To: Sarju Garg <[EMAIL PROTECTED]> > > > > > > Cc: <[EMAIL PROTECTED]> > > > > > > Sent: Monday, November 12, 2001 2:16 PM > > > > > > Subject: Re: [Sip-implementors] Use of INFO before sending ACK > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > There was a discussion on this some time ago, and the general > > > > > > > understanding is that it IS allowed to send INFO before the UAC > > > has > > > > > > > received the 200 OK response and sent the ACK. > > > > > > > > > > > > > > However, unless the UAC has received a 18x provisional response, > > > with > > > > a > > > > > > > To header tag and Contact header to use in the INFO, it can NOT > > > assume > > > > > > > that proxis will handle/route an INFO in the same way as the > > > INVITE. > > > > For > > > > > > > this reason it may (depending on the scenario you want to use > > > INFO > > > > for) > > > > > > > be better if the UAS sends a 18x provisional response, instead > > > of > > > 100 > > > > > > > Trying, when it receives the INVITE, to make sure the UAC gets > > > the > > > To > > > > > > > tag and Contact header as soon as possible. They are also needed > > > if > > > > the > > > > > > > UAC wants to terminate the specific call setup leg using BYE. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer Holmberg > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > Sarju Garg wrote: > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > If the user sends a message that is not expected during the > > > call > > > > state > > > > > > > > ,then how should UA behave to this message? FOr example if the > > > > calling > > > > > > > > side UA sends INFO while the call is being established (UA > > > sends > > > > > > > > INVITE and then INFO without waiting to send ACK first), then > > > how > > > > the > > > > > > > > does called side UA interpret this INFO message. There are 3 > > > > > > > > possibilites: > > > > > > > > 1. Ignore it, will be retransmitted after sometime > > > > > > > > 2. Save it, send 1xx message and process it after receiving > > > ACK > > > > > > > > 3. Send 409 message saying that this message is received at > > > wrong > > > > > > > > time. > > > > > > > > > > > > > > > > To me, 2 seems to be the right option. Please let me know > > > which > > > > would > > > > > > > > be the correct behavior. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Sarju > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
