Matthew Gardiner wrote:
> I think this interpretation of RFC3262 breaks backward
> compatibility with
> RFC3261.
>
> That is, an implementation coded according to RFC3261 refuses
> a call setup
> when there is no SDP in the 200. RFC3262 comes along and this
> behaviour is
> now "incorrect". I had assumed that newer SIP specifications
> augmented,
> rather than modified, existing ones.
I disagree. If you implement only RFC3261, then you will not see
a 200 without SDP. To quote the extract someone else already quoted:
RFC 3261 13.2.1 2nd bullet
If the initial offer is in an INVITE, the answer MUST
be in a reliable non-failure message from UAS back to
UAC which is correlated to that INVITE.
For this specification, that is only the final 2xx
response to that INVITE.
Since you have implemented RFC3261 alone (specifically not RFC3262), then
you cannot advertise support for reliable provisionals (Supported: 100rel)
and so will not receive them. Therefore, the answer MUST be in the 200
response.
If, on the other hand, you decide to implement RFC3262, then you must
implement it all. Including the bit about not necessarily getting an
SDP in the 200 if you received one reliably earlier.
Paul Kyzivat was right when he wrote:
# This is no accident. The language is as it is in 3261 precisely to
# anticipate the reliable provisional mechanism.
# The language is fine tuned to still permit the answer in the 200 in this
# case to provide backward compatibility.
Regards,
Michael Procter
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
