[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] sip-session-timer-11: why explicitly impose proxy restr ictions on all the b2bua's
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