Subject: RE: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Dec 2001 16:27:44 -0500

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, December 06, 2001 11:26 AM
> To: Jonathan Rosenberg
> Cc: 'Flemming Andreasen'; Henning Schulzrinne; MMUSIC
> Subject: Re: Comments on
> <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > This did require the movement of one paragraph from this 
> draft back into
> > bis:
> > 
> > This means that a
> > re-{\INVITE} {\MAY} contain no SDP, so that the 200 OK to the
> > re-{\INVITE} contains the offer. In this case, the
> > offerer {\MUST} offer the same SDP it provided previously. 
> This is to
> > ensure that the offered SDP in the 2xx will be acceptable 
> to the UAC,
> > as there is no way to reject it.
> > 
> > This will appear in bis-06.
> 
> I think this constraint is too strong. 

We had formerly agreed to it in sip (with the additional flexibility that
you can change the IP address/port).

> 
> Consider:
> 
> 	A                   B
>         |   INVITE(sdp)     |  offers codecs X,Y
>         |------------------>|
>         |      OK(sdp)      |  accepts X, not Y,
>         |<------------------|  would have accepted Z if offered
>         |      ACK          |
>         |------------------>|
>         |   INVITE(no sdp)  |
>         |------------------>|
>         |      OK(sdp)      |  should be able to offer X,Z
>         |<------------------|
>         |      ACK (sdp)    |
>         |------------------>|
> 
> In this standalone case, it probably isn't likely that A will be
> interested in Z the second time if it wasn't the first time. 
> But if A is
> a B2BUA, it might be preparing to involve another party that is very
> interested in Z. 

OK, but in this case it would be a new dialog for the new party, so that you
would have no previous sdp.

> 
> I believe the rule should be that on reinvites without sdp, 
> the response
> should be the same as last time, or a superset of that.

I'm just trying to keep it simple, and don't like revisiting decisions
agreed to previously on the lists...

-Jonathan R.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Dec 2001 18:57:17 -0500

Comments below.

	Paul

> you can change the IP address/port).

Just because it was agreed to doesn't mean it was right.

> would have no previous sdp.

I was suggesting that A is a B2BUA bridging between a party C not shown
above and B. A then decides to replace C with a different one D. So
there is a new dialog with D, but the dialog between A and B remains.
Something like the following:

C                   A                   B
|   INVITE(sdp)     |                   |  offers codecs X,Y
|------------------>|                   |
|                   |   INVITE(sdp)     |  offers codecs X,Y
|                   |------------------>|
|                   |      OK(sdp)      |  accepts X, not Y; would
|                   |<------------------|  have accepted Z if offered
|                   |      ACK          |
|    OK(sdp)        |------------------>|  
|<------------------|                   |  accepts X, not Y
|    ACK            |                   |
|------------------>|                   |
                    |                   |
D                   |                   |  prepare to xfer to D
|                   |   INVITE(no sdp)  |
|                   |------------------>|
|                   |      OK(sdp)      |  can only offer X
|                   |<------------------|  (should offer Z too)
|   INVITE(sdp)     |                   |  "
|<------------------|                   |
|   488             |                   |  Fails - D can only do
|------------------>|                   |  Y & Z, not X.

//

|   OK(sdp)         |                   |  If X,Z had been offered
|------------------>|                   |  would accept Z
|                   |      ACK (sdp)    |
|                   |------------------>|  then all is well

This is too simplistic for a practical call flow, but it makes the
point.

> agreed to previously on the lists...

Another case of something that happened before my time.

This arises in more complex flows that may not have been considered
before. I believe these more complex flows become more important as
people get familiar with the technology.

	Paul