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

[Paul Kyzivat <pkyzivat@xxxxxxxxx>]

Anders,

Thanks for identifying this. I should have remembered.

So that is a case we don't have to cope with.

	THanks,
	Paul

Anders Kristensen wrote:
> On 4/20/2010 7:04 AM, Paul Kyzivat wrote:
> > DRAGE, Keith (Keith) wrote:
> > > Do remember that there are certain cases where the UAC will not ignore
> > > it. These are the cases where the message containing original answer
> > > has not yet arrived or been lost, and the protocol has not yet
> > > recovered from that.
> >
> > Hmm. Can you say more?
> >
> > Are you thinking of a case where the answer has been sent in a reliable
> > provisional, but the PRACK has not yet been received? And then that
> > *some* SDP is included in a subsequent unreliable provisional, or 2xx?
> >
> > That is an interesting case. The one that would be least wierd is:
> >
> > UAC UAS
> > | INVITE (SDP1) |
> > |----------------->|
> > | 1xx REL (SDP2) |
> > | X--------------|
> > | 2xx (no SDP) |
> > |<-----------------|
>
> This is not a valid case. It's explicitly ruled out by 3262:
>
>    If the UAS had placed a session description in any reliable
>    provisional response that is unacknowledged when the INVITE is
>    accepted, the UAS MUST delay sending the 2xx until the provisional
>    response is acknowledged.  Otherwise, the reliability of the 1xx
>    cannot be guaranteed, and reliability is needed for proper operation
>    of the offer/answer exchange.
>
> Thanks,
> Anders
>
> > I think that implies a different best practice:
> >
> > If the UAS has sent an answer in a reliable provisional, if it sends a
> > 2xx before receiving a prack of the answer, it should include the answer
> > in the 2xx as well.
> >
> > (If the UAS intends to initiate another o/a it MUST await the prack, so
> > if the 1xx is lost it will be retransmitted.)
> >
> > Thanks,
> > Paul
> >
> >
> >
> >
> > | |
> > |<-----------------|
> > | |
> > | |
> > |----------------->|
> > | |
> > |<-----------------|
> > | |
> > | |
> > |----------------->|
> > | |
> > |<-----------------|
> > | |
> > | |
> > |----------------->|
> > | |
> > |<-----------------|
> > | |
> > | |
> > |----------------->|
> > | |
> > |<-----------------|
> > | |
> >
> > > regards
> > >
> > > Keith
> > >
> > > > -----Original Message-----
> > > > From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On
> > > > Behalf Of Christer Holmberg
> > > > Sent: Tuesday, April 20, 2010 1:47 PM
> > > > To: OKUMURA Shinji; sipping@xxxxxxxx
> > > > Subject: Re: [Sipping] Is SDP in an unreliable response "the answer" 
> > > > ???
> > > >
> > > >
> > > > Hi,
> > > > > > > Before sending an answer,
> > > > > > > - An UAS MAY send unreliable provisional responses with a SDP.
> > > > > > > - And the SDP MUST be identical to an answer SDP.
> > > > > > >
> > > > > > > After sending an answer,
> > > > > > > - The UAS should not insert a SDP in any response.
> > > > > > >
> > > > > > > Is this OK?
> > > > > > That text still doesn't say what an SDP inserted after sending the
> > > > > > answer means, only that it should not be sent.
> > > > > The SDP means nothing. it is neither an offer nor an answer.
> > > > Exactly. In my opinion that is what is important - not whether the
> > > > UAS inserts SDP or not.
> > > >
> > > > > > I still don't see why we need to make a separation about SDP sent
> > > > > > before and after the answer, because in both cases the SDP must be
> > > > > > identical to the answer.
> > > > > 1. RFC3261 says that UAS MAY send it before the answer and
> > > > > doesn't say nothing after the answer.
> > > > That is one reason why we are writing the draft - to clarify things
> > > > which may not be clear in the specs.
> > > >
> > > > > 2. The SDP MUST be ignored by UAC. it is meaningless.
> > > > I agree, and that is what we must be clear about. Because, as we
> > > > know, some people want to send a NEW offer (or updated answer) in a
> > > > subsequent response, and that is not allowed.
> > > >
> > > >
> > > > > 3. if another o/a exchange is occured (using UPDATE or
> > > > PRACK), it is not even a confirmation.
> > > > > And, again, I know there are many implementations that send
> > > > a copy of
> > > > > the SDP after the SDP answer has been sent, so instead of
> > > > saying that
> > > > > it should not be done I think it is much more important to
> > > > say that, if
> > > > > it is done, it must be identical to the SDP answer. In other
> > > > words, to
> > > > > make it clear that the UAS can not send a NEW offer (or
> > > > updated answer)
> > > > > in a subsequent response after the SDP answer has been sent.
> > > > >
> > > > > Since UAC MUST ignored it, there is no problem on a interworking.
> > > > > Why must it be identical to the SDP answer?
> > > > Well, if you look at it that way, fine. But, then the important thing
> > > > is that the UAC must ignore it - not that the UAS should not send it.
> > > >
> > > > Regards,
> > > >
> > > > Christer
> > > >
> > > >
> > > >
> > > >
> > > > > > Regards,
> > > > > >
> > > > > > Christer
> > > > > >
> > > > > > Hans Erik van Elburg <ietf.hanserik@xxxxxxxxx> Mon, 19 Apr 2010
> > > > > > 13:55:41 +0200
> > > > > > > > - An UAS MAY insert a SDP body that is identical to the
> > > > > SDP answer,
> > > > > > > > in an unreliable provisional response before the SDP
> > > > answer has
> > > > > > > > been sent.
> > > > > > > >
> > > > > > > > - The UAS MUST NOT insert a SDP body that is not
> > > > > identical to the
> > > > > > > > SDP answer, in an unreliable provisional response
> > > > before the SDP
> > > > > > > > answer has been sent.
> > > > > > > This is terribly confusing. Very probabe that noone will
> > > > > get it right.
> > > > > > > Triple negation. And talking about sending and answer before the
> > > > > > > answer has been sent. ???
> > > > > > >
> > > > > > >
> > > > > > > > - The UAS MUST NOT insert a SDP body in any response
> > > > > after the SDP
> > > > > > > > answer has been sent.
> > > > > > > This means that you can't send it again after you've send
> > > > it in an
> > > > > > > unreliable provisional response. Do you want tto say that?
> > > > > > >
> > > > > > > /Hans Erik van Elburg
> > > > _______________________________________________
> > > > 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
> > _______________________________________________
> > 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
_______________________________________________
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