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

From: "Bose, Anjan" <[email-masked]>
Date: Wed, 14 Aug 2002 00:11:07 -0400

Al,
		There are cases when the call agent needs to know whether
the terminating subscriber's phone is ringing (automatic callback comes to
mind, but there are probably others, and I'm sure that there are other ways
of implementing these features also).  I think that it is better to retain
the notification that the terminating subscriber's phone is ringing in the
early stages of SIP-ISUP interworking and then if it is decided that the
notification becomes superfluous in SIP to deprecate the feature.  
		It's always easier to strip unnecessary messages after
implementation rather than trying to add messages once products get into the
field.

Anjan

-----Original Message-----
From: Al Varney [mailto:[email-masked]]
Sent: Tuesday, August 13, 2002 4:26 PM
To: William Marshall; [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] new draft-ietf-sipping-isup-05

At 04:35 PM 8/13/02 -0400, William Marshall wrote:
>Gonzalo,
>
> > Your local policy could look like this:
> >
> > 1) If there is media coming from a stream, play it (don't play local
> > ringback), regardless of the status of the callee (alerted or not).
> >
> > 2) If there is no media coming from any stream (they are all inactive or
> > sendonly or no SDP has been received) AND the user is being alerted (180
> > has been received) play local ringback.
> >
> > 3) If there is no media AND the user is not being alerted, do nothing.
> >
>
>The interesting case, of course, is the one you don't list.  If SDP has
>been received, and either explicitely says "a=sendrecv" or does not
>contain the "a=inactive" nor "a=recvonly", AND the user is being alerted
>(180 received).  Do you play local ringback or not?  Both choices are
wrong.

    That's why, in my opinion, a PSTN gateway (ISUP, MF or whatever) should 
never send 180 in the first place.  The PSTN will ALWAYS deliver in-band 
audible ring tone, and I don't see any advantage of ever triggering local 
ringback to a SIP UAS on such calls.  (I was not around for any earlier 
discussion on this topic, so I may be missing some fundamental concept
here.)

    The "early ACM" case (section 7.2.5) will work for all ISUP voice 
calls.  SIP callers would then experience exactly what ISDN or analog 
telephone callers experience -- call progress tones from the terminating 
end of the call and no clipping on answer.  Section 7.2.6 and the 
"alerting" state in the state machine in 7.2 could then be 
removed.  (Removing the "alerting" state from 7.2 doesn't constrain the 
behavior of a SIP UAS -- it only simplifies the ISUP gateway).

    ISDN terminals could do local ringback, but I've never observed it (for 
voice calls).  Unfortunately, the ACM indication "subscriber free" is not 
100% synonymous with an audible ring tone being sent in-band.  A subscriber 
line can be free but various conditions can result in a tone/announcement 
rather than ring tone.  The CPG with "alerting" (in 7.2.9) could be used to 
more reliably trigger ISDN local ringback, but since the audio path is 
already established, and the terminating end is always sending ring tone, 
and it only works for ISDN destinations, there is no advantage.  Instead, 
the CPG usually only results in updating an ISDN display.

      Unfortunately, even with this change, mapping of an ISUP CPG with 
"alerting" to a 180 (in 7.2.9) still presents a race condition that could 
trigger local ringback before media arrives.  Since this CPG isn't 
generated on calls to analog lines (and thus cannot be relied on for all 
calls), maybe the 180 indication isn't that useful?

Al Varney

_______________________________________________
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

_______________________________________________
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: Wed, 14 Aug 2002 21:56:48 -0500

Anjan:  Please see my response below.

    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 
(IMO).  Draft-05 was announced by IETF (and Jon) on Aug 7, 2 days after 
IESGLC.  Mark and I had comments on FCI/BCI text on the following day and 
that issue was essentially resolved (I think) in 3 days.  The comments on 
the NEW early media text (and 180 vs. 183) have been going on for less than 
a week.

    Respectfully, Jon, these were NOT TRIVIAL changes.  For example:

  Old 4.5 in Draft-04 (renumbered to 5.5 in Draft-05):
    "To allow the transmission of messages and tones before a final
    connection has been established, SIP nodes which interwork with the
    PSTN need to be able to establish temporary media connections during
    this period."

  New 5.5 Early Media:
    "In cases where interworking has not been encountered,
    use of early media is almost always undesirable since it consumes
    inter-machine trunk recourses to play media for which no revenue is
    collected."

    Equivalent changes in 7.2.5/7.2.6 now express a decided preference for 
