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

List:       sip-implementors
Subject:    Re: [Sip-implementors] B2BUA
From:       Ravi Kumar <ravikumar () huawei ! com>
Date:       2011-08-10 13:23:06
Message-ID: 083D129BCDF74CDFBFE8761E98780E87 () china ! huawei ! com
[Download RAW message or body]


Hi Tabt,
	I have one confusion with respect to your query. 
	You have concern about retransmission of 2xx response but that will
be done bye server not client but text that you have mentioned is about
invite client transaction.

	Retransmission of 2xx response of invite request is by UAS refer to
section 13.3.1.4 The INVITE is Accepted of RFC 3261.
	The 2xx response is passed to the transport with an
   interval that starts at T1 seconds and doubles for each
   retransmission until it reaches T2 seconds.

	T1 is 500ms and T2 is 4s. So maximum retransmission of 2xx response
can be done is 4 times.

	If application do not want retransmission than use reliable
transport that is TCP. 

Thanks & Regards,
Ravi Kumar


****************************************************************************
****************************
 This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it

-----Original Message-----
From: sip-implementors-bounces@lists.cs.columbia.edu
[mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of Couret
Tabt
Sent: Thursday, July 28, 2011 2:54 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] B2BUA

Sorry, Figure1 is the following:


Alice          Atlanta (INTERNET)  Biloxi             Bob
  |              |                      |              |
  |--F1 INVITE-->|                      |              |
  |              |---F2 INVITE--------->|              |
  |              |                      |              |
  |              |                      |--F3 INVITE-->|
  |              |                      |              |
  |              |                      |<---F4 200----|
  |              |<----F5 200-----------|              |
  |<--F6 200-----|                      |              |
  |--- F7 ACK--->|                      |              |
  |              |------F8 ACK--------->|              |
  |              |                      |----F9 ACK--->|
  |              |                      |              |



2011/7/28 Couret Tabt <courettabt@gmail.com>:
> Thanks, Castillo,
>
> In details, that is the following.
>
> Figure 1:
>
> Alice            Atlanta (INTERNET)  Biloxi               Bob
>  |                     |                            |                    
|
>  |--F1 INVITE-->|                             |                     |
>  |                     |---F2 INVITE--------->|                     |
>  |                     |                             |                    
|
>  |                     |                             |--F3 INVITE-->|
>  |                     |                             |                    
|
>  |                     |                             |<---F4 200------|
>  |                     |<----F5 200-------------|                     |
>  |<--F6 200-------|                             |                     |
>  |--- F7 ACK---->|                             |                     |
>  |                     |------F8 ACK---------->|                     |
>  |                     |                             |----F9 ACK---->|
>  |                     |                             |                    
|
>
> In RFC3261,  the following is described about retransmission time.
>
>
--------------RFC3261-------------------------------------------------------
-----------
> 17.1.1 INVITE Client Transaction
>
> 17.1.1.1 Overview of INVITE Transaction
>
>   The INVITE transaction consists of a three-way handshake.  The client
>   transaction sends an INVITE, the server transaction sends responses,
>   and the client transaction sends an ACK.  For unreliable transports
>   (such as UDP), the client transaction retransmits requests at an
>   interval that starts at T1 seconds and doubles after every
>   retransmission.  T1 is an estimate of the round-trip time (RTT), and
>   it defaults to 500 ms. ...
>
----------------------------------------------------------------------------
----------------------
>
>
> In Figure 1 sequence, usually, the time between F4 and F9 may be
> over 500 ms. Then Bob may often re-transmit 200 OK.
>
> If we want to avoid those retransmissions of 200 OK, then
> what should we do?
>
> Yours truly,
> Tabt,
>
>
> 2011/7/28 Iņaki Baz Castillo <ibc@aliax.net>:
>> 2011/7/28 Couret Tabt <courettabt@gmail.com>:
>>> That is to say,
>>> if we do NOT use B2BUA,
>>> we need much time to receive ACK for 200 OK,
>>> especially  in Internet.
>>> Then, we have re-transmitting of 200 OK.
>>>
>>> The solution of that is B2BUA.
>>> Accordingly, most SIP system ( though Internet)
>>> adopt B2BUA.
>>>
>>> Am I right?
>>
>> The reasons for using a B2BUA are not "avoiding 200 retransmission".
>> Retransmissions indeed exist and are 100% covered by RFC 3261 so they
>> MUST NOT be a problem.
>>
>> B2BUA are used to build like-PBX services and so. Also, they don't
>> "solve retransmissions" always, as typically they send the ACK (for a
>> 200) in leg B after the ACK arrived from leg A. So the callee could
>> send 200 retransmissions until it receives the ACK.
>>
>> In short, I suggest you to forget that reasoning.
>>
>> Regards.
>>
>> --
>> Iņaki Baz Castillo
>> <ibc@aliax.net>
>>
>

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



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