Subject: [Sipping] Comments on 'early media draft' and 'netann draft'

From: [email-masked]
Date: Tue, 01 Apr 2003 09:51:48 +0200

Hello all

At present, there are TWO 'concurrent' drafts that are dealing with 
early media treatments.
I can hardly understand why there are still 2 drafts ; they shoud be merged.
Or at least a part of Eric's document should be moved to Gonzalo document.

- The first from Gonzalo is describing from a general point of view how 
early media buffers
should be played ; without considering why those RTP buffers should be 
submitted.
It is a good approach I think ; more specially from the point of view of 
UAC who do not have
to take care of why it is receiving those RTP buffers.

There is a major discussion around this draft on what priority should be 
given to local ringback
and RTP buffers when 180 message has been received while the distant UAS 
is already
streaming RTP buffers.
Several points to consider :
* the 180 message is 'RINGING'. We do not have to change its meaning. It 
is the message that
must make the remote UAC to ring. Either by playing tone, either by 
showing a popup, ...
We do not have to presume how the user will be alerted.

* Prority should not be given to incoming early RTP buffers unless 
clearly specified by the remote.
It is the default behaviour implemented my most SIP terminals.
SIP and RTP streams are two different links and we have to synchronize 
them. An UAS will
receive an INVITE with an offered SDP, send a 180, initiates a RTP 
stream using the offered SDP,
prepare the answered SDP and send a 200 response.
=> The remote UAC must give priority to local ringback  until it is 
notify to give other priorities (200, 183,...).

The 183 message is clearly available 'to convey information about the 
progress of the call that is not
otherwise classified'. To notify the remote UAC that it should give 
priority to early RTP buffers we
have to override default behaviour by sending a 183 message. Here, the 
content of this message
could be discussed but probably we should use the content of the SDP to 
change priorities
maybe using 'sendonly', 'recvonly' parameters...
If the remote terminal supports it, of course a PrAck message should be 
asked.

Except this discussion point, I approve this document.

- The second draft is from Eric. He is focusing on a specific use case.
Eric is describing how a proxy or a b2b application server should forward an
INVITE to a media server, adding some parameters to ask  him to run media
treatments. Such media treatments could be played before call establishment
or after.
The proxy approach is so easy to implement  that is why I think it must 
be supported
by the solution.
But when you will want to extend this mechanism to make your media 
server to report
DTMF interactivity for example, the application server will have to be 
in b2b mode.

I approve Eric's document.
But several comments :

* Parameters that describe the announcement to be played are submitted 
as request URI
private parameters. The behaviour of SIP proxies whith those parameters 
is not clear :
some of them forward those parameters ; others remove them (e.g. SER). A 
clear position from the
WG is needed. If the proxy should not forward them, then those 
parameters should be submitted
somewhere else.

* 487 code. There is really a need for a such call flow : early media 
treatment and hang up by
a media server without sending 200 OK. It is a normal scenario and in 
now way an existing
ERROR code should be submitted to the UAC. Then, we have to provide a 
solution.
The 487 code seemed a good solution but RFC 3261 says that  it should be 
used only after
a BYE or CANCEL request. Then it should be extended maybe but what about 
existing B2B proxies
and SIP terminals ?
On the other hand, Eric reported that  'we do not want to break 
meaningful forking proxies' ; I
agree with this position.
=> We have to find a concensus on this open point.

- I made some quick tests of early media with two very used SIP 
softphone : eStara and Ubiquity.
None support PrAck message.

* eStara can play early media without problem. It can receive a 183 
message with a SDP.
Then it plays the incoming RTP buffers.
But (of course) it does not support the 487 response and does not detect 
the call has been
hang up. This illustrate the problem raised earlier of the support of 
the 487 message in this
state of existing equipments state machine.

* Ubiquity does not support at all early media.  Impossible to make it 
playing early RTP buffers.

-- 
David Rio
Alcatel CIT - Rennes
ASD France
33 2 99 87 47 18

_______________________________________________
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: Fri, 04 Apr 2003 15:18:55 +0300

David,

In the SIPPING meeting we in fact said that both drafts had to be 
aligned. However, after further analysis, we have some to the conclusion 
that alignment is not needed.

The reason is that Eric's draft does not describe how to generate early 
media. It focuses on how a proxy can instruct a media server to play 
media (in this case early) using SIP.

I commented that way of doing things in a separate note some days ago, 
by the way.

Hope this clarifies things,

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