Subject: [Sipping] RE: Early media draft

From: "Francois Audet" <[email-masked]>
Date: Tue, 26 Nov 2002 11:11:48 -0800

Gonzallo,

You are missing my main point. See below.

> Having a stream set up in sendrecv mode indicates that you 
> intend to send media. Otherwise, you would have set it up in 
> inactive mode. Therefore, if you intend to send media, and 
> the session has not been established, you will be sending 
> early media... 

Having a stream set up in sendrecv modes indicates that you
intend to send media: I agree with that. It does not however
indicate exactly when it will occur, and it does NOT indicate
that you will necessary provide in-band ringing. 

What I really disagree with is the recommendation in point 2
of section 3 for the pots-like UA. It basically says that it
is all right to ignore the 180 if there is a sendrecv (or
recvonly) and NOT provide an alerting indication.

This is against the loosely-coupled mechanism that you are proposing
(which I agree with). The sendrecv tag should have no impact on 
the meaning of 180. There are totally unrelated.

If a phone manufacturer follows the recommendation in the draft, it
will end-up with phones that don't ring most of the time when a call is
made to a PSTN gateway. The reason is as follows:

Contrary to what is mentioned in the draft, there is not
normally a tight coupling in the traditional PSTN between
ringback and media. The use of in-band ringback is determined
normally by the far end of the call, not the originating PSTN
gateway. If a SIP UA makes a call through a PSTN gateway, the
PSTN does not know right away if the far end will use out-of-band
ringing or in-band ringing. It will cut-through the media as soon
as possible because there COULD be some in-band ringing. This
will result in sendrecv stream. However, the far end switch may
decide to send or not in-band ringing, and it will provide an
indication of which option it is choosing (it depends on if it is
interworking with an analog trunk or not, and other critierias).
But the point is that there will be an out-of-band indication
of wether or not an out-of-band alerting should be provided to the
user. If it does NOT send in-band media (because there is no
analog trunk interworking), the user will get silence on the line
if his phone manufacture followed this draft.

This would be very bad. And I can assure you that this is exactly
what will happen.

I am just saying that the paragraph that states:

	2. If the callee is being alerted and there are no audio
	   streams in sendrecv or recvonly mode, play a locally-
	   generated ringback tone to the user.

Should be changed to:

	2. If the calles is being alerted, play a locally-
         generated ringback tone to the user.

This would introduce a lot of consistency with the graphical
UI recommendation.

The logic would be very simple:

1. sendrecv -> play the media
2. 180 -> play the alerting (in-band or or not, depending on terminal
design)

The rest of my original email simply pointed out that if this followed,
there would be less of a need to use the "inactive" tags every
single time a call is made to a PSTN gateway.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Nov 2002 21:57:20 +0200

Hi Francois,

One small clarification: does your proposal mean that IF the PSTN
network provides remote ringback there would be no 180 ringing? Assuming
the stream mode is sendrecv, you would simply pass the early media with
the remote ringback? You would not indicate on the SIP signalling level
that the called PSTN user has been alerted?

Regards,

Christer Holmberg
Ericsson Finland

> single time a call is made to a PSTN gateway.

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Wed, 27 Nov 2002 09:49:43 +0200

Hi,

> recvonly) and NOT provide an alerting indication.

You have an interesting understanding of the word "ignore" :o)

If the remote user is being alerted and you have a media stream with
media (e.g., sendrecv), it is not difficult to guess what will be
received over there (i.e., something that the remote user wants you to
play).

Anyway, you seem to be stuck with the example I provide for POTS phone.
As the draft clearly indicates, it is ONLY an example. It does not
propose that POTS phones follow such a local policy. If your favorite
local policy for POTS phones is different than mine, then go ahead
implement it. Or convince everybody that yours is the local policy to
follow and write a standard with it. What my draft does is simply
explain how early media works and the decisions you may want to make
regarding local policies if you have an homogeneous system. The local
policy you choose is up to you, and definitively outside the scope of
the draft.

Thanks,

Gonzalo