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:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 12:23 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sameer Sawhney -X (ssawhney - Flextronics Software at Cisco) Sent: Monday, September 18, 2006 9:43 PM To: [EMAIL PROTECTED]; [email protected] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, September 18, 2006 9:37 AM To: [email protected] 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 [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
