Subject: [Sipping] draft-burger-sipping-em-rqt-00.txt

From: "Neil Deason" <[email-masked]>
Date: Tue, 16 Oct 2001 16:57:01 +0100

I am afraid, as much as I despise the problems surrounding 
early media and wish it would go away, this draft isn't making 
complete sense to me.

It is stated that the example msg flow in 6.1.1. Proxy 
Announcement ...

"does not truly drive a requirement for early media between 
the proxy and the media server. There are other configurations
that can satisfy the need for early media signaling to the 
gateway without passing early media throughout the SIP network." 
    
Whoever said there was a requirement for early media between 
the proxy and MS in the first place. The early media is required 
between the caller and answering end point. The counter example 
of 6.1.2 still needs early media signalling in the SIP network
between the App server and the GW. 

The signalling flow of 6.1.2 also claims to have the added 
benefit of allowing outsourcing of announcement services 
but this is also possible in the 6.1.1. There is no reason 
there why the proxy and MS have to be in the same administrative 
domains. As well as not complicating possible billing the 6.1.1 
signalling retains end to end transparency by not introducing 
a B2BUA into the network. 

In 6.2.2 I would have to disagree with the assertion that 
early media is not just a PSTN/SIP interworking. I find the 
example of a UA that is too dumb to play a media announcement 
but that is smart enough to be B2BUA hard to come to terms with. 
Early media is only a problem in a pure SIP environment 
if you go out of your way to make it one. There are many better
ways of implementing a Do Not Disturb service than this.

Cheers,
Neil
--
Ubiquity Software Corporation, UK        http://www.ubiquity.net

_______________________________________________
Sipping mailing list  http://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: "Naoto MAKINAE" <[email-masked]>
Date: Wed, 17 Oct 2001 10:53:35 +0900

Dear Neil and Eric,

I have some comments on the proposed scenarios.

- In 6.1, I do not agree on the use of 486 Busy Here response.
  486 should be issued by the called endsystem. Why not
  simply establish a both-way RTP media stream between
  the caller and the media server after 200 OK and ACK, and
  then release the call after the annnoucement, if you do not
  insist on the caller's experience of incomplete call?

  If you motivation of the scenario described in 6.1 is NOT to
  charge for an incomplete call, could you provide assumed
  charging models? If a PSTN caller could make a call to a free phone
  number, which is actually a SIP phone,  and of course without charge
  with some charging arrangement, then the caller in 6.1 could also
  hear an announcemnet after 200 OK and ACK without charge
  with the same arragement.

- In 6.2.1, an analogy of answering machine in PSTN suggests that
  the called UAS should respond with 200 OK, receive ACK,
  establish a both-way RTP media stream, play an annoucement,
  and optionally record the caller's message.

- In 6.2.2, why not redirect the call to the media server?

I am not objecting to the idea of ealry media. I just do not see
enough justification for putting more complexity into SIP.

Regards,
naoto

--
Naoto MAKINAE
Nippon Telegraph & Telephone Co.
Email:[email-masked]