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
