Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks

From: Christer Holmberg <[email-masked]>
Date: Fri, 01 Feb 2002 08:53:21 +0200

Hi,

I have a small question of the use of PRACK for the offer purpose.

Assume that UA1 calls UA2.

UA1                    UA2
==========================

-----INVITE (offer 1)-->

<----183 (answer 1)-----

-----PRACK (offer 2)--->

Now, when UA2 receives the PRACK it will probably alarm the user, ie the
UA2 phone will start ringing.

Then, if (for whatever reason) the 200 to PRACK does not reach UA1, and
UA2 answers, is UA2 allowed to send the 200 to INVITE before the 200 to
PRACK has reached UA1? This is how it most likely would work in "normal"
PRACK scenarios, so...

(If UPDATE is used, UA1 would not send UPDATE before it has received 200
to PRACK, so when UA2 receives the UPDATE and alarms the user the PRACK
transaction would be finished.)

Regards,

Christer Holmberg
Ericsson Finland

Jonathan Rosenberg wrote:
> 
> Rohan Mahy wrote:
> >
> 
> > >We need to discuss that further. Unify indicated that the
> > preference was
> > >not to allow it in PRACK. I sent a note to the list already
> > describing
> > >the reason. The reason is that you may need to reject an
> > offer if it
> > >occurs in the middle of an outstanding offer (i.e., glare
> > prevention).
> > >This means that if A sends a COMET to B with an offer, and B
> > sends a
> > >PRACK to a previous 1xx with an offer to A, A will need to
> > reject the
> > >PRACK for glare prevention.
> >
> > Would it help to add an additional restriction:  Don't send a
> > new offer if you are still waiting for acknowledgement of a
> > message you sent in the same dialog.
> 
> It would help, yes. Its broader than you need. I am trying to think if
> there would be an negative impacts from this restriction. None I can
> think of off hand, though.
> 
> >
> > A would be forbidden to send an offer in a COMET (or a 200
> > for the original INVITE) until its provisionals where
> > acknowledged.
> 
> As a specific instance of your rule, yes. We could also make it simpler,
> which is that you can't send an offer in UPDATE (I think we have
> consensus to call it UPDATE) if you have a reliable provisional response
> outstanding.
> 
> >
> > I think sending offers/answers in PRACK is even more useful
> > in the 3pcc early media case.
> >
> > basically I prefer this:
> >
> > INVITE (no SDP) -->
> > <-- 18x (offer1)
> > PRACK (answer1) -->
> > <-- 200 (PRACK)
> > <-- 200 (INVITE)
> > ACK -->
> >
> > to this:
> >
> > INVITE (no SDP) -->
> > <-- 18x (offer1)
> > PRACK -->
> > <-- 200 (PRACK)
> > COMET (answer1) -->
> > <-- 200 (COMET)
> > <-- 200 (INVITE)
> > ACK -->
> >
> > (which is technically forbidden by rule 4 above)
> 
> Right, the benefit is the savings of a transaction.
> 
> OK, I'll bite. I think the 3g guys would prefer this as well, since I
> suspect the case of 1-of-N codecs + manyfolks will be a common one.
> There, without sending SDP in PRACK, you'd need to to this:
> 
> INVITE (SDP offer w/ many codecs + inactive + precon) ------>
> <----- 183 (SDP answer w/ one codec + inactive + precon)-----
> PRACK------>
> <----200 PRACK
> COMET (SDP offer w/ one codec + sendrecv + precon) ----------->
> <-------200 COMET (SDP answer w/ one codec + sendrecv + precon)
> <-----resource reservation-------->
> COMET (SDP offer w/ one codec + sendercv + conditions met)------->
> <-------------200 COMET (SDP answer w/ one codec + sendrecv + conditions
> met)
> <---------180-------------------------------------------------
> PRACK--------------------->
> <-------------200 PRACK----
> <-----------200
> -----ACK>
> 
> This is an extra pair of messages (an extra COMET) that is not currently
> in the flows in 24.228 which would need to be added. Whilst it *doesn't*
> increase call setup latency, it uses more bw on the air interface. Yeah,
> compression will help some, but I bet theyd prefer to avoid another
> transaction to an already overly complex setup flow. Of course, I think
> its even easier to avoid preconditions altogether, but let us not
> discuss that.
> 
> So, let me ask for consensus on allowing the o/a exchanges in PRACK in
> addition to UPDATE, subject to some kind of constraint to avoid the
> problem I mention of glare on the PRACK.
> 
> 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

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Feb 2002 02:23:46 -0500

> Assume that UA1 calls UA2.

Huh? What does PRACK have to do with ringing? 

> PRACK has reached UA1?

Of course. UA2 doesn't know that its 200-PRACK hasn't reached UA1. 

