Subject: [Sip] Unify draft and 1-of-N

From: Terry L Anderson <[email-masked]>
Date: Thu, 24 Jan 2002 11:37:52 -0500

The method of section 5.1 nicely solves the 1-of-N problem, but I assume
we still want to support the N-of-N or M-of-N approach as well for
devices that do NOT have the limitiation.

How do caller and callee indicate the new interpretation of the m line
in the initial INVITE?  Caller controls the option to send a new INVITE,
but unless the second INVITE (or a COMET) is REQUIRED, caller may try to
use all M codecs returned by callee.

If the 2nd INVITE (or COMET) is required, I think M-of-N can be
supported.  Caller returns all M in 2nd INVITE if it can support them
simultaneously and Callee can return M or 1 in 2nd 200 OK depending on
its capability.  The problem is if Caller has no restriction and decides
not to send 2nd INVITE - Callee has no way to indicate its limitation.

Was it intended for bis to require the second INVITE?

Of course if neither had the restriction, the second message exchange
was not needed, but that is they way they find out.  If the restriction
or not was indicated in the first INVITE and 200 OK, the 2nd could be
saved when it was found neither had the restriction.

--

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Jan 2002 14:54:09 -0500

> devices that do NOT have the limitiation.

That works as well with the mechanism.

> use all M codecs returned by callee.

I don't follow the problem. The callee knows the full set of codecs from
the initial INVITE, so it places in the response whichever ones it is
capable of simultaneously receiving.

For example, lets say A calls B. A supports codecs X,Y,Z, and B supports
Y and Z. A can only do one codec at a time, B can do either Y or Z
simultaneously. AN initial INVITE would look like:

INVITE:

m=audio 2024 RTP/AVP X Y Z
a=inactive

200 OK:
m=audio 2024 RTP/ACP Y Z
a=inactive

ACK:

re-INVITE:

m=audio 2024 RTP/AVP Y
a=sendrecv

200 OK:
m=audio 2024 RTP/AVP Y
a=sendrecv

Seems to work fine. In the event where A has no restrictions, but B can
only do two of X,Y,Z, the initial INVITE would list X,Y,Z, and the 200
OK would allow B two pick any two, and return that. There would not be a
second exchange.

> not to send 2nd INVITE - Callee has no way to indicate its limitation.

It would indicate its limitations in the 200 OK to the initial INVITE.
If you believe there is still a problem, please send a specific flow
that doesn't work.

> Was it intended for bis to require the second INVITE?

No.

-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

_______________________________________________
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: Terry L Anderson <[email-masked]>
Date: Thu, 24 Jan 2002 15:24:40 -0500

Perhaps my confusion is simply that the behavior of each party in 5.1 is not
carefully specified.
I read it as BOTH caller and callee send ALL codecs supported (even if
restricted to 1 of N) in first exchange.  If so and the 2nd INVITE is optional
at the choice of caller then here's the problem:

caller supports M of N simultaneously, callee is restricted to 1 of N

caller sends: 0 4 8 15 97 on m line (all it can support but can only support 2
simultaneously)

callee can support 0 and 15 but only 1 simultaneously, thinking that the new
mechanism is in use (that caller MAY support only 1 of N) callee returns 0 15
on m line of 200 OK (or was callee supposed to choose only one and indicate
the rest using simcap if callee can support only 1 of N, rather than "ALL of
the codecs supported by the UA, even if they cannot be supported
simultaneously" as caller did?)

caller now decides that 0 and 8 are in common and can support 2 simultaneously
so there is no need for 2nd INVITE and so just begins using 0 and 15
interchangably.  Callee cannot handle this.

Or possibly what I am missing is that Caller indicates use of "new mechanism"
by sending inactive in the initial INVITE.  I guess if caller does this he is
obligated to send another INVITE (or COMET) to change to sendrecv and so
callee will have a later 200 OK that can be used to reduce list to one codec.

--

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Jan 2002 21:26:55 -0500

Terry L Anderson wrote:
> restricted to 1 of N) in first exchange. 

No, that wasn't the intent. Sorry if thats not clear. 

> If so and the 2nd INVITE is
> optional

In this case, the callee returns only one codec, since it can only do
one. In parallel, it ought to use simcap in the 2xx to indicate its
other codec capabilities. This way, if A wants, it can re-invite with
two codecs, rather than just one. 

-Jonathan R.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 25 Jan 2002 08:52:00 +0200

Hi,

>>Perhaps my confusion is simply that the behavior of each party in 5.1 is
>>not carefully specified.

I guess I understood the text in the same way as Terry :) 

That's the reason I brought up the question about the inband DTMF (in
another thread). I guess that's not an issue anymore...

Regards,

Christer Holmberg
Ericsson Finland