As Christer mentioned, the current proposal is described in: http://www.ietf.org/internet-drafts/draft-ietf-sip-overlap-01.txt
It involves sending a new INVITE with the additional digits added in the To header. This INVITE, even though it uses the same Call-ID, should be seen as a new call-leg since the To is now different (it has more digits). Therefore, when the UAC finally decides there are no more digits, it needs to CANCEL all the other INVITEs. It may also need to send BYE on any unwanted call-legs established by a 2xx or a 1xx with a To-tag. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 [EMAIL PROTECTED] ----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Bob Penfield" <[EMAIL PROTECTED]> Cc: "Sarju Garg" <[EMAIL PROTECTED]>; "Christer Holmberg" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, November 12, 2001 9:31 AM 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
