Subject: [Sip] Re: [Sip-implementors] Query on Re-transmission of non 2xx responses in an Invite Transaction

From: [email-masked]
Date: Wed, 22 Jun 2005 11:39:52 -0400

Aman,

For INVITE transaction, retransmission of requests will only occur when 
client had not received the provisional responses.
In this case, server needs to send the responses for each retransmitted 
request since client transaction is still inCalling state.

In case, when provisional response had been received, no retransmission of 
request occur, and server transaction needs to retransmit final responses 
till it get an ACK. Timer G basically taking care of the retransmission of 
the final responses till ACK is received. 

Hope it clarifies your doubt.

Regards,
Udit

Aman Arora <[email-masked]> 
Sent by: [email-masked]
06/22/2005 05:03 AM

To
[email-masked], [email-masked], 
[email-masked]
cc

Subject
[Sip-implementors] Query on Re-transmission of non 2xx responses in     an 
Invite Transaction

Hi all,

Section 17.2.1 of RFC 3261 says the following for the Invite Server
Transaction:

While in the "Proceeding" state, if the TU passes a response with
status code from 300 to 699 to the server transaction, the response
MUST be passed to the transport layer for transmission, and the state
machine MUST enter the "Completed" state.  For unreliable transports,
timer G is set to fire in T1 seconds, and is not set to fire for
reliable transports.

This is a change from RFC 2543, where responses were always
retransmitted, even over reliable transports.

Additionally as per Figure 7 in the RFC, we are also supposed to
re-transmit the responses, on
receiving the re-transmitted request (as in case of the non-Invite
transaction).

|INVITE
|pass INV to TU
INVITE             V send 100 if TU won't in 200ms
send response+-----------+
+--------|           |--------+101-199 from TU
|        | Proceeding|        |send response
+------->|           |<-------+
|           |          Transport Err.
|           |          Inform TU
|           |--------------->+
+-----------+                |
300-699 from TU |     |2xx from TU        |
send response   |     |send response      |
|     +------------------>+
|                         |
INVITE          V          Timer G fires  |
send response+-----------+ send response  |
+--------|           |--------+       |
|        | Completed |        |       |
+------->|           |<-------+       |
+-----------+                |
|     |                   |
ACK |     |                   |
-   |     +------------------>+
|        Timer H fires    |
V        or Transport Err.|
+-----------+  Inform TU     |
|           |                |
| Confirmed |                |
|           |                |
+-----------+                |
|                      |
|Timer I fires         |
|-                     |
|                      |
V                      |
+-----------+                |
|           |                |
| Terminated|<---------------+
|           |
+-----------+

My doubt is that incase the server transaction (say within a Proxy) is
anyways re-transmitting
responses locally (when timer G fires), why do we need to support
re-transmission of responses
for a re-transmitted request, as is suggested in the figure.

One possible situation where this would be required is when, the request
re-transmission timer
at the client transaction is configured to a value less than that of timer
G. But even then when
timer G would fire in the server transaction, we would anyways re-transmit
the response once again.
Thus I feel this additional functionality of re-transmitting responses for
the re-transmitted requests
is not really required.

I would appreciate any clarification on this.

regards
Aman

***********************  FSS-Unclassified   ***********************
"DISCLAIMER: This message is proprietary to Flextronics Software Systems
Limited (FSS) and is intended solely for the use of the
individual to whom it is addressed. It may contain  privileged or
confidential information and should not be circulated or used for
any purpose other than for what it is intended. If you have received this
message in  error, please notify the originator immediately.
If you are not the intended recipient, you are notified that you are
strictly  prohibited  from  using, copying, altering, or disclosing
the contents of this message.  FSS  accepts no  responsibility  for loss 
or
damage arising from the use of  the information transmitted
by this email including damage from virus."

_______________________________________________
Sip-implementors mailing list
[email-masked]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
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: Rajeev Seth <[email-masked]>
Date: Thu, 23 Jun 2005 13:41:41 +0530

Hi Aman,

