Bogdan-Andrei Iancu wrote:

Hi,

you can use the dialog module to see info about the ongoing calls, but you cannot disconnect them.

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

regards, bogdan

Mark Anthony C. Delfin wrote:

...

Hi List,

Is there a module for .openser/openserctl where I can view active calls and/or disconnect them.

thanks Mark

---

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Klaus Darilion wrote:

Klaus Darilion wrote:

...

Bogdan-Andrei Iancu wrote:

...

Hi,

you can use the dialog module to see info about the ongoing calls, but you cannot disconnect them.

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 forgot about Contact: and Via: Then we would have a B2BUA with topology hiding/anonymization.

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:

there are already some info stored in the dialog structure like callid and from and to uris and tags. of course, in time, this functionality can be added.

regards, bogdan

Klaus Darilion wrote:

...

Bogdan-Andrei Iancu wrote:

...

Hi,

you can use the dialog module to see info about the ongoing calls, but you cannot disconnect them.

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

...

regards, bogdan

Mark Anthony C. Delfin wrote:

...

Hi List,

Is there a module for .openser/openserctl where I can view active calls and/or disconnect them.

thanks Mark

---

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Klaus Darilion writes:

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.

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:

What it still do not like on sems that it reuses parts of (open)ser (fifo communciation ...) - or has this changed?

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:

Is it a "real" B2BUA (2 different dialogs, different call ids/tags on the 2 call legs, no "privacy" data in one leg can be seen in other leg?)

yes it is true b2bua. media goes direct though.

Does it support RTP/RTCP relaying with multiple streams?

no, as i said, it handles only signaling, which to me sounds like a much more scalable idea than relaying also media.

Does it support NAT traversal or is still nathelper+rtpproxy necessary?

you handle nat traversal by openser. sems b2bua does not need to be aware of nat.

Does it work out of the box with openser1.1?

yes.

-- juha

olivier.taylor writes:

where to get the new sems and relative docs?

http://svn.berlios.de/viewcvs/sems/

Does sems have transcoding facilities or it's just pass-tru and doesn't care of media type?

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:

Thanks for the info,

I'm trying to set a small scale prepaid setup using acc and some php scripts, but I cannot disconnect active calls

On 7/18/06, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:

...

Hi,

you can use the dialog module to see info about the ongoing calls, but you cannot disconnect them.

regards, bogdan

Mark Anthony C. Delfin wrote:

...

Hi List,

Is there a module for .openser/openserctl where I can view active calls and/or disconnect them.

thanks Mark

---

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

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:

openser is not dialog stateful. -- juha

forever ?

openser can be stateful Javier

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@tutpro.com wrote:

Javier Ramirez writes:

...

forever ?

not necessarily, but dialog statefulness in the proxy is not necessarily a good idea. for example, there is always a tradeoff between scalability and dialog statefulness. also, if dialog stateful proxy for any reason dies, it is more severe thing than if transaction stateful proxy dies.

-- juha

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

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@tutpro.com wrote:

JF writes:

...

It's not necessarily a bad idea either, it depends on what you want to do with it.

yes, what do you want to do with it? i understand pre-paid pstn service needs to clear too long call, but that would be better handled by pstn gws, not the proxy.

-- juha

inline

On 7/18/06, Juha Heinanen jh@tutpro.com wrote:

JF writes:

...

You can have pre-paid SIP services without PSTN.

why? i don't understand how anyone would subscribe to such a service. how many email services you know that charge by the volume of email messages sent?

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.

...

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.

3gpp uses "SIP" to implement a walled garden. again, i have seen very little interest for it in user community. they simply use their nokia e series phones as regular rfc3261 compliant phones, not 3gpp phones.

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

-- juha

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@tutpro.com wrote:

JF writes:

...

SIP-IPTV perhaps. Why would PSTN calls be the only motivation for people to pay?

fine, but why should sip proxy be responsible for terminating the ip-tv session when money runs out? why doesn't ip-tv service (sip ua that corresponds to pstn gw) do it?

-- juha