Subject: RE: [Sipping] new draft-ietf-sipping-isup-05

From: William Marshall <[email-masked]>
Date: Thu, 15 Aug 2002 09:07:43 -0400 (EDT)

Summary of this thread so far:

There seems to be general agreement that there is a problem with
preempting/generating local ringback in the current isup-05 draft, and 
that the alternative of clipping the media after answer is worse.
There seems to be general agreement that this is a direct result
of offer/answer when combined with PRACK and manyfolks, and the 
interpretation of "a=sendrecv" as it pertains to alerting.

The sheer number of messages in this thread clearly indicates that
the current draft did not resolve the comments on the subject
during the last-call process.

Aside from a statement of several to just "get this draft out", there
are three solutions proposed:
  0)  do nothing and ignore the problem
  1)  use a 183 instead of 180 if in-band ringback will be sent
  2)  include a flag in the 180 if in-band ringback will be sent

And some comments appearing on the list relating to these three
solutions (apologies in advance if I missed or mis-stated any positions):

Bill Marshall wrote:
> A "solution" that results in clipping the initial conversation is so
> fundamentally broken that it doesn't deserve consideration at all.
[and note that my original solution was choice #2]

Brian Rosen wrote:
> I like the explicit Alert-Info much better than inferring it from
> 183 vs 180 or other indirect mechanisms.

Christer Holmberg wrote:
> 			My concerns are the idea of
> 200/UPDATE, and also (which has been discussed before) the MUST of
> buffering 200 before a PRACK has been received, and those things I DO
> think shall be solved on a protocol level.
and
> So, whatever solution we'll go for (if we'll go for any solution at all...) 
> I think it's important that we define it so it really only affects gateways 
> (and, of course, other nodes which may want to send early media ... )

Jon Peterson wrote:
> I am willing to put something that is roughly option
> (1) in sipping-isup-06. It will appear in a few days.

Gonzalo wrote:
> I have a big problem with (1). 
[remainder of Gonzalo's arguments appear to be in favor of choice #0]

Al Varney wrote:
>     Everyone:  We all want to finish this document.  While I had some 
> unease regarding the text in Draft-03 and -04, it is only with Draft-05 
> that the early media text made ISUP interworking problematic 
...
>     In other words, in my opinion, Draft-04 worked with the PSTN, and 
> Draft-05 doesn't.

Anjan Bose wrote:
> I agree that the more explicit the notification is, the better. Having 
> 	Alert-Info: <data:audio/basic;base64,AAAAAA>
> as an indicator, is better than none, but how about having the
> following as an indicator that the terminating subscriber's line is ringing
> and that in-band ringback is going to be sent:
> 	Alert-Info: <data:audio/basic;in-band-ringback>

John Elwell wrote:
> At present the QSIG draft maps a QSIG ALERTING to a SIP 180 response and
> vice versa. I would not be happy with solution 1), ...

_______________________________________________
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: Al Varney <[email-masked]>
Date: Thu, 15 Aug 2002 12:45:23 -0500

At 09:07 AM 8/15/02 -0400, William Marshall wrote:
>solutions (apologies in advance if I missed or mis-stated any positions)

    My biggest concern, perhaps orthogonal to the above issue, is that 
Draft-05 introduced "new media" text that would IGNORE in-band ringback in 
preference for local ringback (whether 183 or 180), in situations where it 
is not possible to KNOW that the in-band audio is ringback vs. some other 
tone/announcement.

    For a SIP-ISUP gateway receiving a SIP INVITE, sending 180 or 183 with 
"a=sendrecv" doesn't have to imply a risk of two-way communication before 
answer.  AT THE GATEWAY, forward audio can be blocked until answer is 
received (or one of the other events that can trigger two-way communication 
before answer).  That's how ISDN and other PSTN access interfaces work 
today.  (See Q.767, D.2.1.7.3 for an ISUP example.)

    The same one-way communication restriction is also enforced at the 
terminating exchange -- normally, the exchange itself is providing ringback 
or other tones/announcements, and there is no interconnection to the 
callee.  In the less common situation where a terminating user (PBX, ISDN) 
provides the audio ringback or other tone/announcement, the connection is 
usually one-way-only in the backwards direction.

    The PSTN model for speech calls is that a backward audio path is set up 
at least by the time ACM is sent, and it is used for 
ringback/tones/announcements and cannot therefore clip at answer time 
(except for the time required to recognize off-hook at the terminating 
exchange and provide a two-way connection (and disable the ringback or 
other tone/announcement).  Q.543 recommends exchanges accomplish this in 
less than 250 ms.  This is consistent with other recommendations that the 
called party be able to deliver audio to the calling party within 1/4 
second after answer.  I recall prior experience with some (business) 
callers offering a brief "Yes" or "Hello" within the first 300-500 ms, and 
then silence.  They dislike repeating themselves.

    Clipping in the forward direction is also a concern, because answer 
must be received and a forward audio path established before the caller can 
respond to the answering party.  (Q.77 and Q.109 may be relevant to this 
issue.)

    Rather than blocking media flow using SIP/SDP messages, it would seem 
simpler to have this administered at the ISUP/IP interconnection circuit 
controlled by the gateway.  Would this allow the desired flexibility for 
180 vs. 183, and still deliver in-band (rather than local) 
ringback/tone/announcements with early media?  And would it avoid a SIP 
change to solve what is really a PSTN deficiency?

Al Varney

---

From: Michael Hammer <[email-masked]>
Date: Thu, 15 Aug 2002 15:25:28 -0400

Bill,

Although I agreed to some of your assessment of the problem, I am not in 
total agreement with your solution.  I think you need to keep the 180 as a 
key links in the conduit of the propagation end-to-end of the indication 
that alerting is occuring.

Could you also work in the idea that:
1) the assumption is that alerting is in-band unless call signaled 
otherwise; coupled with the independent Offer/Anser activation of the 
appropriate backwards in-band path by the called application.
2) The injection of in-band alerting at a mid-point (i.e. a GW) occurs only 
if an explicit indication commands it to do so.

Whether the 180 is assumed to do injection always and a flag is needed to 
toggle that off, or the 180 is assumed to not do injection and a flag is 
needed to toggle that on, can perhaps answer 2) above.

The comment in RFC-3261 21.1.2 180 Ringing that:  "This response MAY be 
used to initiate local ringback." needs to be more definitive in at least 
the SIP-ISUP Mapping draft for the SIP to ISUP GW.

Mike