[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    RE: [Sip-implementors] reINVITE
From:       <srivastava.vivek () wipro ! com>
Date:       2004-07-30 11:31:48
Message-ID: 44CA2174A6432542AD99570ADA4A636A017F179A () blr-ec-msg03 ! wipro ! com
[Download RAW message or body]


Inline...


-----Original Message-----
From:	sip-implementors-bounces@cs.columbia.edu on behalf of Mukul Purohit
Sent:	Fri 7/30/2004 4:13 PM
To:	Marc Petit-Huguenin
Cc:	sip-implementors@cs.columbia.edu
Subject:	Re: [Sip-implementors] reINVITE
> > Hi,
> > 
> > 
> > Marc Petit-Huguenin wrote:
> > 
> > > Reposted, as I really would like to have a definitive answer on this.
> > > 
> > > Thanks.
> > > 
> > > 
> > > 
> > > I would like to have a confirmation that an UAS must be ready to
> > > receive a
> > > new INVITE in a dialog as soon a response was sent for the previous
> > > INVITE.
> > > More precisely, the UAS must not wait for the ACK before accepting
> > > the next
> > > INVITE.
> > > 
> > > My reasoning is based on the fact that RFC3261 section 14.1 says that
> > > "If
> > > there is an outgoing INVITE client transaction, the TU must wait
> > > until the
> > > transaction reaches the completed or terminated state before
> > > initiating the
> > > new INVITE." As an INVITE transaction reaches the completed or
> > > terminated
> > > state as soon a non-provisional response is received, the next INVITE
> > > can
> > > be sent at the same time the ACK for the 200 response is sent. As the
> > > packet ordering can change, the INVITE can arrive at the UAS before the
> > > ACK. So this mean that the server should be prepared to receive the next
> > > INVITE before receiving the ACK.
> > 
> > 
> > 
> > Completed State for client-invite is reached only when the response
> > was 3xx-6xx, and not any non-provisional response (I mean 200 ).
> > As per section 13.3.1.4 , 2xx retransmission is handled by UA core.A
> > 2xx response is passed to Transport layer periodically, for all
> > protocols, until an ACK is received. This retransmission starts at T1
> > seconds, and doubles until it reaches T2 seconds.
> > 
> > Finally if the there is no ACK, session SHOULD be terminated, by
> > sending a BYE.
> > 
> > So Answer to your question : UAS must wait for an ACK, before
> > accepting any request within the dialog.
> 
> 
> Again, I disagree with this interpretation. If it was true, it means
> that the UAC must wait 32 seconds (64*T1) before sending the second
> reINVITE to be sure that the ACK is received by the UAS, or that a BYE
> is sent by the UAS in case all the ACK are lost.
UAC need not wait to send a re-Invite, it is the UAS that say no to the
re-Invite, because the 3-way handshake of previous Invite(The original
Invite) is not yet complete. It does not make any sense to change the
parameters, until there "exist" some parameters (which will exist only
after the Call is esatblished, i.e. Invite-Ok-Ack is Complete).

Vivek: SIP follows the offer/answer model and if offer comes in INVITE and answer \
goes in 200 OK, UAS can recieve another offer.

> This means that a phone must wait 32 second after the establishment of a
> call before be able to put a call on hold. And wait again 32 seconds
> before be able to un-hold. No very useable.
Establishment of call means the RTP session has started. This wont until
the 3-way handshake is complete. A phone need not wait for 32 sec
"After" establishment of the call. There after it can put on hold.

Hope this explains :)
mukul

_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors








Confidentiality Notice

The information contained in this electronic message and any attachments to this \
message are intended for the exclusive use of the addressee(s) and may contain \
confidential or privileged information. If you are not the intended recipient, please \
notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies \
of this message and any attachments.


[prev in list] [next in list] [prev in thread] [next in thread]