>ACKs are peculiar. I Yep, i just found it in SIP rfc "SIP trapezoid"
Thanks for your help. Paul Kyzivat wrote: > > > 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
