Subject: RE: [Sipping] New version of the early media draft

From: Al Varney <[email-masked]>
Date: Thu, 27 Mar 2003 21:04:56 -0600

I haven't seen any "results" from the Early-Media Ad-Hoc (if it was held), 
so I'll toss out something I would have stated had I been there....

At 04:50 PM 3/14/03 -0500, Peterson, Jon wrote:
>They are proverbially out of luck in the CAS interworking case, no? Again,
>it's not our fault that ISUP doesn't present its status accurately
>out-of-band.

    Absolutely true.  Even more so for MF or DP trunks off a SIP 
gateway.  You can't fix the past, but you do have to worry about embedded base.

>Anyway, this is speaking to a pair of separable issues. Whether or not we
>send pre-answer media with a 180 is separable from whether or not we need
>some SIP-layer indication that we are doing so. Personally, I think we're in
>a bad position to deal with cases where ISUP provides valuable in-band
>information but doesn't tell us so in the encoding of an ACM, and I don't
>think it is reasonable for us to always send pre-answer media on receipt of
>ACM. But this is a separate issue.
>
>If we send 180, and subsequently send media, we could very well be deceiving
>a deaf user (or a user whose UA simply doesn't render pre-answer media) into
>thinking that 'alerting' tells the whole story. But if 'alerting' told the
>whole story, there'd be no need to send any pre-answer media to accompany
>it. This is the paradox I keep hearing - people want to see an indicator
>that says "alerting" and play early media, but they simultaneously
>acknowledge that the reason they want the early media is because it
>qualifies the alerting state in some fashion.  How valuable is the
>"alerting" state at the UAC, then?

    OK -- so folks want "alerting" and early media (as in ISUP), 
particularly for cases when interworking with the old PSTN.  Then why add a 
SIP-early-media indicator to 180?  Instead, why not add an "alerting" 
indicator to 183 -- which maps rather well to ISUP ACM practice (ACM always 
implies in-band media in the backward direction, and it sometimes indicates 
'user free'/alerting).  It also maps to/from ISDN in an obvious manner.

    This leaves 180 untarnished as an explicit "alerting and no intended 
early media" indicator, and local ringback could always be generated.  Any 
pre-200 media could be assumed to have gotten ahead of SIP messaging, and 
it could be cut through to the caller either immediately or after a short 
delay.

    Adding a new indicator to 183 for "user being alerted" is backward 
compatible, since RTP media would be there even if the new indicator was 
ignored.  And for cases where the indicator WAS recognized, a display or 
forking treatment similar to that for 180 could be used.  Some UA could 
even generate local ringback if it really, really wanted to do so.

    The major advantage would be better compatibility with SIP-ISUP 
gateways for interworking, and the preservation of 180 for cases where 
SIP-aware signaling was used end-to-end.  Or where gateways that could 
distinguish true alerting cases (a gateway with directly-connected lines, 
for example, always knows the true alerting state of a terminal).  Over 
time, SIP-to-SIP calls would all tend to use 180, and the old PSTN behavior 
would be contained within 183 handling (where it already has to exist).

    (While adding indicators to 183, would it also be useful to have a "SIP 
not used all-the-way" indicator that indicates interworking to non-SIP 
protocols?   Or would a UA always behave the same for gateways sending 183 
and called-UAs sending 183?)

    View this as a comment thrown out into a late-night Ad-Hoc session.

Al Varney

>I would be more sympathetic to this view if the 'alerting' state had some
>specific semantics at the UAC pointed out in RFC3261 that differentiated
>'180 received' from '183 received' or other provisional states - but it
>doesn't. There's nothing magical about receiving a 180 response. It's been
>suggested that this is valuable for forking composition, but in my
>estimation, if there's in-band media associated with a provisional branch of
>a fork, you need to evaluate that media, not the status code (again,
>otherwise, why send the media at all?). Some sort of 180 indicator that
>suppresses local ringback doesn't help you either way with any of these
>problems.
>
>Jon Peterson
>NeuStar, Inc.
>
> > -----Original Message-----
> > From: Michael Hammer [mailto:[email-masked]]
> > Sent: Friday, March 14, 2003 12:51 PM
> > To: Peterson, Jon
> > Cc: 'Drage, Keith (Keith)'; 'Elwell, John'; 'Mark Watson';
> > [email-masked]'
> > Subject: RE: [Sipping] New version of the early media draft
> >
> >
> > Jon,
> >
> > Doesn't the possibility of deaf users preclude the use of 183
> > from being
> > used, as has been suggested, since they won't hear the
> > locally injected
> > ringback or the inband media?
> >
> > Mike
> >
> >
> > At 05:52 AM 3/14/2003 -0500, Peterson, Jon wrote:
> >
> > >Below.
> > >
> > >Jon Peterson
> > >NeuStar, Inc.
> >
>_______________________________________________
>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: "Cullen Jennings" <[email-masked]>
Date: Mon, 31 Mar 2003 08:23:07 -0800

Robert posted the minutes on the SIP list with the subject "Non-Invite adhoc
minutes and action plan" - lets keep the discussion on that thread.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Al Varney
> Sent: Thursday, March 27, 2003 7:05 PM
> To: Peterson, Jon; [email-masked]