Subject: RE: [SIP] 3PCC and the re-invite response

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 1 Dec 2000 15:11:17 -0500

> -----Original Message-----
> From: Gethin Liddell [mailto:[email-masked]]
> Sent: Friday, December 01, 2000 9:58 AM
> To: Brett Tate
> Cc: Sip Mail List
> Subject: Re: [SIP] 3PCC and the re-invite response
> 
> 
> On Fri, 01 Dec 2000, Brett Tate wrote:
> > > I actually think that the best solution for 3PCC is an 
> amalgamation of
> > > the late ACK and re-invite proposals:
> > >
> > >  A                Controller            B
> > >  |  INV  held SDP    |                  | time t = 0
> > >  |<------------------|                  |
> > >  |                   |                  |
> > >  |  200 SDP A1       |                  |
> > >  |-----------------> |                  |
> > >  |                   |                  |
> > >  |       ACK         |                  |
> > >  |<------------------|                  |
> > >  |                   |                  |
> > >  |                   |  INV NO SDP      |
> > >  |                   |----------------->|  (1)
> > >  |                   |                  |
> > >  |                   |  200 SDP B       |
> > >  |                   |<-----------------|
> > >  |      INV SDP B    |                  |
> > >  |<------------------|                  |
> > >  |                   |                  |
> > >  |  200 SDP A2       |                  |
> > >  |-----------------> |                  |
> > >  |                   |                  |
> > >  |                   |  ACK  SDP A2     |
> > >  |  ACK              |----------------->|
> > >  |<------------------|                  |
> > >  |                   |                  |
> > >  |                   |       RTP        |
> > >  |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
> > >  |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
> > >  |                   |                  |
> > >  |                   |                  |
> > >  |                   |                  |
> > >  |                   |                  |
> > >  |                   |                  |
> > >  |                   |                  |
> > >  |                   |                  |
> > >  |                   |                  |
> > >
> > > my only query is who do we late ack at (1), agent A or agent B.
> > 
> > It would be best to send it first to the party that the 3pcc
> > is controlling since it should definitely support it, and it
> > is the one trying to pull the other party off of hold.  In the
> > above scenario, I am assuming that B put party A on
> > hold (the picture isn't complete).  Thus the INVITE
> > without SDP should be sent to B first.
> 
> the picture is actually the call flow that will occur at the 
> initiation
> of a 3PCC session.  so `b' has not put `a' on hold, the contoller has
> put `a' on hold whilst it tries to contact b'.  once it has contacted
> `b', it is able to quickly bring `a' into the RTP session 
> because there
> is no user intervention.

Right. This actually seems like a reasonable compromise. There can still be
delays if the re-INVITE triggers some kind of UI interaction to approve it,
but that is less likely, and in any case, the user is already there, so the
response should come quickly.

> 
> if we were to initiate the late ACK scenario to 'a' at (1) then as
> Gonzalo pointed out, `a' may be waiting around a long time for an ACK
> to appear because we would have to wait for the user to answer the
> phone.

This bit I just don't follow. Point (1) in the call flow above is not an 
ACK, but an INVITE to B while A is on hold; there is no late ACK here at
all.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Vladislav Zubarev <[email-masked]>
Date: Thu, 30 Nov 2000 14:55:36 -0800

Completely agree with this point. I think it's dangerous to do it this way,
since
SDP (at least according to existing standard) could easily be changed in
200 OK, which
would result in a crash of a controller or another set of re-INVITE, 200
OK, ACK !!!

Gethin Liddell wrote:

> people,
>
> i'm slightly concerened (maybe un-justifably) about the re-invite
> working of the 3PCC draft.
>
> my concern is that it is possible (is it not?) for the user agent
> receiving the re-invite to change its SDP settings in its response as
> follows:
>
>  A                Controller            B
>  |  INV held SDP     |                  |
>  |<------------------|                  |
>  |                   |                  |
>  |  200 SDP A1       |                  |
>  |-----------------> |  INV SDP A1      |
>  |<----------------- |                  |
>  |                   |  200 SDP B1      |
>  |                   |  ACK             |
>  |  INV SDP B1       |----------------->|
>  |<------------------|                  |
>  |  200 OK SDP A2    |                  |
>  |------------------>|                  |
>  |  ACK              |                  |
>  |<------------------|                  |
>  |                                      |
>  |               BROKEN RTP             |
>  |                                      |
>  |                                      |
>  |                                      |
>
> NOTE: A has returned different SDP in its two different 200 OK messages.
>
> Why might it do this?  It might not but it is possible is it not.
>
> perhaps we should mandate that an agent can only change its SDP for a
> session in an INVITE not in a response (after the initial
> INVITE/RESPONSE exchange of course)
>
> what do we think?
>
> --
> Gethin Liddell
> Ubiquity Software Corporation
>
> http://www.ubiquity.net
> mailto:[email-masked]
>

--
Vladislav Zubarev        mailto:[email-masked]
Software Engineer        http://www.cisco.com
Cisco Systems, Inc.      http://www.vovida.org

---

From: "Gethin Liddell" <[email-masked]>
Date: Sun, 03 Dec 2000 17:46:34 -0000

> > > >  |  ACK              |----------------->| (2)
> > > >  |<------------------|                  |
> > > >  |                   |                  |
> > > >  |                   |       RTP        |

sorry, i meant the late ack that is sent later for the invite.  i have 
re-labelled the ack i was refering to as (2)and i'm refering to the scenario 
where all the arrows from point (1) are in the opposite direction (clear as 
mud?)
_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 5 Dec 2000 13:11:47 -0500

> From: Brett Tate [mailto:[email-masked]]
> Sent: Saturday, December 02, 2000 7:51 PM
> To: Sip Mail List
> > > Another reason is because
> > > many current UA's respond to hold SDP with
> > > hold SDP.  Thus both sides would be passing
> > > hold SDP with 0.0.0.0 as connection addresses,
> > > and the call would not get established.
> >
> > If that's the case, scenario in Figure 1 of the 3pcc draft 
> will not work
> no
> > matter how much we try to fix it. In particular, that would 
> mean that
> > http://lists.bell-labs.com/pipermail/sip/2000q4/004391.html 
> won't work as
> > well, since both A and B would keep returning "on hold" SDP 
> to the 3pcc
> > forever. Hence, automatically putting other party on hold 
> just because you
> > were put on hold sounds like very wrong behavior. Just as you say in
> another
> > email, some phones return on hold media even for INVITEs 
> with no SDP,
> which
> > plainly cannot be fixed. So isn't it better to fix the UAs 
> instead of
> > creating workarounds that don't always work anyway?
> 
> Gethin's flow works for 3pcc call setup.  However
> a no-call REFER (if still valid) or hold-then-transfer
> A to B through controller also works and allows
> A to hear/see the call progress/fail.

Brett, you have made this comment in several emails so far (in fact, several
through what appears to be copy-paste). I cannot follow what you are
proposing here. Can you please send a call flow?

Brett wrote previously:
>Another reason is because
>many current UA's respond to hold SDP with
>hold SDP.  Thus both sides would be passing
>hold SDP with 0.0.0.0 as connection addresses,
>and the call would not get established.

This is bad.

The whole reason we made "hold" be equal to 0.0.0.0 connection address was
that the service was done as a side effect; no special processing is needed.
The INVITE+hold stuff will all work if UAs do not treat a connection address
of 0.0.0.0 differently from anything else; SDP processing should proceed
normally. The only difference is that you can't send to 0.0.0.0, so even if
you tried, no packets are sent and call hold is thusly accomplished.
Standardizing on using 0.0.0.0 (instead of allowing any other non-routable
address) has the benefit that UIs that wish to indicate call hold can do so.

However, it seems that the benefit of this has been lost on implementors,
now resulting in a problem with some of the call flows.

I will add some text to bis explaining this issue.

I think this thread, and several others, all relate to one central problem:
we need a general way of describing SDP processing in UAs; how to determine
what the "current" set of SDP is, and how one creates a response to an
offered SDP. With a general algorithm in place for that, these problems
would go away.

> Thanks for the response.  Maybe one of the
> 3pcc authors can organize a bof at the
> IETF meeting if there is enough interest
> in this stuff.

I hope to cover some of these issues at the meeting. 

Although 3pcc is not a chartered item, I believe there is sufficient
interest (and already implementations) for us to move it forward as an
informational item.

-Jonathan R.
---