I see this as no worse than what we have today, and there is little we
can do about it. A bad UAC implementation is a bad UAC.
Unfortunately, this is one of those excuses for an SBC...
On Oct 25, 2008, at 12:21 PM, Salvatore Loreto wrote:
the following paragraph of Section 5.2 puzzles me:
If a server receives an INFO request with a body it understands, but
it has no Info-Package header, the UAS MAY render the body. Note the
semantics of "rendering" is up to the Info Package definition. The
UAS MUST respond to the INFO request with a 200 OK. This enables
legacy use of INFO.
Now it states that is to enable legacy use of INFO, but at same time
refer to the Info Package definition
that is something only for the new usage.
IMO with this text it would be possible send also an INFO request
the other end is not willing to receive,
it is enough not include the Info-Package header. Is this can be
seen as a possible security problem?
Thanks
Sal
Paul Kyzivat wrote:
While I see rules in 5.1 and 6 that permit use of legacy packages
at the INFO UAS, I find no rules that permit sending a legacy INFO.
I guess it must be possible to use legacy INFO even when both sides
support this new info package mechanism. And I guess the evidence
that a UA *doesn't* support this new mechanism (by the absence of
the headers in request/response) is just equivalent to one that
explicitly negotiates support of no packages.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
