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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 1 Dec 2000 14:36:39 -0500

OK, obviously there is much to be said here.

Neil writes:
>Or indeed ACK. Is late SDP in ACK for 3pcc really that 
>difficult to support? Some people certainly do it already and I 
>plan on testing for this at the upcoming bakeoff. 

First off, let me motivate the change in the 3pcc spec. The problem is that
the controller has to delay sending an ACK to one of the UAs (say UA A)
until it comples an INVITE transaction with the other (say UA B) (or at
least until it gets the 200 OK). Now, the problem is that while this INVITE
transaction is pending with B, A is going to be retransmitting the 200 OK.
If it does not receive an ACK within 32 seconds, it gives up and the call is
terminated. However, the INVITE transaction pending with B may take more
than 32 seconds to complete. As such, the setup may fail. So, the problem is
twofold (1) the setup failure when the second INVITE takes too long to
terminate, and (2) the excessive 200 OK retransmissions that serve no
purpose. Its all because ACK is serving two roles; to complete the
transaction, and to carry SDP.

Now, a separate issue is my, er, well received proposal to eliminate SDP
from ACK.

Brian writes:
>> 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).
>
>I am specifically aware of a commerical implementation that actively does
this.

OK. Removal of things can only happen if they were not commercially
implemented. It was my hope that none of the SIP-H.323 converters were
really deployed yet, and that furthermore, we wouldn't see much v1 traffic.
If thats not the case, the proposal is dead.

Re: the PRACK proposal, I'll buy into the argument that overlapping initial
INVITEs is even more horrible to deal with then the various SDP cases, so
I'll back off on that too.

Dave Oran writes:
>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.

I guess what I want is some kind of simple model, along the lines that Dave
is proposing. The model needs to work across INVITE, ACK, multiple
provisionals, and 200 responses. I.e., how would we handle something like
this

            |  INV SDP1                |
            | -----------------------> |
            |                          |
            |  183 SDP2                |
            | <----------------------- |
            |  PRACK SDP3              |
            | -----------------------> |
            |                          |
            |  200 PRACK SDP4          |
            | <----------------------- |
            |                          |
            |  200 INVITE SDP5         |
            | <----------------------- |
            |                          |
            |  ACK SDP6                |
            | -----------------------> |
            |                          |
            |                          |
    
           UAC                        UAS

Now, there are *6* SDPs here. WHat happens if there is some message
reordering; for example, if the 200 PRACK arrives after the 200 OK (assuming
we allow SDP in PRACK responses; I don't recall discussing it. The idea is
to show that this is all complex to handle in the general case).

For a general mechanism like Dave is proposing, there needs to be a
well-defined ordering amongst which SDP are used to determine "the most
recent". Anders has pointed out some issues as well:

>When a UA does a re-INVITE with updated SDP it effectively proposes new
>media settings. If for whatever reason the UAS can't or won't honour
>those settings it can reject the INVITE. If media settings are updated
>in an ACK there's no way for the UAS to tell the UAC that it doesn't
>have enough bandwidth or it doesn't support any of those codecs etc.

In more general terms, which of the SDP to use in the definition of the
session depends not only on ordering, but on the messages themselves. 

Now, this is not unsolvable, but will take some work to sort out.

Robert had suggested another use to the SDP-everywhere counter-approach:

>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

We must also consider backwards compatibility. I don't know how existing UAs
would react to this kind of flow.

-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

> -----Original Message-----
> From: Anders Kristensen [mailto:[email-masked]]
> Sent: Friday, December 01, 2000 11:18 AM
> To: Brett Tate
> Cc: [email-masked]
> Subject: Re: [SIP] as if there wasn't enough traffic on this darn
> list...
> 
> 
> 
> 
> Brett Tate wrote:
> > 
> > > > > So generally allowing SDP in ACK could work for some 
> operations. I
> > don't
> > > > > think it's worth the confusion, though. Better simply 
> to say that ACK
> > is
> > > > > for stopping INVITE retransmissions only. If you want 
> to modify media
> > > > > settings do a re-INVITE.
> > > >
> > > > For 3pcc a re-INVITE loop would potentially
> > > > get established if both sides keep changing
> > > > ports with every re-INVITE (and particularly
> > > > when the same port is not used before and
> > > > after hold).  This is why SDP in ACK for
> > > > re-INVITEs is important for 3pcc.
> > >
> > > Yes, but why would the UA keep changing ports (or 
> anything else in the
> > > SDP)? There are many ways SIP UAs can misbehave. This is 
> just another
> > > way of misbehaving. For example, is this much different 
> from the fact
> > > that a 3pcc controller can't keep either UA from 
> re-inviting over and
> > > over again for no good reason?
> > 
> > That is just it, according to the rfc2543, this
> > is not misbehaving.  Changing port
> > and/or connection address is even
> > part of the new advance media scenarios
> > for the upcoming bakeoff.
> 
> Well, that's my point. The point of view of rfc 2543 and the 3pcc
> controller are not the same here. Both behaviours are legal 
> according to
> rfc 2543 and both are Bad according to the 3pcc controller.
> 
> --
> Anders Kristensen
> 
> _______________________________________________
> 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: Manoj Bhatia <[email-masked]>
Date: Fri, 01 Dec 2000 15:32:04 -0500

I wonder why there is an assumption that the 3pcc -00 draft has not been
implemented so far. At the fifth bakeoff , there
were  at least 4-5 working implementations on this and the 6th bakeoff
would have more.

Further in the call flow below, the fact that a PRACK can change SDP from the
initial
INVITE defeats all the QoS reservation that manyfolks draft proposes.

So,  making rules that
1) A  change in SDP can only be introduced via re-INVITEs is a safe assumption
to have.
2) SDP in PRACK not allowed; ( rules need to be clarified under the context of
'manyfolks' draft
and not under '3pcc' or SIP in general.) would help a bit.

As per Robert's proposal to a two-way handshake on codec negotiation , we are
almost
close to H.323/H.245 now !
Surely, it would cause hiccups to SIP-UAs today but may eventually solve the
negotiation issues later.

Making some strict rules now combining 3pcc and 'manyfolks' drafts on PRACK
especially would help.

thanks
-manoj

--
Manoj Bhatia                           |        |         |
[email-masked]                       |       :|:       :|:
7025 Kit Creek Road, RTP, NC - 27709   |     :|||||:   :|||||:
Ph: 919-392-3873  Fax:919-392-6801     |  C i s c o S y s t e m s