[SIPForum-discussion] thanks!&&other queation about invite transaction

[Herve Jourdain]

Hi,

 

I don¡¯t think the session as used in this sentence means more than 2
participants. I think that what RFC 3261 tells is that something is wrong,
so there should be a disconnection in some way.

The point is, depending on the state of the dialog, you can send CANCEL or
BYE. In this paragraph, I think they opt for BYE, hence the dialog needs to
be ¡°confirmed¡±, before it can be terminated by sending a BYE.

One reason for opting for BYE maybe that the transaction which sent the
initial 2XX has supposedly gone to TERMINATED state, hence there should be
no more information available to send a CANCEL for that transaction¡­

 

As to your remark about ACK, I don¡¯t totally agree. It¡¯s true that at the
state machine level, there seems to be no effect of ACK on transactions when
sent in response to 2XX (for other final responses, the ACK handling is part
of the state machines).

But this is because this part is mostly handled outside the state machines,
in the UA core ¨C either UAC core or UAS core. One of the reasons is that,
if you want generic ¡°state machines¡± for both proxies and user agents, you
need to do the handling of ACK in the core, because it will depend on the
type of application you¡¯re using it in.

For a proxy, you need to forward the 2XX, for a UAC, you need to send a ACK
when you receive a 2XX¡­ So the core ¨C whether proxy or UA ¨C will behave
differently, but the State Machines will remain the same¡­

At least, that¡¯s my current interpretation.

 

Regards,

 

Herve

 

  _____  

From: Óê ³Â [mailto:chen.yu26 at yahoo.com.cn] 
Sent: lundi 10 d¨¦cembre 2007 14:41
To: Herve Jourdain; discussion at sipforum.org
Subject: thanks!&&other queation about invite transaction

 

Herve,

THANKS A LOT ! I am very pleasure that you answer my question so exactly.

 

As you mentioned, I read the RFC3261 (13.3.1.4¡°The INVITE is Accepted¡±)
again. The UAS do not use any timer ,but rather a retransmission mechanism
for 200 OK before a ACK for this response is received. I got it.

 

However, there are still some related puzzle about the invite transaction:

1, the difference between session and dialogue. 

Well, the end of the 13.3.1.4 points out: ¡°If the server retransmits the
2xx response for 64*T1 seconds without receiving an ACK, the dialog is
confirmed, but the session SHOULD be terminated.¡±

 

I wonder why there are different treatment of 200 between session and dialog
?

In my opinion, the session means one caller with many callees, more than two
participants. While the dialogue is just point to point, two joiners. Is
that right?  

 

2. the terminating remark of invite transactions 

the 3261 states that when the invite server transaction transmit the 200
response, it will move to the "Terminated" state. And the client transaction
also enter to the same state since it receive the 200. 

 

So, it seems to me that the ACK has no effect on the invite transactions
(both client and server).Put it other way, the connection still can be built
up , even if without the reception of ACK.

 

Waiting for your kindly reply!

 

Your sincerely

Nora

 

  

  _____  

 <http://cn.mail.yahoo.com/promo/carnival07/index.html?source=xy> ½øÈëÑÅ»¢ÓÎ
Ï·¼ÎÄ껪£¬Ó®È¡Òº¾§ÏÔʾÆ÷£¡ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20071210/c87281a3/attachment-0002.html>