Subject: [Sipping] update to 3pcc I-D

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 10 May 2002 03:58:16 -0400

Folks,

I've just submitted an update to the 3pcc I-D. Since its now a sipping
item, its been renamed draft-ietf-sipping-3pcc. Until it appears in the
I-D archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-00.txt

The changes are:

* addition of a new flow, flow 4. This is a variation on the previously
recommended flow. It uses SDP with no media lines (as opposed to no SDP)
to avoid the SDP hacking that flow 3 requires. This is now the
recommended flow. 

* general update for bis compliance

* example flow of 3pcc and early media, using UPDATE

* example flow of 3pcc and manyfolks

* reworded in places to reflect proposed bcp status

* discussion of the usage of the Reason header for handling call
failures

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 May 2002 14:29:20 -0400

> to avoid the SDP hacking that flow 3 requires. This is now the

I am wondering about how alerting is handled in this flow. Specifically, wonder whether a UA should alert upon receiving a media-less initial invitation. There are a number
of problems with alerting at this time:

- The proper manner of alerting may depend on the media to be used. (E.g. Generate ring tone vs pop a window.)

- The called user may not be able to decide whether to answer the call without knowing what media are to be used. (E.g. will accept audio but not video, or IM but not
audio)

- The call may eventually fail because the two ends have no media in common. In that case the alert was an annoyance. (This property is shared with an offer-less
invitation.)

- It may be impossible to alert without choosing a medium, and costly to do so if the call eventually fails due to lack of common media. (A PSTN gateway is an example of
this.)

Flow 4 doesn't really mention alerting, but I think it implicitly assumes that alerting will happen between messages (1) and (2), and not between (6) and (7). If the
alerting of A is delayed until after message (6) when media information is available, then this flow has the same timeout problem as Flow 1.

I think what is really needed is a way to determine whether there is going to be a match on the media between A and B before either side alerts. But I don't see a way to
achieve this with existing SIP features. So I think that flows 3 or 4 are best practice at the moment, regardless of their limitations.

For the future, tweaking SIP features could provide a better solution. For instance, assume:

EXTENSION-1) a media-less invite doesn't alert

Using that, the following flow would be possible. (Excuse me for not drawing a real flow - hopefully this is sufficient to get the point across):

- invite A with no media (assume no alert)
- invite B with no media (assume no alert)
- send OPTIONS to A within the dialog
- send OPTIONS to B within the dialog
- compute intersection of SDP from the two options
- sent UPDATE to A with offer containing the
  intersected SDP, with address set to blackhole
  (assume this alerts).
- wait for answer from A & ack.
- send UPDATE to B using  A's answer, with
  the address set to blackhole
  (assume this alerts.)
- wait for answer from B & ack.
- send UPDATE to A with no offer & await answer.
- send UPDATE to B with A's answer as the offer.
- wait for answer from B & ack.
- send B's answer in ack to A.

The above leaves a lot to be desired. The following would be better:

- invite A with no media (assume no alert)
- invite B with no media (assume no alert)
- send OPTIONS to A within the dialog
- send OPTIONS to B within the dialog, but include
  A's SDP as a pseudo-offer. Assume B responds with
  SDP like it would if it received such an offer.
- sent UPDATE to A with offer containing B's
  answer, with address set to blackhole
  (assume this alerts).
- wait for answer from A & ack.
- send UPDATE to B using  A's answer
  (assume this alerts.)
- wait for answer from B & ack.
- send UPDATE to A with no offer & await answer.
  (assume new requirement that offer-less update
   MUST return prior SDP.)
- send B's answer in ack to A.

It assumes:

EXTENSION-2) When OPTIONS contains an SDP body, it is treated like an offer and the SDP in the response then contains what the corresponding answer would be

EXTENSION-3) UPDATE with no offer is required to return the last SDP as its offer.

I realize I am on thin ice postulating changes like this, but without doing something 3pcc just doesn't work very well for multimedia calls.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 May 2002 16:13:57 -0400

Oops - my proposed flows new are totally wrong! 

For some reason I was thinking UPDATE took an ACK like INVITE does, though I know better.

Still, I stand by my concern about the limitations in the existing flows. I will go back to the drawing board on alternatives.

	Paul

---

From: "Cullen Jennings" <[email-masked]>
Date: Sun, 12 May 2002 10:27:41 -0700

