"Anil Bollineni" <[EMAIL PROTECTED]> 
06/21/2005 04:58 AM

To
"Rajeev Seth" <[EMAIL PROTECTED]>, "jaganmohan" 
<[EMAIL PROTECTED]>
cc
<[EMAIL PROTECTED]>, 
<[email protected]>
Subject
RE: [Sip-implementors] doubt about handling of multiple 2xxresponses due 
to forked proxy






Here mentioned, each 2xx response is passed to upper layers for 
processing. So no transactions are created.
17.1.1.2
        Thus, each 2xx needs to be passed to a proxy
   core (so that it can be forwarded) and to a UAC core (so it can be
   acknowledged).  No transaction layer processing takes place.
   Whenever a response is received by the transport, if the transport
   layer finds no matching client transaction (using the rules of
   Section 17.1.3), the response is passed directly to the core.  Since
   the matching client transaction is destroyed by the first 2xx,
   subsequent 2xx will find no match and therefore be passed to the
   core.
=================================
This explains the behavior of UAC on receiving a subsequent 2xx after the 
first 2xx has been received and the transaction has gone to "terminated" 
state. The subsequent 2xx will be passed to the core (without creating a 
transaction)and following can happen
1. UAC core will retransmit ACK if the 2xx is a retransmitted response.
2. UAC core may create a new dialog if the TO TAG in 2xx is different than 
the one received in the 2xx received earlier for the same INVITE. 
3. Proxy core will forward this 2xx as a stateless proxy to UAC ( As per 
16.7) 
The point here is that if the *subsequent 2xx* is received after 64*T1 
seconds of after the receipt of first 2xx response,  UAC core will drop it 
and will not take either action 1 or 2 as listed above.
The another point to consider is that UAC can also receive more than one 
1xx responses with different TO-TAGS ie. two 180 responses sent by two 
UE's on receiving forked INVITE's. This will also result in establishing 
two early dialogs at UAC. Also there will be two separate transactions in 
the transaction layer at UAC in the *proceeding* state for the same 
INVITE.
 Here UAC can terminated one of the dialog( by sending BYE) once the 2xx 
is received on another dialog.
=================================

13.2 (3261)
  The UAC core considers the INVITE transaction completed 64*T1 seconds
   after the reception of the first 2xx response.  At this point all the
   early dialogs that have not transitioned to established dialogs are
   terminated. Once the INVITE transaction is considered completed by
   the UAC core, no more new 2xx responses are expected to arrive.
Can somebody explain the case, where multiple 2xx responses create 
multiple dialogs on UAC side, and results in multiple dialogs for the same 
call same time. What I understood is when UAC receives first 2xx response, 
it can't accept no more 2xx responses from above statement. 
==============
 
==============
Above statement clarifies that the UAC will not be able to accept a 2xx 
response "which is received after 64*T1 secs" of initiating an INVITE 
transaction. However all the 2xx responses received *within this period* 
will be passed to the core and the UA core can acknowledge them and create 
separate dialogs for each 2xx.
This way the UAC will have multiple dialogs with different UAS's resulting 
out of an INVITE forked by Proxy.
Section 13.1 
"Therefore, when multiple 2xx  responses are received from different 
remote UAs (because the INVITE forked), each 2xx establishes a different 
dialog.  All these dialogs
are part of the same call"


===============
Thanks,
Anil


-----Original Message-----
From: [EMAIL PROTECTED] [
mailto:[EMAIL PROTECTED] On Behalf Of Rajeev Seth
Sent: Thursday, June 16, 2005 3:19 AM
To: jaganmohan
Cc: [EMAIL PROTECTED]; 
[email protected]
Subject: Re: [Sip-implementors] doubt about handling of multiple 
2xxresponses due to forked proxy
jaganmohan <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
06/16/2005 02:25 PM

To
[email protected]
cc
Subject
[Sip-implementors] doubt about handling of multiple 2xx responses due to 
forked proxy



  Hi all,
                 i have a doubt about handling of multiple 2xx responses 
due to forked proxy
                 please clarify this
                 The UAC has sent an INVITE request and it is forked by 
the proxyserver.
Question:
                 Does UAC is going to start any timer after receiveing the 

first 200OK
response,
                 as the transaction is ended after receiving the first 2xx 

response?
===========================================
UAC will not know whether the proxy has forked the request or not. 
Therefore it has to terminate the transaction as soon it gets a 2xx for an 

INVITE. However if the UAC receives another 2xx from different remote UAs 
(because the INVITE forked), it has to create a new transaction for 
handling this 2xx. As per 3261 this will also result into a new dialog 
being created at UAC (13.1)
--Rajeev--
===========================================
thanks in advance
JMR



jaganmohan <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
06/16/2005 02:25 PM

To
[email protected]
cc
Subject
[Sip-implementors] doubt about handling of multiple 2xx responses due to 
forked proxy





  Hi all,
                 i have a doubt about handling of multiple 2xx responses 
due to forked proxy
                 please clarify this
                 The UAC has sent an INVITE request and it is forked by 
the proxyserver.
Question:
                 Does UAC is going to start any timer after receiveing the 

first 200OK
response,
                 as the transaction is ended after receiving the first 2xx 

response?
thanks in advance
JMR
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


***********************  FSS-Private   ***********************
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


***********************  FSS-Unclassified   ***********************
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to