As per 17.2.1 the retransmission of the last sent response on receiving a 
retransmitted request is  MUST only  if the Server transaction is in the 
"Proceeding" state ( 1xx is sent).

However  17.2.1 says about *completed* state ( State after sending 
3xx..6xx responses)  ==>>

"while in the "Completed" state, if a request retransmission is  received, 
the server SHOULD pass the response to the transport for retransmission"

In the *completed* state not retransmitting the final response on 
receiving a retransmitted request may only lead to maximum delay of 4 secs 
for the response to reach to the UAC as timer G is MIN(2*T1,T2). Therefore 
it is not a  MUST condition.

Retransmitting the provisional response in the *proceeding* state is MUST 
because client transaction will stop the retransmission of requests ( 
Timer A  will stop in proceeding state) and possibly UAC will start a 
no-answer timer  on receiving a provisional response only.

Regards,

Rajeev

06/23/2005 12:53 PM

To
[email-masked]
cc
[email-masked], [email-masked], 
[email-masked]
Subject
Re: [Sip-implementors] Query on Re-transmission of non 2xx responses    in 
an Invite Transaction

hi Udit,

What will happen in a situation where we send out a non 2xx response to 
the
Invite before sending out any
provisional response?
Though 100 Trying is sent, yet in case of a cross, what is the need to
re-transmit the response for a re-transmitted
request, when anyways we are going to perform self re-transmissions? So 
why
does a server transaction need
to re-transmit a response on receiving a re-transmitted request in the
Confirmed State (as per figure 7 in the RFC)

My query was primarily for non 2xx (final responses) to an INVITE.

rgds
aman

             [email-masked] 
             om 
                                                                        To 

             06/22/2005 09:09          Aman Arora 
             PM                        <[email-masked] 

                                                                        cc 

                                       [email-masked], 
                                       [email-masked], 
                                       [email-masked] 

                                       a.edu 
                                                                   Subject 

                                       Re: [Sip-implementors] Query on 
                                       Re-transmission of non 2xx 
                                       responses in  an Invite Transaction 

 

Aman,

Regards,
Udit

 Aman Arora 
 <aman.arora@flextronicssoft 
 ware.com> 
 Sent by:                                                               To 

 sip-implementors-bounces@cs            [email-masked], 
 .columbia.edu                          [email-masked], 
                                        [email-masked] 

                                        ia.edu 
 06/22/2005 05:03 AM                                                    cc 

                                                                   Subject 

                                        [Sip-implementors] Query on 
                                        Re-transmission of non 2xx 
                                        responses in        an Invite 
                                        Transaction 

 

Hi all,

|INVITE
|pass INV to TU

regards
Aman

***********************  FSS-Unclassified   ***********************
"DISCLAIMER: This message is proprietary to Hughes Software Systems 
Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, 
or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."

***********************  FSS-Private   ***********************

---

From: Aman Arora <[email-masked]>
Date: Wed, 22 Jun 2005 14:33:00 +0530

Hi all,

                               |INVITE
                               |pass INV to TU

regards
Aman

the contents of this message.  FSS  accepts no  responsibility  for loss or

---

From: Aman Arora <[email-masked]>
Date: Thu, 23 Jun 2005 12:53:47 +0530

hi Udit,

What will happen in a situation where we send out a non 2xx response to the
Invite before sending out any
provisional response?
Though 100 Trying is sent, yet in case of a cross, what is the need to
re-transmit the response for a re-transmitted
request, when anyways we are going to perform self re-transmissions? So why
does a server transaction need
to re-transmit a response on receiving a re-transmitted request in the
Confirmed State (as per figure 7 in the RFC)

rgds
aman

             [email-masked]                                             
             om                                                            
                                                                        To 
                                                                        cc 
                                       [email-masked],                       

                                                                           

Aman,

Regards,
Udit

 Aman Arora                                                                
                                                                           
                                                                   Subject 

                                                                           

Hi all,

|INVITE
|pass INV to TU

regards
Aman

"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
notified that you are strictly prohibited from using, copying, altering, or