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

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

As I said in a separate note, the idea is not use the mechanism that the 
application interaction design team develops. Since all the UACs would 
eventually like to be able to interact with whatever is in the network 
(e.g., introduce a pin number so that your call can proceed), this will 
be a widespread feature.

Gonzalo

Francois Audet wrote:
> Gonzallo, doesn't the mechanism in section 3 imply that the UAC sending the
> initial INVITE needs to know beforehand that this Application Server model
> will be used and therefore it would amount to requiring all SIP UAC to
> always include the join header????
> 
>  > -----Original Message-----
>  > From: Gonzalo Camarillo [mailto:[email-masked]]
>  > Sent: Thursday, April 03, 2003 22:04
>  > To: Michael Hammer
>  > 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]
>  > Subject: Re: [Sipping] New version of the early media draft
>  >
>  >
>  > Michael,
>  >
>  > fetch the draft below:
>  > http://www.ietf.org/internet-drafts/draft-camarillo-sipping-ea
>  > rly-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:
>  > > 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:
>  > >
>  > >> 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:
>  > >>
>  > >>>  > 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.
>  > >>
>  > >>
>  > >>
>  > >> --
>  > >> 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
>  > >
>  >
>  >
>  > --
>  > 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
>  >
>  >
> 

-- 
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: "Francois Audet" <[email-masked]>
Date: Fri, 4 Apr 2003 12:06:40 -0800