Subject: [Sip] final "unify" rules for bis

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 04 Feb 2002 03:27:33 -0500

Folks,

I worked through the various scenarios of offers and answers in bis, and
came up with a concrete statement of where they can, and cannot be. Here
is the result:

1. INVITE may contain an offer, or may be empty
2. If a UAS gets an INVITE with an offer, it MAY place the answer either
in a reliable provisional, or the final 2xx, but not both (of course).
It MUST NOT attempt to place an offer in any responses, provisional, or
final.
3. If a UAS gets an INVITE without an offer, it MUST place an offer in
either a single reliable provisional, or the final 2xx, but not both (of
course). "Single" implies that it can only make a single offer. 
4. If the UAC did not make an offer in the INVITE, the offer will come
in either a reliable 1xx or a 2xx. In that case, the UAC MUST generate
an answer in the corresponding PRACK and ACK, respectively. After that,
the UAC MAY generate additional offers in PRACK (and the UAS places its
answer in the corresponding 2xx PRACK)
5. If the UAC did make an offer in the INVITE, and the answer came in a
reliable 1xx, the UAC MAY make subsequent offers in a PRACK (and the UAS
places its answer in the corresponding 2xx PRACK).
6. If a UAS has SDP, either an offer or answer, in a reliable
provisional response, it MUST NOT generate a final response until the
provisional has been acknowledged.
7. Extensions specify whether offers or answers can be used with them;
they must also discuss any interactions with these rules and show how
the meet the requirements of o/a.

Basically, the exchanges are pretty simple. Beyond the two we already
know (offer in INVITE, answer in 2xx, offer in 2xx, answer in ACK) Its
mostly three useful ones:

INV (offer)
1xx (answer)
PRACK
2xx-PRACK
2xx
ACK

or

INV 
1xx (offer)
PRACK (answer)
2xx-PRACK
2xx
ACK

or

INV (offer)
1xx (answer)
PRACK (offer)
2xx PRACK (answer)
2xx
ACK

You can have additional offers in PRACK, but this just isn't useful
since the UAC would need to wait for a provisonal to make the offer.

Why these restrictions? O/A requires a few simple properties. Besides
avoiding overlap, the main one is guaranteeing order. So, that made me
eliminate some cases:

1. you cant make offers in any 1xx except the first. Otherwise, that
offer could reach the UAC while the UAC had just sent an UPDATE or other
forward request with an offer. That would require the UAC to reject the
1xx, but it cant.

2. You can't make offers in any 2xx unless its the first offer. Same
reason as above, you can't reject it. 

My simple conclusion was thus you can't generally have offers in
resposnes, since they can't be rejected. The only case where it won't be
rejected is if its the first offer of the exchange. That works OK. From
this, the above rules basically are distilled.

With UPDATE, you get the ability to have offers in the reverse direction
from callee to caller. You also get asynchronous offers from caller to
callee. UPDATE is outside of bis, though. UPDATE will also need to say
that a callee cant send one if it has a reliable provisional response
outstanding (we discussed that on the list), but thats outside the scope
of bis as well.

I have placed these new rules, in more general form (so that UPDATE
could add stuff and not violate them) into bis-07.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 04 Feb 2002 12:51:51 +0200

Hi,

I think the rules are pretty clear. A couple of issues, though.

>answer in the corresponding 2xx PRACK)

This sounds like the UAC can generate PRACKs without receiving a
provisional response, and even after it has sent ACK, so I guess it
needs a little more detailed clarification.

>provisional has been acknowledged.

I am aware of the reason for this restriction (I brought up the reason
myself in another thread, so...), but I don't think it's the best way to
solve the issue (that a final response may reach the UAC before a
provisional response with an offer does).

If we can't send the 200 before we have received the PRACK, I see no
reason to alarm the called party before we have received the PRACK...

Regards,

Christer Holmberg
Ericsson Finland