I like it all except the examples.

I understand that Refer stuff is not a RFC yet but I think REFER is
generally a better way to do click to dial.

The Mid-Call announcement example is just a Mid-Call announcement example
and should not be confused with the various trust relationships that must be
described to explain a complete credit card based pre-paid calling example.
Though it may be a part of pre-paid, confusing it with pre-paid is
misleading. How about the same call flow but motivating it with an example
of a calendaring system whispering that you have an appointment in 5 minutes
while you are on the call with someone else. This might be the wrong call
flow for that, but if it is, then perhaps it is the wrong call flow for at
least some class of Mid-Call announcements.

Cullen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 May 2002 15:48:43 -0400

Paul Kyzivat wrote:
> I am wondering about how alerting is handled in this flow. Specifically,
> wonder whether a UA should alert upon receiving a media-less initial
> invitation. There are a number

To be honest, the entire point of the flow is that alerting occurs at
this time, rather than later. If it occurs later, the response to the
re-INVITE is delayed, and the same transaction timeout problem as in
flow I occurs.

> 
> - The proper manner of alerting may depend on the media to be used.
> (E.g. Generate ring tone vs pop a window.)

Media can always change during the call anyway. If the call started as
video, would you delay the ringing till audio is added? To me, the
ringing inquires whether or not the user wishes to communicate.

> 
> - The called user may not be able to decide whether to answer the call
> without knowing what media are to be used. (E.g. will accept audio but
> not video, or IM but not
> audio)

Again, these may change during the call in any case.

> 
> - The call may eventually fail because the two ends have no media in
> common. In that case the alert was an annoyance. (This property is
> shared with an offer-less
> invitation.)

Yes, that is a fundamental issue with third party call control. 

> 
> Flow 4 doesn't really mention alerting, but I think it implicitly
> assumes that alerting will happen between messages (1) and (2), and not
> between (6) and (7).

Correct.

> If the
> alerting of A is delayed until after message (6) when media information
> is available, then this flow has the same timeout problem as Flow 1.

Correct.

> 
> I think what is really needed is a way to determine whether there is
> going to be a match on the media between A and B before either side
> alerts. But I don't see a way to
> achieve this with existing SIP features. So I think that flows 3 or 4
> are best practice at the moment, regardless of their limitations.

Sounds like preconditions to me.

> Using that, the following flow would be possible. (Excuse me for not
> drawing a real flow - hopefully this is sufficient to get the point
> across):
> 
> The above leaves a lot to be desired. 

Yeah; one of the things I really don't like is that the controller does
all this SDP mucking. Thats what flow IV was trying to help alleviate.

The following would be better:
> EXTENSION-2) When OPTIONS contains an SDP body, it is treated like an
> offer and the SDP in the response then contains what the corresponding
> answer would be
> 
> I realize I am on thin ice postulating changes like this, but without
> doing something 3pcc just doesn't work very well for multimedia calls.

I agree that the current 3pcc mechanisms could do better with some
additional extensions. I have some ideas on those too; what I really
want is to finally completely decouple offer/answer from SIP messages,
so that offers and answers could appear across transactions. Once this
is done, I can actually send an INVITE w/o SDP, get an offer in the 2xx,
and send an ACK without SDP (thus stopping the spurious retransmits).
Then, UPDATE later on with the answer. 

So, the ideal flow to me is:

          A              Controller               B
          |(1) INVITE no SDP  |                   |
          |no alerting        |                   |
          |<------------------|                   |
          |(2) 183 offer1     |                   |
          |------------------>|                   |
          |(3) PRACK          |                   |
          |<------------------|                   |
          |(4) 200 PRACK      |                   |
          |------------------>|                   |
          |                   |(5) INVITE offer1  |
          |                   |------------------>|
          |                   |(6) 200 OK answer1 |
          |                   |<------------------|
          |                   |(7) ACK            |
          |                   |------------------>|
          |(8) UPDATE answer1 |                   |
          |alerting           |                   |
          |<------------------|                   |
          |(9) 200 UPDATE     |                   |
          |------------------>|                   |
          |(10) 200 INVITE    |                   |
          |when answered      |                   |
          |------------------>|                   |
          |(11) ACK           |                   |
          |<------------------|                   |
          |(12) RTP           |                   |
          |-------------------------------------->|

