Hi Munish How can you forget the INFO request, u need to acknowledge it right?
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
