I want to add more to this discussion: A<--->UAx:UAy<--->B
I see some use in trying to synchronize the session timers in the B2B case. However this would require both the Refresh-Interval and Refresher are negotiated synchronously. Easier scenario would be: 'A' proposes to be the refresher with 60(or some other) second refresh interval. 'UAy' will carry out A's proposal, by presenting itself as the refresher with 60 second interval to B. 'B' will accept both the refresher and refresh-interval. 'UAx' will agree to whatever A proposed. Many other possible scenarios: 1. Both A and B want to be the refreshers. 2. A and UAx want to be the refreshers. 3. UAx and UAy want to be the refreshers. 4. ... The flexibility of configurations on the B2B and the support (or the lack) of session timers on A, B will lead to more and more use cases. Cheers, Sreedhar Pampati net.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arjun Roychowdhury Sent: Friday, March 18, 2005 6:19 PM To: Reinaldo Penno Cc: [email protected]; [email protected] Subject: Re: [Sip-implementors] RE: [Sipping] B2BUA and Session Timers 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use [email protected] for questions on current sip Use [email protected] for new developments of core SIP _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
