Subject: Re: [SIP] as if there wasn't enough traffic on this darn list...

From: [email-masked]
Date: Thu, 30 Nov 2000 14:00:53 +0530

SDP in PRACK I have no problems with.

However ,removing SDP in ACK will break some SIP-H.323 implementations
which send media
on ACK. There were two approaches to this, one of which was SDP in ACK. So
those who took this latter
approach will suffer (although I dont know how many commercial deployments
exists - I guess for most
it would just be another evening or two  of re-working in their labs)

As far as receiving multiple INVITE before each trans. end is concerned, at
first thought this seems messier
for the developer. All this while , if you received T2 while T1 was in
progress (T=Transaction) from the same
endpoint, you could send a bad message with a retry after. This made
implementations simple, but now with
multipe INVITEs, the receiving side has to remember:
     * CSeq values of all INVITEs and respond with app. 200 OKs
     * remember possible diff. media parameters for each recvd. INVITE and
respond with OK
     * know how to correlate an ACK recvd afer it sends back Ok for one of
the overlapped invites.
     <etc ?>
All this can be surely implemented, but at first thought, it looks dirty.
Agreed though that it solves some problems
of efficiency (eg overlapped dialing).  This entire thread of record-route
reworking along with now multiple INVITEs
before they complete seem to be slowly making life that much more difficult
:-)

Thoughts ?

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

Jonathan Rosenberg <[email-masked]> on 11/30/2000 01:36:05 PM

To:   "[email-masked]'" <[email-masked]>
cc:

Subject:  [SIP] as if there wasn't enough traffic on this darn list...

So, figuring we didn't all have enough email on the sip list to read (I am
personally hopelessly behind), let me stir things around some more with
another proposal for something to ditch from the spec.

Right now, you can carry SDP in the INV/200/ACK exchange in two ways. You
can send nothing in the INVITE, followed by SDP in the 200, and then SDP in
ACK (and fortunately I don't know anyone who actively does this). Or, you
can send SDP in INVITE, SDP in 200, and nothing in ACK. I also think there
are several confused implementations that likely send it in all three.

Add to this the unfortunate PRACK mess, which also has been used to send
SDP
in order to support the manyfolks resource work when used with 3pcc, but
which is yet unimplemented.

It all adds up to a messy confusion. Its not clear what it means to send
SDP
in all these places, and how it works.

So, my proposal is that we simplify. We only allow SDP in INVITE and then
provisionals/200 OK. No SDP in ACK. No SDP in PRACK. (sounds like a Dr.
Seuss rhyme, doesn't it?)

The latest 3pcc draft no longer recommends using the SDP-in-ACK, since it
has problems. Given that there don't seem to be useful applications of it
any longer, and given that, to my knowledge, it is not sent by anyone (at
least not in any commercially shipping boxes, I hope), I'd like to yank it.

There is a consequence, and that is dealing with the manyfolks requirement
for sending an updated SDP to deal with manyfolks+3pcc. My proposal for
that
is to use a re-invite, rahter than PRACK, to carry the updated SDP. This
does mean that we need to allow, in SIP, a re-INVITE to arrive while an
initial INVITE is in progress. Allowing this would also address some of the
concerns raised in previous threads about handling requirements for changes
in early media.

I don't think its hard to deal with the re-INVITE while INVITE-is-active
case. The simplest solution is to reject the first INVITE and continue
processing with the second one, using the new SDP and all.

Anyway, before getting into those details, what does the group think about
dropping the SDP-in-ACK and SDP-in-PRACK stuff?

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Arnoud van Wijk (ELN)" <[email-masked]>
Date: Thu, 30 Nov 2000 13:36:06 +0100

Hello Jonathan,

Hmm yes,it is a good idea to keep things clear.
I agree that it is a good idea to keep the ACK free of SDP and if you want to change the session, then to send a re-invite.

Another advantage is that in this case, the UAs can already act on the 200 OK SDP message without waiting for the ACK.
(saves some time).

cheers

Arnoud

_______________________________________________________________
ERICSSON EUROLABS NETHERLANDS BV
Arnoud van Wijk
ABACUS Lab
Research & Development (ELN/V)
Fax: +31-161 247569
_______________________________________________________________

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 30 Nov 2000 17:52:08 -0800

> 
> Hmmm, I would simplify by going the OTHER direction and 
> allowing SDP in any leg of an INVITE transaction. The meaning 
> would be coupled with the state the transaction is in. This 
> allows for 3-way negotiation of SDP, and allows very simple 
> rules: the SDP you operate on, and reply to is the one you 
> received in the last Request (INVITE or PRACK).
> 
> The simple call scenarios don't get any more complicated: you 
> use the most recent SDP sent, otherwise the most recent one 
> you received.
> 
> That gives much more flexibility and eliminates the special 
> case rules as well.

It also removes the problem whereby one side doesn't support
unannounced/arbitrary/intermixed vocoder changes or assymetric vocoder
selections.

eg 
INVITE has SDP with m=audio 12150 RTP/AVP 0 2 4 8
200 OK selects m=audio 12150 RTP/AVP 0 2 but caller's UA doesn't support
multiple codecs or wants to use ony one vocoder, so send
ACK re-selecting m=audio 12150 RTP/AVP 0

There _are_ implementations that are commercially shippped which support for
SDP-in-ACK and people have tested this functionality at previous interop
events (even tested with the Dynamicsoft UA). As H.323-SIP gateways start
appearing on the market I think you will find more and more SIP user-agents
wanting to support this function as they will want to interoperate with the
all the Microsoft Netmeetings and existing H.323 equipment. 

I think there will be a lot of hidden problems and complexity with the
suggested re-INVITE before INVITE completes. Implementation complexity (I
feel) will be significantly higher and there great number of different
message permutations that will need to be tested. I can't see it being very
backwardly compatiable either. 

I do believe we need to fixed the re-INVITE glare mechanism which is (IMO)
currently unworkable, this however is a separate problem.

Regards,

Robert.

-- My opinions are my own. I tried selling them once but everybody
	seems to already have one. --