Subject: RE: [Sip] Query about '491 response' in case of RE-INVITE.

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 22 Nov 2005 11:09:06 -0500

I belive you are correct as to 484 being sent.
 
Mike

________________________________

	From: Ramesh [mailto:[email-masked]] 
	Sent: Tuesday, November 22, 2005 10:42 AM
	To: Michael Hammer (mhammer)
	Cc: Manjeet Soodan; [email-masked]
	Subject: Re: [Sip] Query about '491 response' in case of
RE-INVITE.

	What should be the response to close the Invite transaction in
case of the subsequent INVITE, would it be 484 address incomplete. It
cannot be 200ok.
	
	Cheers
	Ramesh

	On 11/21/05, Michael Hammer (mhammer) <[email-masked]> wrote:

		Ramesh,
		 
		Be very carerful with the overlap signaling.  In fact,
the subsequent INVITEs that A sends are each new dialogs, with each old
previous dialog being later rejected.  They are not updates to the same
dialog.
		 
		Mike

________________________________

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ramesh
			Sent: Monday, November 21, 2005 10:55 AM
			To: Manjeet Soodan
			Cc: [email-masked]
			Subject: Re: [Sip] Query about '491 response' in
case of RE-INVITE.

			I think it is wrong to send the 491 in this
case. 491 response can only be sent by A to B, in your example, if B
sends an INVITE to A. A can send multiple Invites as these are nothing
but updates to the original. If you look at the ISUP-SIP overlap
signaling ( RFC 3578)  you will see this scenario described when SAM
messages are sent.
			
			Cheers
			Ramesh

			On 11/17/05, Manjeet Soodan
<[email-masked]> wrote: 

				1) There are two SIP UA's A and B.
				2) A sends INVITE with SDP to B.
				3) B responds with 100 and then 180
Ringing(wthout SDP)  and adds TO tag to
				180.
				3) After 180 is received, A sends a
RE-INVITE before 200 OK is received 
				(i.e RE-INVITE with all the headers
having same value as initial INVITE and
				higher CSEQ value).
				4) In this case B responds with a  '491
Request Pending' for RE-INVITE.
				
				Is it the right behaviour, if not then
what should be the right behaviour of 
				B?

				-Manjeet

	
_______________________________________________
				Sip mailing list
https://www1.ietf.org/mailman/listinfo/sip
				This list is for NEW development of the
core SIP Protocol 
				Use [email-masked] for
questions on current sip
				Use [email-masked] for new
developments on the application of sip 

			-- 
			cheers
			ramesh 

	-- 
	cheers
	ramesh 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dale R. Worley" <[email-masked]>
Date: Tue, 22 Nov 2005 11:44:18 -0500

>                 the subsequent INVITEs that A sends are each new
>                 dialogs, with each old previous dialog being later
>                 rejected.  They are not updates to the same dialog.

>                         case. 491 response can only be sent by A to B,
>                         in your example, if B sends an INVITE to A. A
>                         can send multiple Invites as these are nothing
>                         but updates to the original. If you look at
>                         the ISUP-SIP overlap signaling ( RFC 3578)
>                         you will see this scenario described when SAM
>                         messages are sent.

>                                 3) After 180 is received, A sends
>                                 a  RE-INVITE before 200 OK is
>                                 received 
>                                 4) In this case B responds with
>                                 a  '491 Request Pending' for RE-
>                                 INVITE.
>                                 

The rules for handling these situations are in section 14 of RFC 3261.

The first issue is whether an INVITE is a re-INVITE, that is, whether it
is within an existing dialog.  Section 14.2 paragraph 1 refers to
section 13.3.1 for how to make this distinction.  Basically, if it
contains a to-tag, it is in-dialog, and if it does not, it is out-of-
dialog.  If an INVITE is out-of-dialog, it does not interact with any
previous INVITE (other than that a UA may reject it as erroneous, since
it has the same Call-Id as a previous dialog).

Within a dialog, a re-INVITE cannot be processed while another INVITE is
being processed.  If the INVITE being processed was sent by the sender
of the new INVITE, the server should reject the latter with 500 (section
14.2 paragraph 2).  If the INVITE being processed was sent by the other
UA, the recipient of the new INVITE must reject it with 491 (section
14.2, paragraph 3).

Dale