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

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 01 Apr 2003 08:33:02 +0300

Francois,

you must play the media you get because of the 200 OK-RTP race
condition. Therefore, your proposal of sending a 180 response saying "I
will send you media, but do not play it", will cause media clipping when
the 200 OK arrives later than the first RTP packets.

I would like people to note that this problem is unsolvable as long as
SIP and RTP follow different paths (as it is the case). Therefore, no
matter how many flags we define, the 200 OK-RTP race condition will
force us to listen to the media path in order to avoid media clipping.

Gonzalo

Francois Audet wrote:
> 
> > -----Original Message-----
> > From: Bob Penfield [mailto:[email-masked]]
> > Sent: Saturday, March 29, 2003 07:43
> > To: [email-masked]
> > Subject: Re: [Sipping] New version of the early media draft
> >
> > BTW, I do support your position that no additional indication
> > of the presence or absence of early media is required in SIP
> > signaling. If UAC receives media, it should play it.
> 
> This is actually the biggest problem I personnally have with the
> assumptions on early
> media.
> 
> I do not think that this rule of "play media when you receive it" is
> implementable
> generally, but only in a few very selected cases.
> 
> There are a number of scenarios that I think are problematic:
> 
> 1 - 180 with SDP
> 
> If a 180 is sent with an SDP (for the purpose of telling the far end
> what
> codec is picked), the called UA the shouldn't be sending silence in
> RTP because, according to the current rules, the calling UA would stop
> the
> locally generated ringing to play the silence packet. (Doing some
> heavy duty
> DSP parsing to detect if the media is silence or not seems hardly
> efficient,
> nor reliable).
> 
> A side effect of this is that if there is a NAT/Firewall involved, it
> is quite
> possible that the binding will expire and the address in the SDP will
> be invalid
> or the media will be blocked upon answer.
> 
> If an indication was present to indicate if the in-band media was
> meant to be
> replacing the locally generated tone, we wouldn't have this problem
> (i.e., one
> could send packets in-band to keep the binding alive).
> 
> 
> 2 - Sequential calling
> 
> In a sequential calling scenario such as call call forwarding no
> answer (section 2.8
> of the SIP services examples Internet Draft). Suppose the following:
> 
>    Alice            Proxy         User B1             User B2
>           |                |              |                   |
>           |    INVITE F1   |              |                   |
>           |--------------->|   INVITE F2  |                   |
>           |(100 Trying) F3 |------------->|                   |
>           |<---------------|183 ProgressF4|                   |  SDP
> is included with 183
>           | 183 Progress F5|<-------------|                   |
>           |<---------------|              |                   |
>           |   Both way RTP Established    |                   |
> In-band   |<=============================>|                   |
> ringing   |                 Request Timeout                   |
>           |                |              |                   |
>           |                |   CANCEL F6  |                   |
>           |                |------------->|                   |
>           |                |   200 OK F7  |                   |
>           |                |<-------------|                   |
>           |                |     487 F8   |                   |
>           |                |<-------------|                   |
>           |                |     ACK F9   |                   |
>           |                |------------->|                   |
>           |                |              |    INVITE F10     |
>           |                |--------------------------------->|
>           |                |              | 180 Ringing F11   |
>           | 180 Ringing F12|<---------------------------------|
>           |<---------------|              |                   |
> 
> The problem with this scenario is that presumably, upon receipt of
> 180,
> the UA needs to figure out somehow that it should be playing the
> locally
> generated alerting. This would imply that upon receipt of the 180, the
> calling
> UA would start a timer and wait until it expires to play the locally
> generate
> tone. Since ringing is composed of tone-silence-tone, the timer will
> have to be
> relatively long. While the UA can detect that the 180 is a different
> dialog than
> the 183, it can not know for sure that the first dialog had been
> cancelled
> because it could be forking: it has to rely on the media.
> 
> While this is technically feasible, it imposes a big unecessary burden
> on
> the client, especially if it is a thin client. On a "decomposed"
> architecture
> (like a stimulus MGCP phone), it makes for pretty nasty signalling, if
> possible
> at all.
> 
> PS: I'm not saying that the in-band media is necessarily useful in
> this scenario. I'm
> just pointing out the difficulties of the "play media when received"
> mantra.
> 
> 3 - Forking
> 
> As expected, this is the worst.
> 
>    Alice            Proxy         User B1             User B2
>           |                |              |                   |
>           |    INVITE F1   |              |                   |
>           |--------------->|   INVITE F2  |                   |
>           |(100 Trying) F3 |------------->|                   |
>           |<---------------|183 ProgressF4|                   |  SDP
> is included with 183
>           | 183 Progress F5|<-------------|                   |
>           |<---------------|              |                   |
>           |   Both way RTP Established    |                   |
> In-band   |<=============================>|                   |
> ringing   |                |              |                   |
>           |                |              |    INVITE F10     |
>           |                |--------------------------------->|
>           |                |              | 180 Ringing F11   |
> Locally   | 180 Ringing F12|<---------------------------------|
> generated |<---------------|              |      200 OK F13   |
> ringing   |                |<---------------------------------|
> 
> There are of course multiple permutations, such as 2 183s, 2 180s, 1
> 183 followed
> by a 180, or 1 180 followed by a 183. And then there might be more
> than 2 UAs being
> forked-to, so the problem can be really bad.
> 
> There is no way to associate a specific RTP stream with a specific
> dialog. The current
> draft hints that one UA could randomly play one stream and mute the
> others (which will be
> very troublesome if the other UA doesn't support UPDATE). This is not
> satisfactory and
> would result in garbage being played to the user. For this reason, I
> believe that the only
> reasonable approach in this scenario is to let the 180 override the
> 183s (if there is
> a 180) and ignore all media. This will of course result that there
> might be some level of
> clipping on answer (I have yet to see a network where this is a
> problem). If there is no
> 180, one could play one of the random stream (although I don't think
> it is particulary
> useful), or play some default "progress" tone that would indicate to
> the user that the
> call is forked.
> 
> One of the reason I think the 180 indication is more useful than the
> 183-with-in-band-
> media is that if the in-band from the 183 is saying "This number has
> been disconnected,
> please hangup" and then a 200 OK comes back (for the 180) wich
> connects the call, the user
> will be very disoriented (realistically, he will probably have hung-up
> anyways). The other
> way around (playing the local ringback) will at least keep the user
> on-line in case somebody
> does answer. The point is that since we can't associate a particular
> media stream with
> the SIP signalling, we can't just "play the media" when there is
> multiple dialogs.
> 
> Many people seem to think that "this is forking, it is trouble, don't
> use it, bla bla bla".
> Unfortunately, it is extremely useful. Also, it happens all the time
> today when parallel
> calling is done (different names exists for it, including "multiple
> appearances", or
> "parallel hunt groups"). If SIP can not properly ring multiple agents
> in a pool in parallel,
> it won't be terribly useful.
> 
> The only alternative is to wait for the 200 OK to connect media.
> Despite the claims of
> this introducing clipping on answer, I haven't seen this to be a
> problem on existing VoIP
> systems (i.e., the time it takes the human to answer is longer than
> the interval during
> which there could be clipping).
> 
> One added difficulty is that from the calling UA's perspective, we
> can't distinguish easily
> between case 2 and 3.
> 
> ---------
> 
> My conclusion is that when there are multiple dialogs, we can not
> honor media at the
> calling UA and have to rely on the SIP provisional responses
> exclusively. This goes against
> the "play media as soon as you receive it" principle.
> 
> Also, since parallel calling (i.e., forking) is extremely common in
> call centers and
> within enterprises, it greatly limits the applicability of early
> media, or indeed ringing
> 2 phones in a private residence. My personal opinion is that it is
> really limited to TDM
> gateway interworking, and only when there is no forking involved or
> multiple dialog
> involved.
> 
> Again, I don't believe that the "in-band alerting" indication
> necessarily solves this (although
> it does help in a few cases). I'm just pointing out that the play
> in-band RTP even if 180 is
> received is not generally a good idea. The reason I am sending this
> email in the context
> of this discussion on the in-band ringing indication is that this idea
> that playing in-band
> media automatically helps keeps on re-surfacing.
> 
> François Audet

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo
_______________________________________________
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: Christer Holmberg <[email-masked]>
Date: Tue, 01 Apr 2003 15:34:52 +0300

Hi,

Forking is always going to a problem, and that is part of the issues I have
on the "must play all media you receive" stuff. In forking cases a UAC may
use whatever local policy to decide which media stream will be played to the
user. Of course, the UAC may mix all streams together, and there will be a
risk the user will only hear a mess, but that is local policy, and should
not be required behaviour.

Also, like I said earlier, there are cases where a UAC may not be able, or
may not want to, play media before it receives a remote SDP for that stream.
I think we should at least have an early dialog established before we put
media handling requirements on the nodes - then we can discuss about how UAS
makes decissions related to local ringback etc.

So, therefore I think it is important for a UAS to send his SDP as soon as
possible - NO MATTER if it's sent in 180 or 183, and NO MATTER if he
actually intends to send early media or not (even if the UAS is not going to
send any media before 200 OK, the UAC would still need the SDP before that,
to establish an early dialog, to prevent clipping).

Just my thoughts...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Tom Taylor <[email-masked]>
Date: Tue, 01 Apr 2003 17:29:34 -0500

But Francois stated clearly that the 200 OK-RTP race condition is not a problem in 
real-life networks.

> force us to listen to the media path in order to avoid media clipping.
...
>>which there could be clipping).
...

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 02 Apr 2003 09:12:20 +0300

