Bogdan-Andrei Iancu wrote: I wondered what would be necessary to disconnect them: It's basically the From header, To header, the Route-Set (upstream and downstream) and the CSeq (upstream and downstream). I think it is not that hard to store these parameters within the dialog data. I guess there also storing some dialog data inside the mediaproxy/nathelper module (or is it inside the RTP proxy?). Maybe this could be combined to build a real B2BUA. regards klau

Klaus Darilion wrote: indeed, this is a long term target. regards, bogdan

Would it be much work to store Via in the dialog structure, remove it from the message, and add it to replies? regards klaus Bogdan-Andrei Iancu wrote:

Klaus Darilion writes: new sems has b2bua support. it is trivial to write sems b2bua application that disconnects a call after a given time. -- juha

Klaus Darilion writes: sems/openser communication is based on unix sockets. you can take conf_auth application, remove most of its lines, and you have an application that disconnects the call after a given period. period can can be given to the application on a call-by-basis, for example, in some P header, queried from database, radius, etc. -- juha

Klaus Darilion writes: yes it is true b2bua. media goes direct though. no, as i said, it handles only signaling, which to me sounds like a much more scalable idea than relaying also media. you handle nat traversal by openser. sems b2bua does not need to be aware of nat. yes. -- juha

olivier.taylor writes: http://svn.berlios.de/viewcvs/sems/ it has all kinds of media facilities, but those are not needed in b2bua signaling application. -- juha

Take a look at Asterisk regards klaus On Wed, July 19, 2006 2:26, Mark Anthony C. Delfin said:

Wait, I thought that the new version of OpenSER had a module for being dialog stateful. Is this wrong? --Mike On Tuesday 18 July 2006 01:05, Javier Ramirez wrote:

It's not necessarily a bad idea either, it depends on what you want to do with it. Persisting dialog info (e.g. to DB) will help handle dialog-stateful proxy failures. This would be a nice feature. Of course, there is a tradeoff in terms of performance. JF On 7/18/06, Juha Heinanen <jh(a)tutpro.com> wrote:

You can have pre-paid SIP services without PSTN. Also, an IMS S-CSCF based on SER would require this in order to be fully compliant to 3GPP standards, but probably this is of no importance in the scope of this list. JF On 7/18/06, Juha Heinanen <jh(a)tutpro.com> wrote:

inline On 7/18/06, Juha Heinanen <jh(a)tutpro.com> wrote: SIP-IPTV perhaps. Why would PSTN calls be the only motivation for people to pay? When that becomes cheap or for free, people will continue to pay for access to content that matters to them, no? Following you e-mail analogy, you might subscribe to online magazines, delivered to you via e-mail. Of course, in a first phase carriers prefer to try out plain SIP and not go to full IMS. But when "carriers" (or you can say "SIP service providers") start needing to control resources consumed by SIP sessions in their network and need to come up with a flexible and cheaper way to roll out new SIP services, IMS was designed for that (well or badly, we're not discussing that). You might argue you can just use the Internet and don't care about QoS, but to access some services the Internet may not be good enough, yet... And then "SIP service" needs to be defined... it's certainly not just PSTN termination. Can be anything provided via a SIP infrastructure. Maybe we're getting too off topic here... I don't want to get into IMS flame wars. I'm just saying some IMS concepts may make sense in "non-IMS" environments, especially when trying to provide (SIP) services in a flexible way. JF

Because then you will end up having one charging system per service and you won't be able to easily extend it to support further services you might want to add. In IMS it's not the "SIP proxy" that terminates the session when money runs out. For this B2BUA application servers can be used (similar to what many people on this list do with Asterisk). IMS CSCFs are required to be able to terminate SIP sessions on other circumstances, e.g.: - at deregistration or registration expiration (makes sense, but not mandatory in non-pure-IMS scenarios) - network-initiated session release (not a nice thing and probably only makes sense in some telco scenarios) - when receiving "out of radio coverage" indications (also only useful in 3GPP or other wireless network scenarios) IMO the dialog statefulness in the proxy would be mostly useful for implementing triggers to SIP application servers (according to some criteria, such as IMS IFC), especially in the case of trigerring B2BUAs, in order to correlate both dialogs (the one going to the B2B and the one coming out from the B2B into the SIP proxy again). But this does not require full dialog statefullness. This separation of routing and application is the IMS concept that IMO seems to have some value irrelevant of if you're on a 3GPP network, a TISPAN R1 (DSL) network, or on the Internet. But soon you realise that in order to support this separation and triggering of services, you end up needing some of the extensions to SIP and to the "SIP proxy" that IMS defines. Perhaps these are all too far-fetched use cases for dialog-statefulness to make its way into OpenSER. But the single argument of not having to setup Asterisk in order to be able to control established sessions with OpenSER is IMO quite important for a considerable part of the user community. JF On 7/19/06, Juha Heinanen <jh(a)tutpro.com> wrote: