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

From: "Francois Audet" <[email-masked]>
Date: Wed, 2 Apr 2003 16:45:03 -0800

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

The problem is that the multiple dialog problem and early media problem (as
in forking
for example) has NOT been solved. Worst, using the current unworkable
solution as a basis 
to make our decisions on the flag issue will not result in a good solution.

The current solution for forking in the draft is for the UAC to pick a
random media 
stream (based on signaling, thus the dialog, not media, because there is no
means to correlate 
dialog and media stream) and mute the others by sending UPDATEs to the far
end. This is
not an acceptable solution. Random non-redictable behavior is not acceptable
to end-users.
Furthemore, this is not robust at all because if the called UA does not
support UPDATE,
multiple streams will be received and there will be no way for the UAC
receiving it
to pick the proper one. (If there was a way to correlate an RTP stream to
the dialog that
generate it, it would be easier)

This leaves the client with 3 choices:
1) Pick a random media stream (which it will not be able to correlate with a
specific dialog
   unless it is lucky with educated guesses).
2) Mix media streams together. 
3) Provide alternative local treatment based on the provisional responses
received. This
   could be
 
You are right that the flag probably doesn't help with this problem. I'll
leave it
to others to defend the flag idea.

I'm OK with current draft, as long as we do not ADD any more dependency on
the "play
media when you receive it" principle to address the flag prolem, and as long
as we improve
the section on forking. It seems to me that if forking is used we CAN NOT
use early media for
in-band ringing (we could do early media for clipping avoidance). Perhaps we
need a 
"forked" indication in INVITE telling the far-end not to send early media...
And to make
it bullet proof a forked indication in the 100 Trying (when forking) to tell
the UAC making the
call that "weird stuff" is going to happen and that proper treatment should
be used not
to confused the user.

---

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

Francois,

you are missing the point of the draft. The draft explains what happens 
when you use early media within the dialog are forking occurs. That is, 
you have a lot of problems.

The aim of the draft is to describe these problems and to describe 
things that a UAC may do without extending the protocol. We do that 
because you have to interact with existing UASs that will send you media 
this way. You cannot upgrade the already installed base.

But we do not want to extend the protocol to provide a solution for this 
gateway model. We recommend that new systems use the application server 
model. In this model, we will provide solutions and extend the protocol 
should that be needed.

Gonzalo

