Re: [Sipping] Is SDP in an unreliable response "the answer" ???

[Paul Kyzivat <pkyzivat@xxxxxxxxx>]

I agree with Shinji below. But there are three things going on in this 
draft:

- collecting together and clarifying the rules as they are,
  including various inferences that are not apparent to
  all readers.

- best practices wneh sending messages.
  If these best practices are followed, certain
  problems are avoided

- best practices when receiving messages.
  This helps address the problem situations that
  may arise if the sender is doing something
  *valid* but which does not follow the best
  practices for sending.

Having a best practice for sending that avoids a problem doesn't 
eliminate the value is documenting a best practice for coping with that 
problem.

	Thanks,
	Paul

OKUMURA Shinji wrote:
> Christer,
>
> Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>
> Wed, 21 Apr 2010 13:55:15 +0200
> > Hi, 
> >
> > > I understand that this is a very rare case,
> > >
> > >         A                                 B
> > >         |                                 |
> > >         |INVITE (offer)                   |
> > >         |================================>|
> > >         |                  1xx-rel(answer)|
> > >         |<===========\  /=================|
> > >         |             \/                  |
> > >         |             /\ 18x-norel(answer)|
> > >         |<===========/  \=================|
> > >         |PRACK                            |
> > >         |-------------------------------->|
> > >         |                                 |
> > >
> > > IIUC, if 18x-norel has a SDP(answer), UAC(A) can not insert 
> > > new offer into PRACK.
> > You now seem to be suggesting that an SDP answer can be
> > transported unreliably. I strongly disagree to such statement.
>
> NO. An SDP answer transported unreliably is only a "preview" of
> the true answer.
> I know it well.
>
> > A copy of the SDP answer can be sent unreliably, and the UAC can
> > use it, but the "real" SDP answer must still be sent reliably.
> >
> > Maybe "ignore" is the wrong wording. The UAC cannot ignore
> > the fact that the reliable response contains the SDP answer,
> > because THAT SDP finishes the offer/answer transaction,
> > but it does not need to parse it.
>
> That's right. "ignore" confuse me. Another clarification is
> necessary.
>
> If 18x-norel has no SDP, this confusion can not be occured.
> Because offer/answer rules are complicated enough,
> somening unnecessary should not exist.
>
> It's "Best" Current Practices, I think.

> Regards,
> Shinji
>
> > Regards,
> >
> > Christer
> >
> > > To avoid this situation UAS should not ...
> > >
> > > Regards,
> > > Shinji
> > >
> > > Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> Wed, 21 
> > > Apr 2010 12:23:39 +0200
> > > > Hi,
> > > >
> > > > <Dean Willis hat on>
> > > >
> > > > Offer/answer is a mess. Instead, let's regard media as an 
> > > application 
> > > > on top of SIP, and use an Info Package for negotiating the 
> > > media. There 
> > > > is no connection to the SIP transactions, which means we don't need 
> > > > complicated rules on when and where to insert SDP, and we 
> > > don't need to 
> > > > describe how offer/answer works for re-INVITEs etc.
> > > >
> > > > <Dean Willis hat off>
> > > >
> > > > I don't disagree with what people are saying, but trying to read it 
> > > >from a I-am-a-new-implementor-and-I-would-like-to-
> > > > get-it-right-from-the-beginning perspective I don't think 
> > > anything is 
> > > > clarified. Eg. talking about that an SDP sent after the 
> > > answer would be 
> > > > "missunderstood as a new offer"
> > > > is confusing. The important thing is not whether the UAS 
> > > includes the 
> > > > UAS answer in subsequent responses or not, because the UAC 
> > > still has to 
> > > > handle such situation.
> > > > What is important is that the UAS MUST NOT send a *new* offer.
> > > >
> > > > Regards,
> > > >
> > > > Christer
> > > >
> > > > > -----Original Message-----
> > > > > From: sipping-bounces@xxxxxxxx
> > > > > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of OKUMURA Shinji
> > > > > Sent: 21. huhtikuuta 2010 8:45
> > > > > To: sipping@xxxxxxxx
> > > > > Subject: Re: [Sipping] Is SDP in an unreliable response 
> > > "the answer" ???
> > > > > Hi,
> > > > >
> > > > > Hans Erik van Elburg <ietf.hanserik@xxxxxxxxx> Tue, 20 Apr 2010 
> > > > > 21:53:17 +0200
> > > > > > On Tue, Apr 20, 2010 at 3:47 PM, Paul Kyzivat <pkyzivat@xxxxxxxxx> wrote:
> > > > > > > Here is my attempt at summarizing the discussion conclusions:
> > > > > > >
> > > > > > > Normative things (stated or implied in existing RFCs):
> > > > > > >
> > > > > > > - If the UAC sent an offer in the INVITE, then after it receives 
> > > > > > > SDP (the
> > > > > > > answer) in a reliable response to the INVITE, any SDP in 
> > > > > > > subsequent responses to the INVITE MUST be ignored.
> > > > > > >
> > > > > > > - Further, if SDP is received in an unreliable response to the 
> > > > > > > invite prior to receiving SDP in a reliable response, then it MUST 
> > > > > > > be treated as the answer for purposes of media processing, but not 
> > > > > > > for purposes of determining when another offer may be sent or received.
> > > > > > [HE] I miss what the UAC should do in this case for subsequent 
> > > > > > responses, does the following hold as well:
> > > > > > "If the UAC sent an offer in the INVITE, then after it receives SDP 
> > > > > > (the answer) in an unreliable response to the INVITE, any SDP in 
> > > > > > subsequent responses to the INVITE MUST be ignored/granted/... ." ?
> > > > > I agree. And it's certainly "ignored".
> > > > >
> > > > > > Regardless what the correct behaviour is, it is missing in
> > > > > your summary.
> > > > > > > - if the UAS receives an offer in the INVITE, it MUST NOT include 
> > > > > > > SDP in any response it sends until it has determined the intended 
> > > > > > > answer SDP to the offer.
> > > > > > >
> > > > > > > - once the intended answer SDP is determined, it MUST be sent in a 
> > > > > > > reliable response to the INVITE. It MAY be sent in one or more
> > > > > > > *preceding* unreliable provisional responses.
> > > > > > >
> > > > > > > Non-normative, best practice suggestions:
> > > > > > >
> > > > > > > - if the UAS receives an offer in the invite, once it has sent the 
> > > > > > > answer in a reliable response, it should not send any SDP in 
> > > > > > > subsequent responses to the INVITE.
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
> Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP