RE: [Sip] sip-session-timer-11: why explicitly impose proxy restr ictions on all the b2bua's

[hisham.khartabil@nokia.com]

What ever happened to Application Servers??

/Hisham

> -----Original Message-----
> From: ext David R. Oran [mailto:oran@cisco.com]
> Sent: Friday, September 05, 2003 8:48 PM
> To: Rosen, Brian; 'Adam Roach'; 'brett@broadsoft.com'; Jonathan
> Rosenberg
> Cc: sip-ietf (E-mail)
> Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy
> restr ictions on all the b2bua's
> 
> 
> Ah, dejá vu all over again...
> 
> I'll repeat the argument I made many moons ago that we should 
> delete all 
> references to anything called a "B2BUA", except to perhaps have an 
> expansion of the acronym in our WG lexicon, and a statement 
> somewhere, 
> perhaps SIPCHANGE which says, in effect:
> 
> "A B2BUA is, loosely speaking, two SIP user agents glued together in 
> completely unspecified ways. A SIP specification intended for 
> standards 
> track MUST NOT use the term B2BUA in any normative language. SIP 
> specifications of any category SHOULD NOT use this term in 
> descriptions of 
> algorithms or protocol usage. The term MAY be used to compare 
> alternatives, 
> e.g. in requirements documents, or where the concept helps in 
> elucidating 
> the problem being addressed."
> 
> 
> Dave.
> 
> --On Friday, September 05, 2003 10:56 AM -0400 "Rosen, Brian" 
> <Brian.Rosen@marconi.com> wrote:
> 
> > I understand why you claim such a system is a B2BUA.
> > Of course, with that example, there are no rules whatsoever
> > on a B2BUA, except that each side is a UA.
> >
> > Does that imply that there should not be any mention
> > of B2BUAs at all in any document other than 3261, which
> > is quite deliberately vague?
> >
> > I would AT LEAST want to point out issues, such as
> > the "one side fails, the other side should be brought down".
> > By your reckoning, would that be out of scope for a standards
> > track document, and merely notes in some BCP?
> >
> > I've been seeing lots of B2BUA "misuse" lately.  The common
> > one is "I have a proxy that modifies headers, therefore
> > I call it a B2BUA, and everyone is fine".  There are
> > no protocol police, and there are no "architecture" police,
> > but I think it is in the community's interest to at least
> > provide expert guidance on how B2BUAs 'should' work.
> > This is an example.  'Should' is okay with me; it would let
> > your example be "legal".
> >
> > Brian
> >
> >> -----Original Message-----
> >> From: Adam Roach [mailto:adam@dynamicsoft.com]
> >> Sent: Friday, September 05, 2003 10:43 AM
> >> To: 'Rosen, Brian'; 'brett@broadsoft.com'; Jonathan Rosenberg
> >> Cc: sip-ietf (E-mail)
> >> Subject: RE: [Sip] sip-session-timer-11: why explicitly 
> impose proxy
> >> restr ictions on all the b2bua's
> >>
> >>
> >> I think the major point is that, with B2BUAs, all bets are off.
> >> As long as they look like SIP UAs on both sides, they meet
> >> spec. There's nothing we can do about this. Cullen points
> >> out exactly what I was going to. I'll expand on this some.
> >>
> >> I have a SIP phone on my desk. So does Alan. However,
> >> because I'm lazy, I often pick up my SIP phone and call
> >> his normal PSTN number. That goes to my PSTN gateway,
> >> through the PSTN to Alan's gateway, and rings Alan's
> >> SIP phone.
> >>
> >> From a protocol perspective, my PSTN gateway, the PSTN,
> >> and Alan's PSTN gateway, as an aggregate, form a B2BUA.
> >>
> >> Is there any reasonable way you can impose a restriction
> >> on such a system as a whole? No. As long as each SIP User
> >> Agent acts as a proper User Agent, everything else is
> >> completely dependant on the purpose of the system.
> >>
> >> /a
> >>
> >>
> >> > -----Original Message-----
> >> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> >> > Sent: Friday, September 05, 2003 9:06
> >> > To: 'brett@broadsoft.com'; jdrosen@dynamicsoft.com
> >> > Cc: sip-ietf (E-mail)
> >> > Subject: RE: [Sip] sip-session-timer-11: why explicitly 
> impose proxy
> >> > restr ictions on all the b2bua's
> >> >
> >> >
> >> > I thought it was because the two sessions the B2BUA bridges ought
> >> > to be considered one session wrt the session timer.  If one side
> >> > dies, the other one needs to be cleaned up.
> >> >
> >> > That being said, if one side can support session timer, and the
> >> > other can't, the B2BUA could, if it was smart enough, maintain
> >> > the session timer on the one side, and clean up the other side
> >> > on failure.  It couldn't detect failure of the non-session-timer
> >> > side of course.
> >> >
> >> > I was about to release -12, with only minor updates.  I guess
> >> > I'll let this thread play out before I release it.  I could
> >> > soften the text pretty easily.
> >> >
> >> > I personally liked the fact that B2BUA behavior was discussed.
> >> >
> >> > Brian
> >> >
> >> > > -----Original Message-----
> >> > > From: Brett Tate [mailto:brett@broadsoft.com]
> >> > > Sent: Thursday, September 04, 2003 3:49 PM
> >> > > To: jdrosen@dynamicsoft.com
> >> > > Cc: sip-ietf (E-mail)
> >> > > Subject: [Sip] sip-session-timer-11: why explicitly 
> impose proxy
> >> > > restrictions on all the b2bua's
> >> > >
> >> > >
> >> > > Why does draft-ietf-sip-session-timer-11
> >> > > explicitly impose proxy related restrictions
> >> > > on all the B2BUA's?
> >> > >
> >> > > I agree that some of the proxy concepts are
> >> > > good recommendations for some types of B2BUA's;
> >> > > however they definitely do not apply to all
> >> > > types of B2BUA's.
> >> > >
> >> > > And in general, I am surprised to see
> >> > > any draft explicitly requiring a B2BUA to act
> >> > > like a proxy.  Some B2BUA's act completely like
> >> > > a UA; others act mostly like a proxy; and others
> >> > > act at various degrees between a proxy and UA.
> >> > >
> >> > >
> >> > > _______________________________________________
> >> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> > > This list is for NEW development of the core SIP Protocol
> >> > > Use sip-implementors@cs.columbia.edu for questions on 
> current sip
> >> > > Use sipping@ietf.org for new developments on the
> >> application of sip
> >> > >
> >> >
> >> > _______________________________________________
> >> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> > This list is for NEW development of the core SIP Protocol
> >> > Use sip-implementors@cs.columbia.edu for questions on current sip
> >> > Use sipping@ietf.org for new developments on the 
> application of sip
> >> >
> >>
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol
> >> Use sip-implementors@cs.columbia.edu for questions on current sip
> >> Use sipping@ietf.org for new developments on the application of sip
> >>
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> 
> 
> 
> ------------------------
> David R. Oran
> Cisco Systems
> 7 Ladyslipper Lane
> Acton, MA 01720
> Office: +1 978 264 2048
> VoIP: +1 408 571 4576
> Email: oran@cisco.com
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip