Subject: RE: [Sipping] new draft-ietf-sipping-isup-05

From: "Bose, Anjan" <[email-masked]>
Date: Tue, 13 Aug 2002 10:19:10 -0400

Gonzalo,
		But having a flag would make implantations clearer, simpler,
and easier to understand and enhance the user experience.

Anjan

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: Tuesday, August 13, 2002 7:38 AM
To: Christer Holmberg
Cc: Michael Hammer; Peterson, Jon; 'William Marshall'; [email-masked]
Subject: Re: [Sipping] new draft-ietf-sipping-isup-05

Christer,

> Yes, there ARE ways (using UPDATE for example) to first set the mode to
> inactive/sendonly, and then change the mode to sendrecv when the called
> party answers, but those methods are very "heavy"

OK, now it seems that you understood my previous messages. A flag would
reduce traffic, but it will not add new information.

It is good to keep in mind that such a flag would be an optimization,
not an enabler of things that cannot be done today.

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

_______________________________________________
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: Tue, 13 Aug 2002 19:45:26 +0300

Anjan,

I would argue that adding extra flags does not make things easier or
simpler, but I guess this depends on the point of view... anyway, how
would you see such a flag enhacing the user experience? That is, what do
you have in mind that you cannot do with UPDATE and the SDP direction
attribute that you will be able to make with the flag?

It will be useful to know the services we are missing in order to fix
our current mechanism.

Thanks,

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Aug 2002 23:28:44 +0300

Hi,

I am not Anjan :) But, I'll still give my opinion on what a flag would give us:

It would give us the possibility to establish a two-way (sendrecv) session with a
SINGLE offer/answer exchange, and if the answer is sent in a 18x the UAS can
indicate, using the flag, if it will send early media or not. The UAC can then use
that information for example to decide if to generate local ringback or not
(decission based on "local policy", and I don't think we need to mandate any
specific UAC behaviour).

If there is no flag, and the media mode is set to sendrecv in the 18x, we have
currently not came up with a good mechanism the UAC otherwise could make that
decision if to generate local ringback or not - since the sendrecv itself doesn't
necessarily mean there will be early media (some people talked about making the
decision based on incoming RTP packets, but I think it was agreed that that is not
a very good solution - and not always even possible).

From a "we-already-have-a-mechanism-for-doing-that" point of view I would like to
repeat the following ADVANTAGES of a flag:
- we would save one transaction (UPDATE/re-INVITE)
- we would prevent futher delays in the call setup (the UAS need to send BOTH 200
OK and UPDATE before the media can be sent)

I don't know how big the advantages above are. I guess it depends on the type of
node, type of network etc, but at least I think they are big enough advantages to
consider a flag :) But, again, I am not sure it's needed in the ISUP/SIP draft
(but, in that case the other stuff about early media should probably also be
removed from that draft, though)

Like I said earlier, I also proposed to add the possibility to indicate
"willingess to receive early media" to the caller preferences feature. But, I
never got any comments on that, so it would nice to know what people (at least the
author of the caller prefs draft) think about that proposal. It doesn't solve the
problem we're discussing here, but it IS related...

Regards,

Christer Holmberg
Ericsson Finland