Subject: Re: [Sipping] Comments on 3pcc

From: [email-masked]
Date: Thu, 16 May 2002 15:01:15 EDT

In a message dated 5/16/02 12:24:36 PM Eastern Daylight Time, 
[email-masked] writes:

> [email-masked] wrote:
> > 
> > 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.
> 
> 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
> 

Sorry, I didn't mean to imply that I spoke for the entire service provider 
community. But if you don't start listening to individuals who each speak for 
a little part of it, and those who have had experience with 
defining/providing these same features for the service providers in the past, 
you will have no chance whatsoever to get them to use what you are 
standardizing. I'm trying to help you, but you don't seem to want it.

> 
> 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,
> 

Yes, I guess Figure 7 (in Section 7) shows a case of "early media" so that 
the ringing tone comes from B prior to answer. But I was referring to the 
figures in Section 4. Anyway, I do not see any way in Figure 7 that A can 
hear anything immediately after they answer their phone. It requires a number 
of additional message exchanges before the media is there. Is the the line 
labeled "(10) RTP" intended to show where the media can flow from B to A? If 
so, it should be labeled as "one-way media". I am having trouble finding 
specific statements about when media flow begins in SIP or in other drafts 
showing call flows. If this procedure (in Figure 7) is needed to provide the 
required audible indication to A, then why are the flows in Section 4 
included?

Can you also enhance Figure 7 to show where A and B actually answer the call. 
This would help some of us who are not familar with the intracacies of the 
protocol to understand the call flow. I've figured that it is when A send the 
200 answer1 and when B sends the 200 OK, but that would not be obvious to 
others.

> 
> 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
> 

Not sure what your point is. It was an early idea in ISDN that the audible 
inband ringing could be generated on the side. I don't think many do it that 
way, though, because of the speech clipping that results.

> 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
> 

It's a fundamental issue for basic telephony to be able to insert various 
tones into a call, whether during set-up, during the active phase of the 
call, or during release. This brings up the possibility of the entire set of 
capabilities that have been documented in several "packages" for H.248 (where 
a gateway could be expected to be able to do this tone injection). I can't 
image the user's end device being able to support the wide range of 
requirements for various current or future services. And it's not simply an 
issue for 3pcc. The 2-party situation would require the same thing (e.g., 
asking that a specific tone be applied to the other user for a specific 
service). I don't see a clear way to do this.

> 
> 
> > 
> > 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.
> 
> 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
> 

True, the procedures/standards need to allow both, since some service centers 
may what to give their customers really good service by having the 
representative on the line before the customer is rung, or they may wish to 
maximize their staff usage by having the customer on the line before they 
bother their representative. I suspect most would choose the latter. But my 
point is that, in either case, they would not accept bothering either the 
customer or their representative unless there was a sufficient chance that 
the call would work. Certainly, the only good approach is one that verifies 
that there is common media and both are not busy before ringing either one. 
Then both could be rung at the same time (with appropriate audible 
indications to the first to answer to wait for the other).

> <snip>
> > 
> > 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.
> 
> 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
> 

I think there's a big difference. In a normal 2-party call, when B stops 
sending media and sends the 200 OK (at virtually the same time), it must be 
next to impossible for the 200 to get to A before the final media packet does 
(especially if DiffServ EF and AF classes are being used). If anything, the 
media might continue for a very short period, and stop well before A could 
try to establish any other media. My comment was on the description in 
Section 6. There could be a significant time after A receives the 200 OK 
before it stops receiving media, since the media sending is under control of 
the other end. Perhaps the 200 OK to A should only be sent after the 
controller gets the 200 OK back from B. 

> -Jonathan R.

Mike Pierce

---

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

[email-masked] wrote:
> 
> Yes, I guess Figure 7 (in Section 7) shows a case of "early media" so
> that the ringing tone comes from B prior to answer. But I was referring
> to the figures in Section 4. 

These flows do not make use of any early media.

> Anyway, I do not see any way in Figure 7
> that A can hear anything immediately after they answer their phone. It
> requires a number of additional message exchanges before the media is
> there. 

Correct. Even in the first person case there is latency between when the
person picks up the phone and they can hear something.

> Is the the line labeled "(10) RTP" intended to show where the
> media can flow from B to A?

Not the earliest time; it can send media after receiving message 8.

> If so, it should be labeled as "one-way
> media". I am having trouble finding specific statements about when media
> flow begins in SIP or in other drafts showing call flows.

The offer/answer draft defines that explicitly. 

> If this
> procedure (in Figure 7) is needed to provide the required audible
> indication to A, then why are the flows in Section 4 included?

The flow in figure 7 assumes that party B is offering early media. Not
all calls make use of early media. Nothing in the sip spec requires or
even encourages it. The flows in section 4 do not use it.

> 
> Can you also enhance Figure 7 to show where A and B actually answer the
> call. This would help some of us who are not familar with the
> intracacies of the protocol to understand the call flow. I've figured
> that it is when A send the 200 answer1 and when B sends the 200 OK, but
> that would not be obvious to others.

OK. 

> > document for enhanced 3pcc is in order...
> 
> It's a fundamental issue for basic telephony to be able to insert
> various tones into a call, whether during set-up, during the active
> phase of the call, or during release. This brings up the possibility of
> the entire set of capabilities that have been documented in several
> "packages" for H.248 (where a gateway could be expected to be able to do
> this tone injection). I can't image the user's end device being able to
> support the wide range of requirements for various current or future
> services. And it's not simply an issue for 3pcc. The 2-party situation
> would require the same thing (e.g., asking that a specific tone be
> applied to the other user for a specific service). I don't see a clear
> way to do this.

If you don't want the local device to generate the tones, then we have
solutions for this; the user can be connected to a media server to play
whatever "tones" you want.

> work.
> True, the procedures/standards need to allow both, since some service
> centers may what to give their customers really good service by having
> the representative on the line before the customer is rung, or they may
> wish to maximize their staff usage by having the customer on the line
> before they bother their representative. I suspect most would choose the
> latter. But my point is that, in either case, they would not accept
> bothering either the customer or their representative unless there was a
> sufficient chance that the call would work. Certainly, the only good
> approach is one that verifies that there is common media and both are
> not busy before ringing either one. Then both could be rung at the same
> time (with appropriate audible indications to the first to answer to
> wait for the other).

Well, I am going to include the appropriate flow for doing this (which I
described in my previous mail) into the 3pcc spec.

> different.
> sending media and sends the 200 OK (at virtually the same time), it must
> be next to impossible for the 200 to get to A before the final media
> packet does (especially if DiffServ EF and AF classes are being used).
> If anything, the media might continue for a very short period, and stop
> well before A could try to establish any other media. My comment was on
> the description in Section 6. There could be a significant time after A
> receives the 200 OK before it stops receiving media, since the media
> sending is under control of the other end.

Its one of these 0 or infinity cases. Since you need to be prepared for
some non-zero amount of media after getting the 200 OK to the BYE, there
is no difference between 5ms worth and 5 minutes worth as far as the
client processing is concerned.

> Perhaps the 200 OK to A
> should only be sent after the controller gets the 200 OK back from B.

You generally want to generate a response to a non-INVITE as soon as
possible. 

-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