I will answer comments inline, but let me first shout this at the top of my
e-lungs:
*********!!!!!!!!!!!!!!!!!!!!!!!!!!!! YOU MUST ACK THE FINAL RESPONSE TO THE
INVITE EVEN IF YOU WANT TO HANGUP!!!!!!!!!!!!!!!!!!!**********************
This is based on the concept which I have been trying, without much success,
it seems, to hammer home about SIP. That concept is:
All transactions complete independently
All transactions complete independently
All transactions complete independently
ACK is a funny beast, and it is both part of the transaction and not. For
purposes of this mantra, it is part of it.
Now, to reiterate this with some inline answers:
> -----Original Message-----
> From: Gautham A N [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 11, 2001 11:18 AM
> To: Vijay Gurbani
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Sip-implementors] doubt in BYE and ACK
>
>
> hi,
> In the call flow example of 20.5, a BYE has not been sent
> before the ACK.
> The reason for this is not that the protocol prohibits it. It
> is because the
> user Bell doesnot know who among the 2 persons who answered
> to his INVITE is
> the 'real' Watson. Only after the media stream starts and he
> is able to talk
> to both the persons has he been able to ascertain to whom he
> wants to talk
> to ( X or Y). So, how can this example be taken to be
> saying that an ACK
> is mandatory ?
The example shows that ACK is sent. The normative text in bis-03 15.3 can't
be much clearer. It says (and please read the first sentence):
The UAC MUST generate an ACK request for each distinct call leg created by a
2xx. The Request-URI
and Route headers for the ACK are constructed as described in Section 16.4.
The To field in the ACK
MUST contain the remote address for the call leg (which includes the tag).
The From field in the ACK
MUST contain the local address for the call leg. The Call-ID MUST contain
the Call-ID for thecall leg.
The Via header in the ACK MUST be indentical to the one in the request being
acknowledged, including any
branch parameter. The CSeq number MUST be the same as the INVITE being
acknowledged, but the CSeq
method MUST be ACK.TheACK might possibly require a session description in
the body. See Section B
for guidelines.
After acknowledging, the caller MAY choose to terminate the call leg with a
responding UAS by sending
a BYE request. Procedures for doing so are defined in Section 15.4.
I think "The UAC MUST generate an ACK request for each distinct call leg
created by a 2xx" is pretty clear.
> Also, what about section 1.4.4 of the RFC2543 which
> specifically says "If
> the caller no longer wants to participate in
> the call, it sends a BYE request instead of an ACK."
This is a bug, and has been fixed in bis-03, which is the text that everyone
has been pointing you to.
> Has this been
> contradicted elsewhere?
Yes, in the above text from bis-03 which I have quoted.
> Also, should the UA not
> retransmitting the 200 OK ,
> once it receives a BYE?
The transaction should complete independently. So, it should continue to
retransmit the 200 OK until it gets an ACK.
> Is there anything specific for or
> against this in
> the bis-03?
Nothing in bis-03 tells you to do it. The state machines are clearly
defined, and they explicitly show retransmissions of the final response
until INVITE.
Stopping transmissions of the 2xx will BREAK intermediate proxies. Remember,
SIP is a transactional protocol, and proxies are transactional elements.
They do not track call state normally, and they will leak memory if you
leave transactions hanging like this.
> if so, where?
Figure 11, section 15.1, outlines the FSM for the INVITE server. It clearly
shows response retransmissions until ACK arrives.
> One more thing the RFC says that though an ACK completes a succesful
> 'session establishment' it says that an ACK comprises a
> transaction of its
> own?
ACK and CANCEL are weird pseudo-beasts, with ACK being the strangest of all.
In some ways its its own transaction, and in other ways, its not. I think in
most useful characteristics, it is part of the INVITE transaction. THis
definitely needs better explanation. The trick is not to get caught up in
the definitions, but follow the normative text.
-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