First of all, I do not understand why people continue discussing things 
like early media with forking whose problems are already well discussed 
and documented in the draft and nobody so far has been able to come up 
with a single use case where the proposed flag would be useful... I 
would ask people to focus on the problem in hand (i.e., the flag), and 
stop discussing about already resolved issues.

> But Francois stated clearly that the 200 OK-RTP race condition is not a 
> problem in real-life networks.

This is an amazing statement. Let's say that we both are in Australia 
with a RTT between us of 10 ms. This is the RTT that RTP will see. Now, 
our home proxies in Finland and in the US record-route because they are 
providing some kind of service.

Now, please explain me how a SIP message travelling from Australia to 
Finland, to the US and back to Australia can arrive roughly at the same 
time as the RTP packet sent directly between the terminals...

Statements like "media clipping is not a problem" or "the RTP-200 OK 
race condition does not really exist" make me think that the only reason 
for creating a flag is networks that work a la ISUP (i.e., tighly 
coupling between signalling and media)... and we agreed in San Francisco 
that that was out of scope.

Gonzalo

---

From: Takuya Sawada <[email-masked]>
Date: Wed, 2 Apr 2003 21:54:29 +0900

This may be irrelevant to the matter on this thread, media flag,
but let me clarify one thing.

RFC3264 reads that once the offerer has sent the offer, it MUST be prepared
to receive media. I do not take this statement as "it MUST play media".
To receive media is one thing and to play media can be another thing.
In my understanding, to recieve media means not to respond with ICMP error, 
to initialize sequence number, to adjust jitter buffer, to calculate
statistics, to send RTCP, etc. Once it receives media, it can play out
media but I think this is essentially the matter of application and its policy.

