Christer Holmberg (JO/LMF) wrote:
Hi,
Some comments inline ([CHH])
2. RFC 3261 says in 13.2.1 that :-
"The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE."
- Does this mean that if an INVITE is sent with SDP (offer) and then if it receives a non reliable provisional response with SDP and then it gets a 200 OK with SDP, then only the SDP in non-reliable provisional response must be considered as answer and the SDP in 200 OK must be blindly ignored ?
Yes.
[CHH] As was said earlier, non reliable provisional responses may get lost, so from that perspective you should be able to use also the SDP in the 200 OK (which, if the remote node behaves correctly, shall be the same as in the non reliable provisional response).
I agree here.
3. Is the following scenario possible :-
A B
| |
| INVITE (SDP OFFER) |
|--------------------->|
| |
| |
| 183 (SPD ANSWER) |
|<---------------------|
| PRACK (NO SDP ) |
|--------------------->|
| PRACK 200 OK(NO SDP) |
|<---------------------|
| |
| |
| |
| 183 (SDP OFFER) |
|<---------------------|
| PRACK ( SDP ANSWER) |
|--------------------->|
| PRACK 200 OK(NO SDP) |
|<---------------------|
| |
| |
| |
| 200 OK(NO SDP) |
|<---------------------|
| ACK (NO SDP ) |
|--------------------->|
| |
In the above diagram, I specifically wanted to know whether calle party (B) can send an OFFER SDP in the second reliable provisional response ?
I believe this is OK.
[CHH] My understanding is that only the first reliable provisoinal response may contain an offer, and only in the case that the initial INVITE didn't contain one (in which the answer is sent in the first PRACK).
I think that there can only be one offer/answer exchange per transaction, so once a SDP (offer or answer) has been sent in a provisional response no more can be sent for that transaction (INVITE). Or?
IF we were allowed to send more offers in provisional responses, how would we handle race conditions if the UAC at the same time sends a new offer (we can't send 491 to a provisional response)?
Well, RFC 3312 certainly calls for multiple offer/answer cycles per INVITE. (It isn't really one transaction, since it requires PRACK and the prack is a separate transaction.)
It is my understanding that once you take account of 3361, 3362, 3364 and 3311, offer/answer has been decoupled from specific messages. Within an invite dialog you may have a sequence of offer/answer exchanges. The main limitations are that each offer must be answered and that you can't send another offer until the prior one has been answered.
Offers and answers can travel in various messages: - invite - 200 ok of invite - ack - reliable provisionals to invite - prack of reliable provisionals - 200 ok of prack - update - 200 ok of update
There is pretty much complete discretion as to which of these messages are used to carry offers and answers as long as the offer/answer protocol is followed and the normal rules are followed for when those messages can be sent.
I think there is a solution to your problem with glare caused by two concurrent offers, one in a reliable provisional: If this happens, the conflicting offer must have been sent in an UPDATE, because that is the only message the other side would be able to send in that circumstance. In that case, the UPDATE should be failed with a 491 while the offer in the reliable provisional should succeed.
Paul
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
