Subject: RE: [SIP] Early media replacement.

From: "Christian Huitema" <[email-masked]>
Date: Mon, 8 Jan 2001 08:38:35 -0800

>> So, that old 183 draft which has expired will be revived, and 
>> in it will be 
>> the stuff for handling basic early media at the SDP/SIP level. 
>> 
>There are other problems with deprecating early media by using 
>re-INVITE. Consider the case where an INVITE request is 
>forked by a proxy to both a SIP desktop client and a PSTn gateway. 
>If the gateway immediately sends a 200 OK on receipt of an INVUITE 
>(with a one-way SDP body to relay the remote ringback) then the 
>desktop client will never get a chance to answer the call. 
>Between two PSTN gateways you will have a race condition.

Robert,

It would be nice to collect a complete list of issues, so that we can
really understand what is the rationale for the 183 extensions. Frankly,
our main objective right now should be to keep SIP simple; from an
architecture point of view, it is very desirable to use a single
mechanism for many purposes (i.e. re-INVITE) rather than invent a
specific hack for every specific problem (i.e. 183). 

Your "race condition" argument is not terribly convincing. The PSTN vs
desktop case that you describe is not different from the possible
race condition between a desktop and an answering machine, or, for
that matter, of the possible race condition between two PSTN gateways.
Forking an INVITE inherently creates a race condition: the first 
leg that responds with a 200-OK gets the call. Early media just makes
the matter more confusing. Imagine a call forked to two PSTN gateways,
one sending an early media that says "please dial 1 for an immediate
connection, dial 2 for voice mail" and another that says "this is
a protected line, please enter your PIN number." How exactly does
183 help in this case?

In fact, the billing argument is not very convincing either. If we
create a 183 response, we effectively create another way to establish
a call. So, I can program my desktop to always answer with a 183
response, a courtesy to my callers who won't be billed. Sure, the
PSTN will time out eventually, but the time out is rather long --
I will need to check, but it is at least 30 seconds, sufficient for
most "answering machine" conditions. Besides, I can still send the
200 OK if the call lasts longer than the timer...

-- Christian Huitema

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Alan Johnston <[email-masked]>
Date: Mon, 08 Jan 2001 13:39:13 -0600

Christian,

I disagree that the 183 itself is the hack.  It is an important and useful
provisional response.  However, using the 183 to establish a two-way early
media session is problematic, and I think it is a good idea to move the
complexity of this situation to a separate I-D which will probably have a
Require extension defined to indicate that a UA is ready to deal with the
complexity.  As Jonathan says, the base spec will still include 183, and
require a UA to listen for one-way early media packets as soon as it sends
an INVITE.

In my mind, the primary argument against getting rid of the 183 entirely
(which would force SIP/PSTN Gateways to map an Address Complete (ACM) or
Alerting message to a 200 OK) is that once you do so, you lose the ability
to indicate in a final response why a call failed.  Consider the case where
a call to the PSTN results in a Forward Don't Answer to another  number  in
the PSTN which is busy.  This could result in the following responses being
generated by the PSTN Gateway: a 183 Session Progress (indicating inband
alerting), a 181 Call Has Been Forwarded, followed by a 486 Busy Here final
response.  This lets the SIP Phone know exactly what happened to the call.
If we get rid of the 183, the PSTN Gateway would be forced to send a 200 OK
as soon as ringing took place.  Since this is a final response, no
indication of forwarding and busy could be sent besides the inband tones.
The busy tone would result in a BYE being sent - not very informative to the
SIP Phone.

In summary, I think this consensus on 183 and early media is a good one.  It
will allow any base SIP spec compliant UA to complete calls to the PSTN
through a Gateway without having to deal with the complexity of two-way
early media.

Also, the billing fraud issue you mention is not an issue in the PSTN.  You
can open up a two-way session on the IP side, but the PSTN Gateway will not
cut the PSTN trunk through in both directions until an answer has occurred
in the PSTN. Your audio path is still blocked in the PSTN.

Thanks,
Alan.

---

From: Rick Dean <[email-masked]>
Date: Mon, 8 Jan 2001 19:01:13 -0600

If we keep early media, then we need to keep 
the 183 cruft, otherwise parallel forking proxies
can't know they have forked to two simultaneous
streaming media locations, a no-no.  Never mind 
the UAC problems and possible non-support for mixing;
mixed ringbacks (even without busy & errors) 
do not make sense to end users.  My limited 
focus group testing is resoundingly negative.  
They hang up.

Gateways send early media when they don't
know what the media means.  Outlawing early
media doesn't mean they have to send 200 okay
immediately, unless they can't tell it is
ringback.  

If gateways can't tell anything, then uninformed
non-200 responses are not useful either.
Users do not listen to 30 seconds of 
busy indication, just in case the
forking proxy tries to serial fork another location.

In summary, if not even SS7 gateways can tell
what the media means all the time for at least
some destinations, then forking with PSTN is 
f*cked.

Even if you allow 183 & early media for forking
you generally don't get informative
4xx responses from gateways because
they want an error session: "The number you
have dialed is disconnected, the new number
is 888-555-1212".  I am still waiting to
flame someone for suggesting we support 
"late media". :-)

Early media doesn't help.  Let's kill it.
If gateway builders figure out a way to
detect ringback, and thus send 180, we can 
have PSTN forking again.

Cheers,
Rick
[email-masked]

P.S. Please forgive me if I always write from the
perspective of a UA (as opposed to a proxy or
back-to-back UA) without noting it.