NOT establishing early media on all calls, unlike the Draft-04 text, which 
at least leaned in the direction of providing early media.  The PSTN is an 
early-media system, and trying to make it into a media-after-answer system 
is an uphill crawl.

    In other words, in my opinion, Draft-04 worked with the PSTN, and 
Draft-05 doesn't.

>notification becomes superfluous in SIP to deprecate the feature.

    Anjan, I agree with your statements, but it's based on a faulty 
premise.  ISUP does NOT provide a positive indication that a terminating 
subscriber's phone is ringing.  SIP-ISUP gateways that don't provide early 
media on receipt of EVERY ACM risk clipping tones/announcements (or missing 
them entirely) when early media is not provided.  Callers will be listening 
to local ringback or no audio at all, while the PSTN is trying to explain 
why the call has not completed.

    Prior to Draft-05, the language of 7.2.5 and 7.2.6 both indicated (or 
at least suggested) that providing early media would avoid clipping and 
allow callers to hear PSTN call progress audio.  Changes introduced in 
Draft-05, probably under the umbrella of 'improved early media text', 
removes this suggestion.  The new text in 5.5 regarding "early media" also 
perpetuates the idea that early media can be avoided (indeed, is 
undesirable) in "non-interworking" cases.

    The ACM "subscriber free" status is a simplistic line status, not an 
assurance that the line is being alerted.  [Q.764 2.1.4(i)(1)(a) says to 
send ACM if subscriber is determined to be "free", not if the subscriber 
line is actually being rung.  There is a difference.]  Various situations 
and features can intervene and result in other tones/announcements AFTER 
the ACM has been returned.  Only by listening to the backward-direction 
audio can the caller determine how to proceed.

    Worse, the new Section 7.2.5 "early ACM" language doesn't mention the 
need for early media to carry this backward-direction audio, and eliminated 
the language that was in Draft-03 and Draft-04 regarding "interworking with 
some old systems".  Unfortunately, virtually all "interworking with old 
systems" situations generate what the draft calls "early ACM" -- an ACM 
with called party status="no indication" and a BCI with "interworking 
encountered".  (7.2.6, for some odd reason, discusses "interworking" under 
the "subscriber free" case.)

    The new text now implies the only case for "early ACM" (ACM with 
called-party status of "no indication") is to satisfy an ACM timer.  Text 
in Q.764 clearly shows that "interworking" with MF/DP and some PBX systems 
will also return such an ACM, and will never return a CPG to indicate 
ringing has started.  These "early ACM" cases (not wireless networks) MUST 
have early media, since ISUP is not available end-to-end to provide ANY 
call progress indications.

    But I've gone on long enough about this ... it will either get fixed in 
the text or fixed in the field.

Al Varney

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Aug 2002 08:50:24 +0300

Hi,

A comment on Bill's proposal.

IF we would go for Bill's proposal, of using the 18x code as early-media
indicator,  I disagree that it would concern only PSTN gateways. YES, those are
the reason this problem exist, but when a gateway receives 18x it may not know
if it's from a SIP phone, or from another gateway.

So, if  the 18x code would be used to indicate if there is early media or not,
both gateways AND SIP phones would have to use the 18x codes in the same way.
Otherwise a gateway may receive a 183  from a SIP phone, assume it sends early
media (which it does not), and the caller won't hear anything (the gateway
doesn't generate local ringback because the assumption the SIP phone will).

So, as the example above shows, using the 18x code as indicator would affect the
whole SIP protocol, and I do NOT think we want to go that way. So, from that
point of view I think the use of a FLAG (the other option which has been
discussed), with a default value no-early-media, would be easier.

BUT, if we still want to use "Bill's mechanism", an idea would be a
uri-parameter (or something similar...) indicating if the remote server is a
gateway. Then we COULD define specific 180/183 behaviour for gateways, eg to
always send 183 when early media is sent, assume early media is sent when 183 is
received from another gateway, etc etc. And, it would NOT affect other SIP
nodes, so if a gateway receives 183 from a NON-gateway it could behave
differently (for example, generate local ringback when 180 is received, and from
a ringback point of view not are about 183 messages).

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 - SIP exchanges
sending "You have now reached company X, please wait for a free operator" kind
of messages).

I have spoken...

Regards,

Christer Holmberg
Ericsson Finland