There is a use case that it should not play the early media:
Considering PSTN to SIP endpoint call flow, if PSTN gateway play out 
the media from SIP endpoint before the call is answered, network
operator will face the risks that its PSTN resources are consumed by
unanswered but meaningful backward voice usage. On the other hand,
network operator will have media clipping problem unless it palys early media.
You must choose media clipping or risk of the theft of PSTN resource.
I think this is the decision of network policy, not of the protocol.
Am I correct?

I really want PSTN gateways implementation to be configurable on whether 
to play out the early media or not, hopefully depending on whether the 
peer is trusted or not.

By the way, regarding the media flag, I agree with Gonzalo.

Regards, 
Takuya

> > Fran輟is Audet

--------
Takuya Sawada
KDDI Corporation (KDDI)
KDDI Bldg. 2-3-2 Nishishinjuku Shinjuku-ku, 
Tokyo 163-8003, Japan
Tel: +81-3-3347-7406
Fax: +81-3-3347-7418
[email-masked]

---

From: Tom Taylor <[email-masked]>
Date: Wed, 02 Apr 2003 09:55:08 -0500

Your difference in geography represents all of 100 ms, if I remember the formula 
correctly.  I suspect codec delays often come to more than that.  In any event, 
there is a human delay between the off-hook or equivalent and the "Hello".