This doesn't require the controller to so much as peep at the SDP, and
it has no timeout issues, and it won't cause alerting until agreed upon
media is present. I'm not sure how the preconditions stuff would work to
prevent alerting until a media stream is set up, but I am sure it could
be worked out.

However, for now, we are specifying the best current practice for doing
3pcc in SIP. That means we document what can be done, and also document
its limtations. Thus, I will incorporate your specific issues and
assumptions that you describe above.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 May 2002 15:52:17 -0400

Thanks for your comments. Responses inline.

> generally a better way to do click to dial.

The 3pcc spec is not the place to engage in the long debate about 3pcc
vs. distributed call control. There are issues like billing and control
which will dictate which approach is best. The point of the draft is to
illustrate how to do 3pcc.

> described to explain a complete credit card based pre-paid calling

I don't see this as overly complicated, certainly not complicated enough
to affect the call flows. There is a trust relationship between the
application server and the media server playing the announcement; these
are secured with tls or ipsec, I would imagine. Can you elaborate on the
specific problem?

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 May 2002 16:00:37 -0400

Here is my proposed text to be added to the description of flow 4, which
documents the limitations that Paul has pointed out:

There are some limitations associated with this flow. First, user A
will be alerted without any media having been established yet. This
means that user A will not be able to reject or accept the call based
on its media composition. Secondly, both A and B will end up answering
the call (i.e., generating a 200 OK) before it is known whether their
is compatible media. If there is no media in common, the call can be
terminated later with a BYE. However, the users will have already been
alerted, resulting in user annoyance and possibly resulting in billing
events. 

Comments?

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 May 2002 19:01:37 -0400

Jonathan,

This sounds good. 

There may be one more related issue. I don't know if it should be mentioned here or simply left to be dealt with elsewhere - it is a bigger issue that this. The issue is
what the behavior should be for a SIP-PSTN gateway when it receives an invite with a media-less offer. I can think of three possibilities:

1) send a 5xx error response to the invite

2) forward the call out to the PSTN. If it succeeds,
   return a 200 OK with no media. Effectively put
   the media stream on hold. Wait for a reinvite
   with media.

3) Don't pass the call to the PSTN. Just respond with
   200 OK. When you get a reinvite that wants to use
   voice, then make the call to the PSTN. Of course,
   it then may take a long time, and it may fail.
   If a reinvite failed, then the call would revert
   to no-media until somebody sends a BYE.

Of these, (1) is a bad choice. (2) may not give a very good experience to the called party - may initially hear silence, and some audio may be dropped even if the reinvite
comes right away. (3) violates the assumptions of call flow IV.

(2) seems like the only choice that makes any sense for this call flow. But it results in added limitations.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 May 2002 19:31:25 -0400

> re-INVITE is delayed, and the same transaction timeout problem as in

Yeah, I figured as much, but thought it was worth mentioning.
In an earlier reply on this thread I brought up the problem of how this should be handled by a gateway device that can't separate media from signalling. It was
consideration of that that first made me question when alerting should happen.

> ringing inquires whether or not the user wishes to communicate.

Alerting is used to inquire whether the user wishes to communicate or not. But there may be different sorts of alerting appropriate to different media or combinations of
media. 

The issue of media changing during a call is a very tricky one. Ideally every media change shouldn't result in fresh alerting. Yet is it valid to assume that if I answered
a voice call I am willing to have video added, without receiving some new indication of this? 

(What if I am sitting in front of my pc in my underwear, and my pc has a camera?)

Managing a multimedia UA is just plain more complex than a monomedia UA. I don't think all the important use cases wrt alerting have been explored.

Maybe we have to say that it is up to the user to configure supported media for the UA at the time of answering the call, so that the UA is capable of handling all
subsequent reinvites without added alerting. 

> Again, these may change during the call in any case.

Once I answer, I can presumably prevent them from changing. I suppose we could assume that I must decide upon answering what media I am willing to use without knowing if
that will be acceptable to the caller.

As Sanjoy said, possibly this can be handled by having a distinct alert indicating no-media.

> Sounds like preconditions to me.

I think so too, but haven't figured out how to make it work.

> So, the ideal flow to me is:

If this can be worked out then it would be a great improvement.

> assumptions that you describe above.

Can't ask for more than that.

	Thanks,
	Paul