Subject: [Sipping] Comments on 3pcc

From: [email-masked]
Date: Wed, 15 May 2002 09:55:10 EDT

Comments on draft-ietf-sipping-3pcc-00:

Section 4 Call Flows

All of the flows ring A, wait for A to answer, and provide no audible signal 
to A while waiting for B to answer. I don't believe this is acceptable in a 
service provider network.

Section 5 Error Handling

It notes that the call to B might fail (e.g., B is busy) or there might not 
be common media (after A answers). This is not acceptable in a service 
provider network. No customer service center (example in Section 1) would 
accept this operation.  The only acceptable signaling procedure would be one 
that can check these things first before ringing A.  The description in 9.1, 
in which the customer service representative is rung and answers first would 
not be acceptable either if the call could then fail or be delayed for a 
simple reason. A normal customer service center would require that the call 
setup to the customer be completed before their service representative is 
rung.

Section 6 Continued Processing

It seems to me that in basic SIP, part of the reasons for B sending the 200 
OK after getting a BYE from A is to confirm to A that B has stopped sending 
media. That is, A is now free to allocate its media path to other uses 
without fear of conflict. This is extremelly important if A is on an access 
that is limited in bandwidth. In this 3pcc example, that information is lost. 
When A gets the 200 OK in this example, B may still be sending media.

Mike Pierce
Artel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 May 2002 12:24:21 -0400

[email-masked] wrote:
> All of the flows ring A, wait for A to answer, and provide no audible
> signal to A while waiting for B to answer. I don't believe this is
> acceptable in a service provider network.

Ahh, my second least favorite technical argument - "this is not
acceptable in a service provider network.". My first least favorite
argument is "if you standardize this then we'll have proprietary
implementations that do it anyway". I didn't realize you spoke for the
entire service provider community.

Anyway, with that out of the way, of course an alerting tone can be
provided to A. It is documented in Figure 7. If party B provides any
kind of early media, whether its ringtone or announcements or whatever,
they will be heard by A. 

Now, the more complicated case is when B doesn't provide inband ringing.
If, instead, it generates a 180 without SDP, or provides a other
provisional response with an Alert-Info header. This is something that
doesn't exist in circuit switched networks, and is unique to VoIP. 
Today, the best you can do is have the controller connect user A to a
media server to play it an in-band ringing, which is far from desirable.
We need some kind of standards-based way for the controller to tell one
of the participants to generate some kind of media locally after it has
answered the call. We have no standards for that today. One can always
just invent some kind of header or something, but I think it is worth
considering the problem more broadly. Sounds like a requirements
document for enhanced 3pcc is in order...

> 
> Section 5 Error Handling
> 
> It notes that the call to B might fail (e.g., B is busy) or there might
> not be common media (after A answers). This is not acceptable in a

Ah, here we go again.

> No customer service center (example in Section
> 1) would accept this operation.  The only acceptable signaling procedure
> would be one that can check these things first before ringing A.  The
> description in 9.1, in which the customer service representative is rung
> and answers first would not be acceptable either if the call could then
> fail or be delayed for a simple reason. A normal customer service center
> would require that the call setup to the customer be completed before
> their service representative is rung.

Well, I've heard conflicting reports on whether its better to ring the
customer service rep or the user first. In any case, it is not for the
SIP group to decide. We need to provide primitives that allow either to
work.

Practically speaking, I think the basic 3pcc will work quite fine for
now; we seldom see failures because of media negotiation problems, and I
would assume that the customer service center has enough reps to ensure
a call is routed to one thats not busy (or a queue if they are all
busy). 

That said, I do think it is important to look at these limitations and
figure out how to properly address them. I think that, ideally, if you
are concerned about getting agreement on media before ringing phones,
you would use some kind of preconditions. Right now, the preconditions
work is really based on the assumption that the person who makes the
offer has done so in an INVITE. The case that comes up here is that the
thing that issues the INVITE (the controller) wants preconditions, but
it can't specify them since isn't offering SDP. I would argue that
presence of a Require: preconditions in an INVITE w/o SDP should be
interpreted to mean "I want preconditions, so don't ring the phone -
generate a 18x with an offer, and please include the preconditions types
you support as optional ones on each media stream, so I can decide what
to do". Thus, the flow would look like:

        User             Controller       Customer Service
          |                   |                   |
          |(1) INVITE no SDP  |                   |
          |require precon     |                   |
          |<------------------|                   |
          |                   |                   |
          |(2) 183 offer1     |                   |
          |optional precon    |                   |
          |------------------>|                   |
          |                   |                   |
          |                   |                   |
          |                   |(3) INVITE offer1  |
          |                   |------------------>|
          |                   |                   |
          |                   |                   |
          |                   |                   |ring
          |                   |                   |
          |                   |                   |
          |                   |(4) 200 OK answer1 |
          |                   |no precon          |
          |                   |<------------------|
          |                   |                   |
          |                   |                   |
          |                   |(5) ACK            |
          |                   |------------------>|
          |                   |                   |
          |                   |                   |
          |(6) PRACK answer1  |                   |
          |<------------------|                   |
          |                   |                   |
          |                   |                   |
          |ring               |                   |
          |                   |                   |
          |                   |                   |
          |                   |                   |
          |(7) 200 PRACK      |                   |
          |------------------>|                   |
          |                   |                   |
          |                   |                   |
          |(8) 200 INVITE     |                   |
          |------------------>|                   |
          |                   |                   |
          |                   |                   |
          |(9) ACK            |                   |
          |<------------------|                   |
          |                   |                   |
          |                   |                   |
          |                   |                   |
          |                   |                   |

So, basically, the controller invites the user with a Require:
preconditions, but no SDP. Based on the semantic above, A sends an offer
in a 18x, but doesn't ring. It lists in that offer all preconditions it
supports, marked as optional. This is passed to customer service in an
invite. Customer service has no preconditions, so it rings, and
presumably right away generates a 200 OK with an answer. This is passed
to the user in a PRACK. Now, since A sees that there are no current
preconditions, it can ring. It does so, and the call is eventually
answered, generating a 200 OK.

Now, if there was no agreeable media or codecs, customer service would
have rejected the invite outright, and never have rung. Then, the
controller would CANCEL with a Reason header (?) and that would
terminate the call at the user, who would have never rung. Thus, we meet
your desired property of never ringing. This flow also has the property
that it works for multimedia too, since it uses flow I in which the
controller need not assume a specific media type. It also allows the
customer service rep to actually insist on preconditions if they want
(like QoS). This flow is possible with everything we have today, except
that it relies on a manyfolks semantic for a case which is currently
undefined in the spec (i.e., no behavior is specified). I'd love to be
able to add the couple of sentences to specify this behavior, but I fear
it is too late. Maybe the chairs could provide some guidance here.

> It seems to me that in basic SIP, part of the reasons for B sending the
> 200 OK after getting a BYE from A is to confirm to A that B has stopped
> sending media. That is, A is now free to allocate its media path to
> other uses without fear of conflict. This is extremelly important if A
> is on an access that is limited in bandwidth. In this 3pcc example, that
> information is lost. When A gets the 200 OK in this example, B may still
> be sending media.

That can happen in regular first party calls too. The media and
signaling are not syncrhonized. Consider a two party call between A and
B. A sends a BYE to B. Even though B has stopped sending media and sent
a 200 OK to the BYE, the 200 OK may arrive before the last bit of media
arrives. In that case, it is just discarded by A. I see this as no
different.

-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