I think you are applying the text too literally to a usage which is essentially abstract (ie a B2B). Though it is expected that a B2B behaves outwardly as a UAC/UAS, there is no specification that says how a UAC/S component of a B2B gathers what its capabilities are. This would be a policy that is dependant on what you are building.
As an example, if you are creating a B2B that acts like a message forwarder but mangles SDP as a message passes along its logic, then, you might feel better assuming this: A<--->UAx:UAy<--->B where your 'policy' dictates: UAy (in UAC mode) will form a message that honors headers from A (nothing wrong with this - its a UA at the end of the day, and my policy decides what constitutes its 'capabilities') UAx (in UAC mode) will form a message that honors headers from B (nothing wrong with this - its a UA at the end of the day, and my policy decides what constitutes its 'capabilities') That should address your concern. Do note that it still may be needed for you to process/change certain headers such as session-timer/max-forwards etc - that depends on what your intent is (transparent/non-transparent) - thats yet another epic alltogether. OTOH if you are creating a B2B that hosts an application such as conferencing etc, then the UAs there may have more 'traditional' ideas of what its capabilities are. regds arjun On Fri, 18 Mar 2005 15:48:33 -0500, Reinaldo Penno <[EMAIL PROTECTED]> wrote: > So, > > First of all, sorry for the cross posting and thanks for the answers. > > What I got from the answers I received is that both sides should behave > like a UA in face of unrecognized/unsupported headers. > > Reading RFC3261, the following is said about unrecognized headers: > > "8.2.2 Header Inspection > > If a UAS does not understand a header field in a request (that is, > the header field is not defined in this specification or in any > supported extension), the server MUST ignore that header field and > continue processing the message. A UAS SHOULD ignore any malformed > header fields that are not necessary for processing requests." > > Now, if both sides should behave like UA, it does not make much sense > from a UA behavior perspective to "bridge" a header to the UAC side that > the UAS side does not understand. I mean, does it make any sense for an > UAC to insert an unknown header in its own request? > -- Arjun Roychowdhury Flextronics Software Systems _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
