[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Paul Kyzivat wrote:

Then the issue is that *someone else* (who Gao has had occasion to do
interop testing with) is claiming that there is a different, yet
legitimate, interpretation of the exiting text. Namely:

- *if* the UAC receives SDP in an unreliable response before
  receiving it in a reliable response, it MUST begin to use it
  in the same way that it would use it if it had been received
  in a reliable response,

- the UAC MUST (or SHOULD?) consider this SDP to be "the answer",
  and hence it MAY send another offer, even before receiving
  another copy of that answer SDP in a *reliable* response.

- still it MUST ignore SDP in subsequent responses to the

If so, then the question comes down to:

Is this alternate interpretation a valid and legitimate interpretation
of the existing text, or not?

I agree that this is a fair question to ask, and I am not yet settled on
an answer to it.

I am approaching this in the manner of a mathematical proof by
contradiction: If this alternative interpretation leads to some sort of
inconsistency, then it is not valid. If we can find no inconsistencies,
then it is a valid interpretation. And if it is, then the text is
ambiguous and will require normative changes to fix.

I have now found the contradiction I was looking for:

If the UAC thought that receipt of the unreliable response with SDP meant it could now send another offer, in what message could it send that offer? The only messages where it could include an offer are:

- an INVITE. But it is forbidden from sending another INVITE until
  the current INVITE transaction is complete.

- an UPDATE. But RFC 3311 says

      o  If the UPDATE is being sent before completion of the initial
         INVITE transaction, and the initial INVITE contained an offer,
         the UPDATE can contain an offer if the callee generated an
         answer in a reliable provisional response, and the caller has
         received answers to any other offers it sent in either PRACK or
         UPDATE, and has generated answers for any offers it received in
         an UPDATE from the callee.

  (note that this language itself is non-normative and is justified as
  a corollary of 3261.)

  This rules out sending the new offer in an UPDATE.

- a PRACK. But a PRACK can only be sent in response to a reliable
  provisional. The assumption here is that the answer has not been sent
  in a reliable provisional yet. So the PRACK would only be an option
  if a reliable provisional *without* SDP was sent after sending an
  answer in an unreliable provisional. This is a very weird case.

- in a response. But the only case where an offer is permitted in a
  response is in the response to INVITE, which isn't a possibility here.

I think the above is enough to debunk this interpretation.


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

[IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

Add to Google Powered by Linux