Sarju Garg wrote:
> Thanks.
>
> SO to summarize,
>
> UAC sends INVITE and then INFO. INFO can be sent before receiving 1xx or 200
> response or sending ACK.
I don't think INFO makes much sense out of a dialog. THerefore, I do not
think you should send it until one is established, either with 1xx or 2xx.
> UAS on receiving INFO should check the call state. If the UAS has received
> INVITE and sent 200 or 1xx then handle INFO properly.
The UAS would check if the INFO matches an existing dialog. If it does,
its processed. Otherwise, a 481 is sent.
If have received
> INVITE but not processed it, then sent 481.
It is not clear what "not processed it" means. The rule above is clear;
if the UAS has a dialog (because it sent either a 1xx or 2xx), the INFO
is responded to with 200, else 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?
All of this is the reason that you are not supposed to send the INFO
until the dialog is created.
>
> I think INFO RFC says that INFO must only be sent in session ESTABLISHED
> state. SO I feel 409 is the right message.
No. 409 was used for a particular registration error that is no longer
needed. If a UAS gets an INFO that does not match any dialogs, its a 481
response.
> 481 is not becoz call leg do
> exist.
Then its not an error. I do not understand the case you are concerned about.
> ----- 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
>
--
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PH: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
