I guess there's several good reasons not to want to make proxy servers into B2BUA's. One such reason would be that a Dialog imposes an implicit requirement that requests within that dialog be processed in CSeq order. A proxy server's main job is to forward requests regardless of the order in which the sequence numbers arrive. A proxy structured as a B2BUA would kill performance ( I think ) by imposing strict ordering on processing order of requests and incur the overhead of having to track that order.
Why does a transaction stateful proxy make sense? At one point I thought I understood -- i.e it can handle forked calls without putting that burden on the User Agent. However, it appears that forking might just as well be handled in the SIP User Agent (assuming SUA's are all set up to handle forked responses). It does seem like a reasonable design choice to add a registrar to a stateless proxy server (i.e. whats being called a Registration-stateful proxy in this thread). Perhaps it also makes sense to build call stateful proxy servers ( for accounting purposes). Why would a proxy ever want to issue a BYE on its own ( just to be nice perhaps?). Ranga Paul Kyzivat wrote: >Christian Jansson wrote: > > >>>Paul Kyzivat wrote: >>> >>>- a dialog stateful proxy will maintain dialog state, which consists >>> primarily of callid, cseq, local and remote targets (contacts), >>> and route set. >>> >>> >>What is the reason a proxy would want this information given that a >>proxy can't send requests? >> >> > >Good question! > >Maybe so that it can claim to be a proxy most of the time and just >"break the law" now and then. (E.g. to send a BYE.) > >(Note that I am not advocating this.) > >I guess it could also be useful to *verify* that certain policies are >being followed. > > Paul >_______________________________________________ >Sip-implementors mailing list >[email protected] >https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
