Hi Meir,
The example that I suggested was a very crude one in order to help Moin
understand the logic.I think the language might have caused some confusion
to you that the UAC sends a third SDP in the ACK. No actually what I meant
was that a subset of items from the initial offer has to agreed upon by the
both parties before the media session actually gets started.
As far as you question about a single chosen codec in the answer,AFAIK the
answer can have a list of codecs chosen from the subset of offer but they
have to be listed in the same order. This helps in assuring that the same
codec is used in
both directions.
For more details on Offer-Answer,have a look at rfc3264.
Regards
Sameer
-----Original Message-----
From: Meir Leshem [mailto:Meir.Leshem at veraznetworks.com]
Sent: Tuesday, September 19, 2006 12:23 AM
To: ssawhney at cisco.com; moin at sdf.lonestar.org;
sip-implementors at cs.columbia.edu
Subject: RE: [Sip-implementors] ACK is needed ??
Hi,
Most of the explanation is good and useful, however in the last paragraph
you provided an example with offer (in the Invite) of 10 items from the
UAC, answer in the 200 OK with 5 items from the UAS and a final choose of
one item from the UAC in the ACK. Do you mean that a third SDP (a new
offer?) is sent within the ACK? So how the UAS will send its final answer?
BTW, in telephony (VoIP) calls, I have never seen something else than a list
of codecs in the "offer" and a single chosen codec in the "answer"
SDP. So this behavior is the only commercial procedure for voip telephony as
far as I know. Is it correct?
Regards
Meir Leshem
-----Original Message-----
From: sip-implementors-bounces at cs.columbia.edu
[mailto:sip-implementors-bounces at cs.columbia.edu] On Behalf Of Sameer
Sawhney -X (ssawhney - Flextronics Software at Cisco)
Sent: Monday, September 18, 2006 9:43 PM
To: moin at sdf.lonestar.org; sip-implementors at cs.columbia.edu
Subject: Re: [Sip-implementors] ACK is needed ??
Hi,
The ACK of 200OK of INVITE serves multiple purpose. The primary purpose of
the ACK is to confirm the reception of the final response of the offer i.e
200 OK.
If the UAC did not send any offer in the initial INVITE, the 200 OK should
contain the offer and ACK contains the answer of the UAC.
The ACK for a 200 OK response to an INVITE request is considered as a
separate transaction and it completes the three way handshake procedure to
establish a SIP session.
Consider an imaginary situation where Bob and Alice has to agree on one
aspect of session (like codec to be used for the session).
The whole logic of 3 way handshake can be visualized in this simple example
where Bob initiates a SIP session towards Alice. Bob sends 10 aspects/items
which can used in initial INVITE . The UAS (Alice) sends back 200 OK
specifying that it can support 5 items, but you tell me which one would you
like to use for this session.
Now the final decision is in hand of Bob (UAC) to accept a particular
aspect/item and inform the UAS (Alice) about this. This final decision is
conveyed in an ACK of the INVITE request.
I hope this a very crude example (ps: this might not be the best way ) will
help you understand the logic behind the need of ACK for 200 OK.
For more details on ACK, refer rfc 3261. That will clear all your doubts!
-sameer
-----Original Message-----
From: sip-implementors-bounces at cs.columbia.edu
[mailto:sip-implementors-bounces at cs.columbia.edu] On Behalf Of
moin at sdf.lonestar.org
Sent: Monday, September 18, 2006 9:37 AM
To: sip-implementors at cs.columbia.edu
Subject: [Sip-implementors] ACK is needed ??
Hi,
What was the intention behind proposing the need for sending ACK after 200OK
of INVITE under SIP.
_______________________________________________
Sip-implementors mailing list
Sip-implementors at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors