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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 21 Nov 2005 11:03:53 -0500

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 

_______________________________________________
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: Fatih "Eyüp" NAR <[email-masked]>
Date: Mon, 21 Nov 2005 08:24:49 -0800 (PST)

I think that using re-invite for the sessions that are
not completed (i.e. 200 ok not received) do not make
sense , instead usage of UPDATE more appropriate ...

--- "Michael Hammer (mhammer)" <[email-masked]>

> Use [email-masked] for new developments on the

__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

---

From: Ramesh <[email-masked]>
Date: Mon, 21 Nov 2005 09:48:12 -0700

There are issues with update. You will really not know if "UPDATE" is
supported until response other than trying is made. So the only method that
you can use is INVITE. Here in this perticular interop scenario the initial
invite did not have the complete routable information so the subsequent
invites will update the number.
As Mr. Hammer pointed out the invites that were send need to be acked. I
don't know with what error messag they will be acked.

Ramesh

---

From: Ramesh <[email-masked]>
Date: Tue, 22 Nov 2005 08:42:11 -0700

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:
>  ------------------------------
> *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:
> >
> > 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
> >
> >
> >

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 22 Nov 2005 11:17:08 -0500

484.

Ramesh wrote:
> 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] 
> <mailto:[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]>
>         [mailto:[email-masked] <mailto:[email-masked]>] *On
>         Behalf Of *Ramesh
>         *Cc:* [email-masked] <mailto:[email-masked]>
>         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]
>         <mailto:[email-masked]>> wrote:
> 
>             3) B responds with 100 and then 180 Ringing(wthout SDP)  and
>             adds TO tag to
>             180.
>             Is it the right behaviour, if not then what should be the
>             right behaviour of
>             B?
> 
> 
>             -Manjeet
> 
> 
> 
>             Use [email-masked]
>             <mailto:[email-masked]> for questions on
>             current sip
>             Use [email-masked] <mailto:[email-masked]> for new
>             developments on the application of sip
> 
> 
> 
> 
>         -- 
>         cheers
>         ramesh 
> 
> 
> 
> 
> -- 
> cheers
> ramesh
> 
> 
> ------------------------------------------------------------------------
>