Leaving that aside, the normal method of engineering grade of service is to allow 
for unacceptable results in a small percentage of cases rather than aiming for 
perfection -- the latter costs too much.  I suspect your round-the-world proxy chain 
for near-neighbours would amount to a small percentage of all calls.

Conclusion:

Gonzalo Camarillo wrote:
>> But Francois stated clearly that the 200 OK-RTP race condition is not 
>> a problem in real-life networks.
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 03 Apr 2003 08:55:32 +0300

Hi,

Some small notes...

First, please remember that in split architectures we talk about the time it takes for
the 200 OK to reach the MGC, PLUS the time it takes for the possible MODIFY/MDCX to
reach the MG.

Now, I don't know if that makes any real difference to the issue. There may still be
enough time before the "Hello" actually reaches the MG, but just to let you know...

Second, with mobile phone kind of devices, and/or hands-free kind of devices, the time
between the off-hook and the "Hello" is probably shorter than with "normal" phones,
where you actually have to lift the hook, and place it towards your ear before you start
to speak. Again, don't know if it makes any difference to the issue,  but still...

Third, the 200 race condition does not always mean we will have clipping. I am still
against the "play everything you receive" stuff, but if we have established an early
dialog with the same device which will send the 200, there probably will be no clipping
(it of course depends on if there is local ringback etc). In forking scenarios, however,
there may be clipping, since we may have established the early dialog with another
device, and do not play media received from the device which finally sends 200 first
(again, I may NOT be mixing everything I recieve from every leg, even if the spec says I
should play everything...).

Fourth, the note about the difference in receiving, and actually playing, media was
"interesting". But, I still think there should be no requirements on media handling
before the early dialog is actually established. Of course, one MAY still play and
handle whatever media he receives, without knowing if it actually comes from some of the
SIP devices he's trying to call, but everybody may not want to do that - due to a number
of reasons.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 03 Apr 2003 13:11:38 +0300

Tom,

it is not as simple as that. Your 100 ms are the transmission delay in 
optimal conditions. In the real world you will have to add queuing delay 
in the routers and processing delay in the SIP nodes.

And that is not all. Let's say that some proxies have to perform DNS 
look-ups when sending the response (sometimes you need to). You can add 
one or two seconds to the final figure...

In general, since signalling and media traverse different paths, their 
RTTs are not related. The network conditions in one path may have 
nothing to do witht he network conditions in the other.

Gonzalo

Tom Taylor wrote:
> Your difference in geography represents all of 100 ms, if I remember the 
> formula correctly.  I suspect codec delays often come to more than 
> that.  In any event, there is a human delay between the off-hook or 
> equivalent and the "Hello".
> 
> Leaving that aside, the normal method of engineering grade of service is 
> to allow for unacceptable results in a small percentage of cases rather 
> than aiming for perfection -- the latter costs too much.  I suspect your 
> round-the-world proxy chain for near-neighbours would amount to a small 
> percentage of all calls.
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 04 Apr 2003 09:47:44 +0300

Takuya,

yes, you are correct.

Gonzalo