OKUMURA Shinji wrote:
Hi,
gao.yang2@xxxxxxxxxx
Thu, 15 Apr 2010 17:14:09 +0800
Hi,
OKUMURA Shinji <shinji.okumura@xxxxxxxxxxxx>
发件人: sipping-bounces@xxxxxxxx
2010-04-15 17:07
收件人
sipping@xxxxxxxx
抄送
主题
Re: [Sipping] About offeranswer draft:
Hi,
I think "*same* SDP is mandatory for UAS's behavior",
[Gao] As you think *same* if mandatory, why not just ignore the real
answer, if it has gotten one in one previous unreliable response?
Because I am a kind man for an ill-behaved UAS.
nantene
and
"That same exact answer MAY also be placed in any provisional
responses sent prior to the answer." means it adequately for me.
Regards,
Shinji
I think this is again getting into the realm of "how should the UAC
behave if the UAS is non-conforming?"
We are not obligated to clarify that at all, though we *may* provide a
suggestion if it seems important.
But I am opposed to expecting the UAC to detect the non-conformance in
order to take specific remedial action. I think that is what "should UAC
refresh the media plane by the real answer" is talking about.
*If* the UAC detects this non-conformance (the indeterminacy), then it
*could* attempt to remedy it by "refreshing the media plane". But there
may be indeterminacy that has not been detected. I guess that too could
be remedied by doing an extra O/A to "refresh". But that would increase
the number of messages in cases when there is no indeterminacy at all.
And if the refresh were attempted using a reINVITE, it could simply lead
to yet another indeterminacy.
So I prefer to say nothing about the "refresh" in this draft.
Thanks,
Paul
Hi Paul and Shinji,
I guess I can converge my discussion on the point, should UAC refresh the
media plane by the real answer?
Or, just ignore the real answer, if it has gotten one in one previous
unreliable response?
IMO UAC should refresh the current view of a session description
by the real answer.
[Gao] By myself, I also prefer this one.
And no matter what direction we choose, we should do the evaluation about
whether it is violation/correction of RFC3261.
I think, in RFC3261 UAC's behavior is described based on the
premise that UAS never include the different SDP from the answer
into the prior unreliable responcse.
It is absolutely an implicit premise. But it is not bad, I think.
So then we can think that UAC's behavior for the different SDP
is not described in RFC. Therefor it can be BCP and does not
violate RFC.
[Gao] If we want to BCP thing for different SDP, we need to clarify that
*same* SDP is not mandatory for UAS's behavior.
I am not sure whether "*same* SDP is not mandatory for UAS's behavior" is
normative change from RFC3261 or not.
Quod Erat Demonstrandum.
Regards,
Shinji
_______________________________________________
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