Francois Audet wrote:
> The problem is that the multiple dialog problem and early media problem 
> (as in forking
> stream (based on signaling, thus the dialog, not media, because there is 
> no means to correlate
> dialog and media stream) and mute the others by sending UPDATEs to the 
> far end. This is
> not an acceptable solution. Random non-redictable behavior is not 
> acceptable to end-users.
> to pick the proper one. (If there was a way to correlate an RTP stream 
> to the dialog that
> 1) Pick a random media stream (which it will not be able to correlate 
> with a specific dialog
> 3) Provide alternative local treatment based on the provisional 
> responses received. This
>    could be
>  
> You are right that the flag probably doesn't help with this problem. 
> I'll leave it
> I'm OK with current draft, as long as we do not ADD any more dependency 
> on the "play
> media when you receive it" principle to address the flag prolem, and as 
> long as we improve
> the section on forking. It seems to me that if forking is used we CAN 
> NOT use early media for
> in-band ringing (we could do early media for clipping avoidance). 
> Perhaps we need a
> "forked" indication in INVITE telling the far-end not to send early 
> media... And to make
> it bullet proof a forked indication in the 100 Trying (when forking) to 
> tell the UAC making the
> call that "weird stuff" is going to happen and that proper treatment 
> should be used not
> to confused the user.
> 

-- 
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: Michael Hammer <[email-masked]>
Date: Thu, 03 Apr 2003 11:30:56 -0500

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.

This resolves the forking case, tells the caller which device intends 
inband media, and allows the caller with possibly user in the loop to 
decide which to listen to.

See the following:

           A          Forking Proxy       User   User  User
                                           B1     B2     B3
           |                |              |      |     |
           |    INVITE F1   |              |      |     |
           |--------------->|              |      |     |
           | 100 Trying F2  |              |      |     |
           |<---------------|   INVITE F3  |      |     |
           |                |------------->|      |     |
           |                |       INVITE F4     |      |
           |                |-------------------->|      |
           |                |          INVITE F5  |      |
           |                |--------------------------->|
           |                | 183 inband F6|      |      |
           | 183 inband F7  |<-------------|      |     |
           |<---------------|              |      |     |
           |                | 183 inband F8|      |     |
           | 183 inband F9  |<--------------------|      |
           |<---------------|              |      |      |
           | UPDATE send F10|              |      |      |
           |--------------->| UPDATE send F11     |      |
           |                |-------------------->|      |
           |                | ACK send F12 |      |      |
           | ACK send F13   |<--------------------|      |
           |<---------------|              |      |      |
Play<=====|<======Early media====================|     |
           |                | 180 inband F14      |      |
           | 180 inband F15 |<---------------------------|
           |<---------------|  CANCEL F16  |      |      |
           |                |------------->|media |      |
           |                |  200 OK F17  |stops |     |
           |                |<-------------|      |     |
           |                |    487 F18   |      |     |
           |                |<-------------|      |     |
           |                |    ACK F19   |      |     |
           |                |------------->|      |     |
           | UPDATE send F20|              |      |      |
           |--------------->| UPDATE send F21     |      |
           |                |--------------------------->|
           |                | ACK send F22 |      |      |
           | ACK send F23   |<---------------------------|
           |<---------------|              |      |      |
Play<=====|<==============="Hello"======================|
           |                |            200 OK F24      |
           |   200 OK F25   |<---------------------------|
           |<---------------|              |      |     |
           | ACK send F26   |              |      |      |
           |--------------->| ACK send F27 |      |      |
           |                |--------------------------->|
           |                |              |      |      |

Am I missing anything here?
The key is to stop guessing and make it more deterministic.

If you don't like this, don't use the inband indicator, and fall back to 
the current state of problems.

Mike

At 01:18 PM 4/3/2003 +0300, Gonzalo Camarillo wrote:
>The aim of the draft is to describe these problems and to describe things 
>that a UAC may do without extending the protocol. We do that because you 
>have to interact with existing UASs that will send you media this way. You 
>cannot upgrade the already installed base.
>
>>in-band ringing (we could do early media for clipping avoidance). Perhaps 
>>we need a

---

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

Michael,

fetch the draft below:
http://www.ietf.org/internet-drafts/draft-camarillo-sipping-early-media-01.txt

Read Section 2.3; this section explains that the gateway model produces 
undesirable results when forking is present. Therefore, you SHOULD NOT 
use this model. However, there are some situations when the gateway 
cannot distinguish between early and regular media. In that situation, 
even knowing that there may be problems if forking occurs, the gateway 
has no other choice than using the gateway model. Therefore, even if you 
had an indication telling the gateway that the call forked, the gateway 
DOES NOT HAVE ANY OTHER CHOICE.

But what happens if your system does have a choice and can actually 
distinguish between early and regular media? Go on and read Section 3. 
It provides a mechanism that, if you look at the end result, is 
equivalent to yours. Therefore, I assume that you will be happy with 
that mechanism.

Why do we use that mechanism (reverse INVITE) instead of your mechanism 
or UPDATEs with an extra stream with an "early media" label (documented 
in the draft as well)? It is explained in the last pargraph of Section 3.

"     An alternative model would consist of adding a new stream
         labeled as "early media" to the original session between
         the UAC and the UAS using an UPDATE, instead of
         establishing a new session. We have chosen to establish a
         new session to be coherent with the mechanism used by
         application servers that are NOT co-located with the UAS.
         This way, the UAS uses the same mechanism as any other
         application server in the network to interact with the UAC."

Hope this helps,

Gonzalo

Michael Hammer wrote:
> 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
>> you are missing the point of the draft. The draft explains what 
>> happens when you use early media within the dialog are forking occurs. 
>> That is, you have a lot of problems.
>>
>> because you have to interact with existing UASs that will send you 
>> media this way. You cannot upgrade the already installed base.
>>
>> But we do not want to extend the protocol to provide a solution for 
>> this gateway model. We recommend that new systems use the application 
>> server model. In this model, we will provide solutions and extend the 
>> protocol should that be needed.
>>
>> Gonzalo
>>
>> Francois Audet wrote:
>>
>>> The problem is that the multiple dialog problem and early media 
>>> problem (as in forking
>>> The current solution for forking in the draft is for the UAC to pick 
>>> a random media
>>> stream (based on signaling, thus the dialog, not media, because there 
>>> is no means to correlate
>>> dialog and media stream) and mute the others by sending UPDATEs to 
>>> the far end. This is
>>> Furthemore, this is not robust at all because if the called UA does 
>>> not support UPDATE,
>>> multiple streams will be received and there will be no way for the 
>>> UAC receiving it
>>> to pick the proper one. (If there was a way to correlate an RTP 
>>> stream to the dialog that
>>> I'm OK with current draft, as long as we do not ADD any more 
>>> dependency on the "play
>>> media when you receive it" principle to address the flag prolem, and 
>>> as long as we improve
>>> it bullet proof a forked indication in the 100 Trying (when forking) 
>>> to tell the UAC making the

---

From: Michael Hammer <[email-masked]>
Date: Fri, 04 Apr 2003 12:35:46 -0500

Gonzalo,

I had already read this once, but went back and read more closely to be sure.

You define what you refer to as the "gateway model", but as near as I can 
tell, the gateway model is simply the Offer-Answer model.  If not, you need 
to explain what the difference is.

Section 2 does an excellent job of describing the various problems.

 From pp. 7-8:

    The gateway model is, therefore, acceptable in situations where the
    UA cannot distinguish between early media and regular media. A PSTN
    gateway is an example of this type of situation. The PSTN gateway
    receives media from the PSTN over a circuit, and sends it to the IP
    network. The gateway is not aware of the contents of the media, and
    it does not exactly know when the transition from early to regular
    media takes place. From the PSTN perspective, the circuit is a
    continuous source of media.

Did you mean to say that the gateway model is NOT acceptable?

Let me see if I understand Section 3 correctly:

UAC sends INVITE with JOIN URI, which could be forked.

UAS (which could be PSTN GW) sends 180 Ringing with SDP Answer.
UAS sends INVITE to JOIN URI with SDP Offer.
UAS withholds sending RTP on first INVITE early session.

UAC receives one or more 180 Ringing with SDP Answer.
UAC receives one or more INVITE with SDP Offer.
UAC has one or more early sessions, but no RTP streams arriving.
UAC may display one or more "ringing" indications.
UAC may play locally generated ringing (ringback) tone.

UAC may select one JOIN INVITE and respond with 200 OK with SDP Answer.
    It would also stop playing local ringback.
UAC sends 182 Queued to other secondary INVITES.
UAS (1) receives 200 OK with SDP Answer and begins sending
    secondary RTP stream based on TDM stream.
UAC plays received RTP on secondary session.

UAS (first) generates 200 OK to initial INVITE.
Forking proxy CANCELS other primary INVITEs.

For UAS already playing secondary media:
UAS diverts media from TDM media from secondary session
    to already established primary session.

For UAS not playing secondary media:
UAS starts playing out TDM media to primary RTP stream.

UAC seeing RTP packets on primary RTP stream switches from
    any secondary RTP play-out to primary play-out.
UAC sends BYE to selected secondary dialog.
UAC sends final response code (4XX) to queued secondary dialog requests.
UAC receives 200 OK and sends ACK for primary INVITE.

Did I miss anything?

Now, this solves the media clipping problem and the forking problem, which 
as you say is equivalent to the case I presented.

But, it doesn't solve the missing ringback problem (which may not be a 
problem for phones with visual displays).  If the signaling is quick, the 
UAC could accept and play the secondary RTP stream containing dead air and 
suppress local ringback.

The only solutions I see so far are:

1) Require GWs to use of silence suppression and require UACs to not use 
silence suppression RTP to over-ride local ringing tone.

2) The GW or the switch before the GW to be configured to always generate 
in-band local ringing tone and override any in-band announcements/tones 
from the destination switch.

