----- 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