From UA1's perspective, it has an offer outstanding in PRACK, and it
knows the answer will arrive in the 200-PRACK. If the 2xx to the INVITE
should arrive before the 200-PRACK, UA1 knows it has to be an offer. If
this had happened through re-INVITEs, that offer would be rejected
because of glare. However, we can't reject the 2xx to INVITE. In this
case, we can handwave that problem away, by stating that final responses
to the invite always come after any 200-PRACK. However, that doesn't
extend to provisional responses and UPDATE from UAS back to UAC. There,
we have Rohan's rule, which is that you can't send an UPDATE when you
have an unacknowledged 1xx outstanding.

Its a bit complicated, I admit; I need to think about a good way to
express the ordering and glare detection rules for these cases, but I
think it works...

> This is how it most likely would work in "normal"
> PRACK scenarios, so...
> 
> to PRACK,

why? I disagree with that. If we didn't allow SDP in PRACKs, we really,
really need to allow UPDATE and PRACK to go in parallel to avoid call
setup latencies.

-Jonathan R.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 01 Feb 2002 10:22:28 +0200

Hi,

My comments inline.

>Huh? What does PRACK have to do with ringing?

[CH] Nothing. It was just an assumption that the called party won't be
alarmed before some kind of negoatiation between the nodes is done
(compare to the resource reservation mechanism in manyfolks). But, ok,
we can assume that the INVITE triggers the ringing.

>Of course. UA2 doesn't know that its 200-PRACK hasn't reached UA1.

[CH] No, but if it keeps receving re-transmits of the PRACK it can
assume so.
 
>should arrive before the 200-PRACK, UA1 knows it has to be an offer.

[CH] What if UA1 receives the 200-INVITE before it even receives the
183-INVITE (this can happen if the INVITE triggers the ringing, and the
called party picks up the phone)? UA2 will probably stop re-transmitting
the 183-INVITE after 200-INVITE has been sent, so UA1 may never get
"answer 1". Even if UA1 DOES receive the 183-INVITE later it probably
won't care about it since it has already received the 200-INVITE. I
don't think we can assume that UA1 will keep waiting for the 183-INVITE
after it has received 200-INVITE.

Of course, if UA1 does receive the 200-INVITE (also including "answer
1") before it has received the 183-INVITE, it could ACK and then send a
re-INVITE (see picture) with "offer 2", but the problem then is that
both parties are trying to speak to each other while we're still
negoatiating the codec...

UA1                     UA2

------INVITE (offer 1)-->
      X<--183 (answer 1)-
<-----200 (answer 1)-----
------ACK--------------->
------INVITE (offer 2)-->
...

>If this had happened through re-INVITEs, that offer would be rejected

So, why don't we? PRACK is only used to ack the 183, but UA1 still won't
send the UPDATE before it has received the 183. So when UA2 receives the
UPDATE it KNOWS UA1 has received the 183 - even if the PRACK transaction
is still open...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 04 Feb 2002 01:58:34 -0500

Responses inline.

> "answer 1".

It cant do that. In this case, it needs to continue retransmitting that
reliable provisional response, and actually delay the 2xx, until it gets
a PRACK. Note that there is no media clipping or adverse user experience
as a result; its the same issue as sending a BYE only after getting ACK
for the 2xx; its just a protocol thing.

> Even if UA1 DOES receive the 183-INVITE later it probably

Thats right. Indeed, because proxies won't likely forward provisionals
after a final, you cannot assure delivery of reliable provisionals
through a SIP network once a final has been sent. Thats why you need to
delay the 2xx.

-Jonathan R.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 04 Feb 2002 10:14:18 +0200

Hi,

>for the 2xx; its just a protocol thing.

Well, the server would be able to send lots of free "early media"...
And, if the node is a gateway the PSTN network won't know anything about
it, since it assumes the connection is established. 

>through a SIP network once a final has been sent. Thats why you need to

This is an issue which was discussed a long time ago, in the "early
days" of PRACK, and the understanding then was that one should NOT have
to delay the 2xx, due to a number of reasons (I guess most of those were
related to PSTN GW issues).

And, how long would we delay the 2xx? Until the 18x time-out?

I think one easy way to go would be to handle the negoatiation first,
THEN alarm the user (like manyfolks handle the resource reservation
first, and then alarms the user).

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 04 Feb 2002 15:59:13 +0200

Hi,

>through a SIP network once a final has been sent. Thats why you need to

Another place where this won't work very good is in a forking scenario. 

For example, assume that I have two phones. Both start ringing, and I
answer one. However, if the 200 isn't sent, the other phone will keep on
ringing... And, the other phone may be a phone answering machine, so it
may send a final response a CANCEL will be sent to my phone...

No, I agree that in a real-life scenario, where the forking proxy may be
"close" to the servers, this won't happen, but in bigger scale networks
it may. We should remember that the PRACK may take a completely
different route than the INVITE/18x/200, due to a record-route.

Regards,

Christer Holmberg
Ericsson Finland