Ivar Lumi wrote: > >It can RR if it wants, but it isn't needed to be transaction stateful. > The messages within the transaction are routed based on the Via >headers. > Yep responses sent ok through vias. But all mid server INVITE > transactions wait ACK, if don't add RR they never get it ? > (That means need to add RR for statefull proxy) > > But ACK flwo is confusing to me somehow. > For example: > UA1 statefull-proxy UA2 > > UA1 sends ACK -> statefull-proxy (it's passed to server transaction, how > it reaches UA2. > Server transaction processes ACK,looks for Route header, if exists > fowards ACK next hop ? > )
ACKs are peculiar. If the invite ends with a 2xx response, then the ACK is not part of the transaction. A transaction stateful proxy won't see it unless it RRs. OTOH, if the final response is >= 300 then the ACK *is* part of the transaction and the proxy will see it. The proxy has to adjust its expectations to this. > >They don't "create" dialogs. They maintain awareness of dialogs > created by the UAC and UAS. > Such case not possible ? > http://www.lumisoft.ee/ivx/sip/sip_invite_ringing.gif I didn't spend a lot of time trying to understand it. At first glance I didn't fully understand. Paul > Probably must skip call statefull stuff now, i just wanted to proxy what > support registrar,stateless,statefull,callstatefull .... > > > Paul Kyzivat wrote: >> >> Ivar Lumi wrote: >>> Ok. >>> >>> Thate means: >>> *) Transaction statefull proxy also adds recourd-route header, that >>> ensures all messages are passed back through same path. >> It can RR if it wants, but it isn't needed to be transaction stateful. >> The messages within the transaction are routed based on the Via >> headers. The RR only governs subsequent requests sent within the >> dialog (call), and so pertain to dialog statefulness. >> >>> Transaction statefull proxy don't create dialogs. >>> *) Call statefull proxy is like transaction statefull proxy, but >>> created dialogs and keeps their state. >> They don't "create" dialogs. They maintain awareness of dialogs >> created by the UAC and UAS. >> >>> Does somebody know place where i can get INVITE flow for: >>> UA1 -> call statefull proxy -> UA2 >> It looks like you only sent this response to me, so you won't be >> getting any other replies. :-) >> >> I don't. Call stateful proxies aren't very useful, so there has been >> little discussion of them that I am aware of. >> >> Paul >> >>> Especially i need UA2 ACK flow to UA1 >>> How it's passed through proxy and proxy transaction and dialog, then >>> how passed to UA1. >>> Also how BYE will go though proxy too. >>> >>> >>> >>> >>> Paul Kyzivat wrote: >>>> A call stateful proxy is a proxy - it follows all the rules for what >>>> a proxy can and can't do. It is presumably also transaction >>>> stateful, so it follows the rules for that too. Because it is >>>> following proxy rules, it must not replace the contact address. >>>> >>>> Over and above that, it keeps state about calls (dialogs, dialog >>>> usages). Presumably, because it keeps such state, it needs to >>>> monitor the end of the dialog so that it will no when to abandon the >>>> state. To do that, it needs to be on the signaling path for the >>>> duration of the dialog. Because it can't rewrite the Contact >>>> address, the only way it can ensure this is to record-route. It will >>>> then see all the messages in the dialog and can use those to >>>> maintain its state, and to know when to abandon its state. However, >>>> it won't necessarily know one of he UAs in the call die. It can use >>>> Session Timer to request that the UAs signal occasionally, and then, >>>> if it fails to see the signaling by the expected time it can presume >>>> that one end is broken and it should abandon its state. (If neither >>>> UA supports session timer then it is out of luck, and probably >>>> should not attempt to be call stateful.) >>>> >>>> An obvious question is whether there is any value in a call stateful >>>> proxy. For the most part I think they have been found to not be very >>>> useful. Potentially they could be used for logging and accounting, >>>> but they are limited in what can be done, and are dependent on >>>> session timer. >>>> >>>> Paul >>>> >>>> Ivar Lumi wrote: >>>>> >>>>> Can you explain with some words diff of B2BUA and call statefull >>>>> proxy ? >>>>> >>>>> Ok i understand B2BUA, but call statefull then ? >>>>> >>>>> I'm trying to get best way to implement dialog statefull proxy. >>>>> >>>>> >>>>> Paul Kyzivat wrote: >>>>>> >>>>>> Ivar Lumi wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'm developing free open source c# SIP stack, all almost well, >>>>>>> but now need some help. >>>>>>> (I try to make dialog statefull proxy) >>>>>>> >>>>>>> Is it right if i say: >>>>>>> Dialog statefull proxy won't add record-route header field, but >>>>>>> adds/updates Contact: field in proxy to point to proxy server. >>>>>> If you do this, you have built a B2BUA, not a call stateful proxy. >>>>>> They are quite different things, though they can be used for some >>>>>> of the same things. >>>>>> >>>>>>> I did some drawing(not finished yet) but shows what i mean: >>>>>>> http://www.lumisoft.ee/ivx/sip/sip_invite.gif >>>>>>> >>>>>>> Any help will be welcome. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