Editorial nit:  Shouldn't 2.1.1 be at the same level as 2.1 and 2.2 as 
there are three issues to address?  (Note there is not 2.1.2)

Mike

At 09:03 AM 4/4/2003 +0300, Gonzalo Camarillo wrote:
>undesirable results when forking is present. Therefore, you SHOULD NOT use 
>this model. However, there are some situations when the gateway cannot 
>distinguish between early and regular media. In that situation, even 
>knowing that there may be problems if forking occurs, the gateway has no 
>other choice than using the gateway model. Therefore, even if you had an 
>indication telling the gateway that the call forked, the gateway DOES NOT 
>HAVE ANY OTHER CHOICE.
>
>distinguish between early and regular media? Go on and read Section 3. It 
>provides a mechanism that, if you look at the end result, is equivalent to 
>yours. Therefore, I assume that you will be happy with that mechanism.
>
>Why do we use that mechanism (reverse INVITE) instead of your mechanism or 
>UPDATEs with an extra stream with an "early media" label (documented in 
>the draft as well)? It is explained in the last pargraph of Section 3.
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 05 Apr 2003 09:24:16 +0300

Michael,

> You define what you refer to as the "gateway model", but as near as I 
> can tell, the gateway model is simply the Offer-Answer model.  If not, 
> you need to explain what the difference is.

Yes, the gateway model, as explained in the draft, consists of using the 
offer/answer model **WITHIN** the dialgo established by the original 
INVITE transaction.

> Did you mean to say that the gateway model is NOT acceptable?

Yes, it means that a UAS (which can be eventually a gateway) can use the 
gateway model only under centain circumstances (see the note I have just 
sent responding to Francois' mail).

> Let me see if I understand Section 3 correctly:

The idea is that you send an INVITE in the reverse direction, and you 
will send early media using that dialog. This way, the UAC has the 
possibility of refusing this dialog.

> Now, this solves the media clipping problem and the forking problem, 
> which as you say is equivalent to the case I presented.

Yes.

> problem for phones with visual displays).  If the signaling is quick, 
> the UAC could accept and play the secondary RTP stream containing dead 
> air and suppress local ringback.

If you use the application server model, you would never generate dead 
air in the dialog established with reverse INVITE.

And systems using the application server model in that way are not going 
to send dead air in the dialog established with the original INVITE 
either. But you are right that an explicit recommendation would be nice.

Thanks for the comments,

Gonzalo