Subject: [Sip] Thoughts on 1-of-N with forking

From: Christer Holmberg <[email-masked]>
Date: Tue, 05 Feb 2002 10:37:54 +0200

Hi,

I have some thoughts about the 1-of-N codec mechanism, and how it will
work in a forking scenario.

Assume that we send an INVITE. Then we receive multiple 18x responses,
from different servers, and we are not able to choose a common "final
codec" for all of them. The problem is that we don't know which of the
early dialogs will finally return 200, so we won't know which codec will
actually be used.

Now, if the node does support multiple codecs at the same time this is
no problem, but to my understanding the idea of the 1-of-N mechanism was
to be able to choose a single specific codec for nodes which don't.

Of course, the client can terminate dialogs which don't "fit" the common
single codec, but that would maybe not always be a very good idea. For
example, phones will start ringing, and then suddenly stop. This is also
a reason why I think it would be a good idea to handle the codec
negoatiation BEFORE the called party is alarmed...

My question is: do we need to say something about this in the spec, or
shall it be regarded as a pure implementation issue?

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 08 Feb 2002 16:04:11 -0500

> to be able to choose a single specific codec for nodes which don't.

If I only support one codec at a time, but I want to have a number of
recipients each be able to select amongst a set of codecs, each of which
wants to send me early media AND I don't want clipping of media, then
this is a provably unsolvable set of constraints for any protocol. One
needs to relax one of these constraints. Whichever one you choose to
relax, sip and o/a have a means to convey it. These include:

1. Send the initial offer with all codecs, all inactive. Each 18x
contains an answer. One or possibly more 2xx will be returned. Select a
codec common to both 2xx, and update it in each dialog with a new offer
in a re-invite. This means you will lose all early media, but only ever
have one codec in use.

2. Send the initial offer with all codecs, all inactive. Each 18x
contains an answer. The UAC picks the first one, sends it an updated
offer in PRACK, reactivating and using one codec. For the other ones, it
does not reactivate. If a 2xx comes on a different dialog, that one is
activated with whatever codec is desired. This approach allows one
branch to provide early media.

> shall it be regarded as a pure implementation issue?

I would rather not say anything. The idea is that O/A provides a fairly
general way to do stuff, and it seems we've been able to do quite a bit
with it, including various handlings of the cases above. There is no
need to standardize any of it. Any of the choices above could be made
and there would still be interoperability.

THanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com