Subject: RE: [SIP] Early media replacement.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 8 Jan 2001 23:44:20 -0800

> > 
> > 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. 
> 
> In practice, I doubt calls to PSTN numbers will fork anyway. 
> That aside, a UA can deal with the multiplicity of streams in the
> standard RTP way - sort them out by SSRC, and play one and/or mix
> them as it sees fit. It needs to be able to do that whether or not
> the 183 message is present. 

I'm not sure about this. I imagine a common forking cases would a simple
"helpdesk" style attendant pool. Where one helpdesk INVITE request is forked
to a pool of attendents/extensions and the first to answer is connected. An
attendent may have either registered a PSTN/PBX extension to the proxy or
they may have forwarded their SIP phone to a PSTN number (mobile phone?) at
their local proxy. In this case, the proxy will either not know about the
PSTN endpoint or will not be able to do anything about it (ie, must still
fork).

> 
> I am unwilling to dismiss PSTN interoperability as 
> an important issue for SIP. My hope is to allow a 
> normal SIP UA phone or PC client to not have to
> worry too much about it. The proposed solution
> of receiving media after INVITE (with the caveat that
> your RTP implementation needs to be correct and sort
> by SSRC any media that comes), alleviates any complex
> work on the side of a UA, and still pretty much
> works.
> 

And from Rick Dean's reply:

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

How about switching back to local ringback whenever you receive provisional
responses from multiple UAS's? It may sound just a little bit strange but it
should not cause a user to hangup because they will probably be used to hear
this type of behaviour in existing PSTN system (for example, changes in
ringtone due to call forwarding). [I agree that mixing early media streams
is probably doomed to failure.]

As far as I can see there are three four cases:
1)PSTN gateway wants to provide remote/personalized ringback stream (or
other queued, etc non-terminal announcement). 
In this case the gateway should send the appropriate event code (180, 181,
182, etc) with SDP. One way media is end forced on both sides. This case is
when the gateway knows that the user is being alerted. It may also be issued
subsequent to 183 or other provisional responses. 
2)PSTN gateway understands that a terminal event occurred. It should send
appropriate final 300+ response without any media stream. For instance, if
the gateway knows that the stream is saying "The number has been
disconnected" it should not try to stream this message in a provisional
response. The message may even be spoken in a foreign language. For
PSTN-SIP-PSTN networks, the caller's PSTN gateway should be responsible for
regenerating a "disconnected" message in the subscribers native language.
3)PSTN gateway does not understand meaning of media stream (it could be
maybe transient ringback/announcements or it could be "terminal" call
progress events). 
The gateway has no choice but to send a 183 Session Prgress response with
SDP (and then a 4xx when the PSTN side times out). This is the least
damaging for request forking (in my mind). Returning a 200OK and playign the
"This number has been disconnected" announcement has the same effect as
returning a 6xx response, that is, it cancels all other branches which is
not appropriate as user intervention isn't possible. (IMO)
4)PSTN gateway requires interaction before the connection is established. 
In this case, the call is effectively being answered by an automated agent
and should be treated as such, that is, a 200 OK is sent and a two-way
session is set up so that DTMF digits or verbal authentication/directions
can be relayed. In this case it would be useful to have some indication to
which entity the session is currently connected "the agent" or "the user". I
don't think the effects on request forking is a large concern with this
style of session interaction.

If a PSTN call is forked and local ringback is forced (as suggested above),
the session progress announcements are lost. Is this such a big problem? If
it the request is forked then the system is probably less concerned if one
branch of the search path has "problems" (hence forking in the first place).

I still think that it would be nice to have a SIP Header that describes the
general characteristics of the entity currently "connected" to the session.
Eg PSTN Gateway, Automated Agent or Human? This information may allow user
agents and proxies to make informed decisions about "what the hell to do!"
or it could be used for billing (in the fourth case). Eg, if proxy or UA
receives a 100 Trying with a SIP header says that the call is being
processed by a PSTN gateway then it may take special action. Likewise the
200 OK could tell you whether the call is beign answered by a person or an
automated agent (and subsequently when the user is finally connected).

Comments?

Robert.

-- My opinions are my own and should not be taken as representing those
of Nuera Communications, Inc. --

---

From: Rick Dean <[email-masked]>
Date: Tue, 9 Jan 2001 11:09:03 -0600

> PSTN endpoint or will not be able to do anything about it (ie, must still

Excellent example.  

Unfortunately, with this design the phone is going to be 
flooded with media from like ten streams.  If the
media is going to be ignored anyway, then why
not have the gateways hide it and send 180.
Should the forking proxy have muted the SDP?

I do not have a good solution for this example.

--
Rick
[email-masked]

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

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 09 Jan 2001 12:38:58 -0500

> I do not have a good solution for this example.

This is an indication why tone detection should be done at the gateway
to the extent possible, with only exceptional cases (such as
announcements) be send as real audio. I'm curious what gateways or
switches that interconnect in-band and out-of-band domains do now - do
they generate both messages (e.g., MGCP or IN plus audio) or just
messages or just audio?

In any event, announcements that are not translated to SIP final status
codes would be very confusing. With forking, the caller might hear one
"sorry, the number you have dialed is not in service" because one of the
agents has mis-typed their phone number and the caller will then
disconnect, even though a dozen other agents are ready to answer his
call.

As long as the fundamental information (busy, etc.) is also available as
4/5/6xx responses, the end system would be safe to just play the first
SSRC value. Maybe we need a special RTP designation for high-priority
audio for announcements :-)

(There is the separate issue of the AT&T "smart" 800 redirector that
prompts for input prior to call completion, but that seems less likely
to be an issue in the case presented here.)

Henning
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs