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

From: "Francois Audet" <[email-masked]>
Date: Tue, 1 Apr 2003 07:55:28 -0800

Gonzallo,

Just a clarification. I am not proposing that we generally do NOT play the
media
if received when a 180 was sent. Indeed we should play it when possible.

I am saying that if there are multiple dialogs (as when there is forking),
and
at least one of the forks wants to play early media, we can not play it and
have 
to wait until answer. The numerous reasons were described in my past email.
There
is no forks, or when all the forks are NOT using early media, we could play
the
media (that seems to suggest discouraging allowing sending early media with
180,
or at least to have the magic flag discussed earlier).

Finally, I don't think the allege "race" condition is a real problem. I've
seen
many implementations where multiple sets are ringing, and there is no
perceivable
clipping. There are things that can be done at the UI level to minimize that
risk.

If there was perceivable clipping, then SIP wouldn't support call centers,
and
simultaneous of multiple lines when one of them does early media. That would
be
unacceptable.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Monday, March 31, 2003 21:33
> To: Audet, Francois [SC100:4K02:EXCH]
> Cc: 'Bob Penfield'; [email-masked]'; 'Jon PETERSON 
> ([email-masked])'; 'Christer Holmberg'
> Subject: Re: [Sipping] New version of the early media draft
> 
> 
> 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

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 1 Apr 2003 17:07:48 -0800

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

Agreed 100%.

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

Again, agree completely.

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

Key work is "as soon as possible". In many cases, you may not know 
before the call is answered where the media should be sent, and
have to send the SDP in the 200 OK. But if you know it beforehand, you
should definitively send it as soon as possible. 

If sent in 18X, the SDP would be useful to the caller if there is no
multiple dialog. If there is multiple dialogs, then you have the "local
policy" stuff of your first paragraph. I'm fine with this. The reason
this is a mess is that there is no sure way to associate the incoming
RTP media with a specific dialog, so it makes it extremely difficult
for the UA to make a good decision.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 1 Apr 2003 17:13:18 -0800

It may be a problem if you have a large number of slow proxies, but then you
will also have problems with calls to multiple terminations. 

I am not sure that we are doing the right thing by trying to optimize
this solution for circuit-switch interworking, to the expense of
useful SIP functionality.

Jon has often said that pure SIP implementations should not use 
early media for in-band ringing. (I agree).

But the way we are designing these procedures, any forked endpoint can send 
inband ringing with early media and effectively supercede the SIP-level call
progress 
indications that the other forked endpoints are sending. I don't think it is
a good idea.

> From: Tom Taylor [mailto:[email-masked]] 
> Sent: Tuesday, April 01, 2003 14:30
> To: Gonzalo Camarillo
> Cc: Audet, Francois [SC100:4K02:EXCH]; 'Bob Penfield'; 
> [email-masked]'; 'Jon PETERSON 
> But Francois stated clearly that the 200 OK-RTP race 
> condition is not a problem in 
> real-life networks.

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 2 Apr 2003 18:27:17 -0800

> Gonzalo Camarillo wrote:
> > 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...

Will there be clipping of RTP packets? Almost certainly.

Will there be lost of useful human speech? It depends: probably not. 

This is where UI design comes into place. On a standard phone, you need 
a certain amount of time to pick-up the handset, bring it to your hear 
and mouth and answer. In that case, that time-lag needs to be shorter than
the
time it takes for the 200 OK to be generated, transmitted and received
at the far end. This makes it very important that your SIP software
be fast enought (on the set, and in the proxies). I am not too concerned
about 
this case, because the bring-the-headset-to-your-head built-in answer delay
should 
provide a sufficient buffer.

On a UI where there is no handset to move, like a PC with a speaker and
microphone,
or a handsfree, the UI should provide some sort of built-in feedback that
the "answer" 
command was accepted. On a "soft-client" the GUI should make it clear when
the call 
is answered.

I am just saying that since we have to engineer our UAC so that it can deal
effectively with multiple dialogues (such as when forking) without being too
confusing to the user, we have to put mechanisms in place to minimize the 
clipping problem. 

Our current procedure means that "legacy" gateways, when they do the "bad"
thing
of sending early media for ringing, will also override the nice native SIP
devices
as far as which early media is played when forking. You'll get worst
clipping if 
the nice SIP terminal answers because the UAC receiving the media will have
to CANCEL 
the INVITE to the legacy gateway that is still ringing to get it to stop
sending RTP. 
Not only do you get the clipping you were talking about, but you also get
additional 
clipping resulting from the time it takes to clear the INVITE that is still
ringing,
and you need for the calling UAC to somehow (based on a timer) decice that
the
first media stream can be replaced by the second. 

I'm talking about this case:

          Alice      Forking Proxy       User   User   User
                                          B1     B2     B3
          |                |              |      |      |
          |    INVITE F1   |              |      |      |
          |--------------->|   INVITE F2  |      |      |
          |                |------------->|      |      |
          |                |       INVITE F3     |      |
          |                |-------------------->|      |
          |                |          INVITE F4  |      |
          |                |--------------------------->|
          | 100 Trying F5  |              |      |      |
          |<---------------|183 Progress  |      |      |
          |                |<-------------|      |      |
 Play=====|<======Early media=============|      |      |
   ...    | 183 Progress   |              |      |      |
          |<---------------|              |      |      |
          |                | 183 Progress |      |      |
          |                |<--------------------|      |
   Blocked|X======"Drinnnngg"====================|      |
          | 183 Progress   |              |      |      |
          |<---------------|         180 Ringing F10    |
          |     180 F11    |<---------------------------|
   Blocked|<==============="Hello"======================|
          |<---------------|            200 OK F12      |
          |   200 OK F13   |<---------------------------|
          |<---------------|              |      |      |
          |                |   CANCEL 14  |      |      |
          |                |------------->|(i)   |      |
          |                |  200 OK F15  |      |      |
      (ii)|                |<-------------|      |      |
 Play=====|<======Early media====================|      |
          |                |    487 F16   |      |      |
          |                |<-------------|      |      |
          |                |    ACK F17   |      |      |
          |                |------------->|      |      |
(i)  B1 stops sending media
(ii) Alice starts timer to detect stopped media (i.e., not normal silence)
     has to decide to now play media from B3 after being sufficiently
confident
     that the other B1 stream is stopped. Potentially big clipping.

On the idea of putting your proxy in Finland when you work in Australia...
Seems to me that while you *can* do this, it is certainly not the
best engineering practice if you are trying to maximize the responsiveness
of the system. SIP is not changing the laws of physics.

Lastly, people have different expectations from a phone service depending on

factors such as distance. If they know the far end is overseas for example, 
they are not as annoyed by a long call setup delay and expect lesser voice 
quality than if they are phoning their cubicule neighbor. If you make calls 
from cubicule-to-cubicule behave like they went from Australia to Finland 
and back, you should get braced for complaints.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 3 Apr 2003 10:38:31 -0800

I am in 100% agreement with your email.

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Wednesday, April 02, 2003 21:56
> To: Taylor, Tom-PT [CAR:5N00:EXCH]
> Cc: Gonzalo Camarillo; Audet, Francois [SC100:4K02:EXCH]; 
> 'Bob Penfield'; [email-masked]'; 'Jon PETERSON 
> ([email-masked])'
> 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: "Francois Audet" <[email-masked]>
Date: Thu, 3 Apr 2003 14:48:38 -0800

> From: Michael Hammer [mailto:[email-masked]]
> Sent: Thursday, April 03, 2003 08:31
> To: Gonzalo Camarillo
> Cc: Audet, Francois [SC100:4K02:EXCH]; Taylor, Tom-PT 
> [CAR:5N00:EXCH]; 'Bob Penfield'; [email-masked]'; 'Jon 
> PETERSON ([email-masked])'; 'Christer Holmberg'; 
> Watson, Mark [MOP:EP10:EXCH]
> Gonzalo,
> Would it be possible to have an early media convention that
> contains the 
> following elements:
> 
> 1) the receiving end indicates in signaling that it intends
> to send early media
> 2) the receiving end includes SDP in hold state and does not 
> send media at 
> first
> 3) the caller responds to one receiver's inband indicator (or 
> not) with an 
> UPDATE putting that receiver in send state
> 4) the receiving end responds to UPDATE and begins sending of 
> RTP with media.

You are right: we need to get rid of the randomness. 

How do the terminating end know that they should answer in the hold state?
Would it apply all the time (which seems to me to be a drastic change from
current implemenations), or only when there is forking?

If it is only when there is forking, it could either work as one of the
following:
(1) somehow the called party would have to know that the call is
    forked (which would be my prefered solution). I guess there
    would need to be some forking indication added to the INVITE by
    the forking proxy. This is similar to what I was hinting at, 
    but you're proposal is cleaner because it relies on signaling
    for muting the media.
(2) the forking proxy would have to modify the SDP in the INVITE to
    put the media on hold (i.e., sendonly or inactive). Of course,
    this means it wouldn't be a proxy anymore but a B2BUA, which 
    is not very desireable....

If we don't do anything about this problem, the only alternative for 
implementors of forking proxies will be to make them B2BUAs. 
Now we don't want this, do we?

Gonzallo, in response to your email: yes I totally get the point that
forking
introduces some difficulties. But what we currently have in the draft for
forking
makes it a lot worst. It needs to be fixed. If we can't do it all in this
document 
(because it requires some additions to SIP), then it may be that we need
some other 
internet draft specifically on forking. That's finewith me. I just don't
think we 
should encourage anybody to "pick a random stream" as per the current draft.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 03 Apr 2003 18:17:45 -0500

At 02:48 PM 4/3/2003 -0800, Francois Audet wrote:

> > From: Michael Hammer [<mailto:[email-masked]>mailto:[email-masked]]

I would avoid (2) as this is not always possible (secured SDP) or 
desirable.  Your forking indicator suggestion could be the trigger for the 
behavior I defined, thus distinguishing it from the current ambiguous 
"normal" behavior.  (media may/may not be in the RTP)  I just thought that 
if the intent is to use the RTP to signal that media needs to be played, 
something other than the "normal" response should inform the client that 
could then say "go ahead".

Mike

>Gonzallo, in response to your email: yes I totally get the point that forking

_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Thu, 3 Apr 2003 15:23:25 -0800

> could then say "go ahead".

Agreed. I think we need a forking indication.