5 Jul
2005
5 Jul
'05
5:05 p.m.
Hello,
I'm currently working on a VOIP network where the phones register to an
OpenSER server - we also have a PSTN Gateway (Asterisk).
To be able to account the PSTN calls of a user we insert a custom header
"X-Account" which stores information about the user account. We can't
just use the From-Header for this as we allow users to e.g. create
unconditional forwards which forward the call to a defined SIP uri when
the user isn't available. If somebody creates a forward to the PSTN it
is still his account which should be accounted and which is therefor put
in the X-Account header.
This part works fine, but I'm still not sure how to handle call
transfers - e.g. when a user wants to transfer his conversational
partner to the PSTN. An unattended transfer in SIP is implemented with a
REFER request which causes the remote phone to send an INVITE to the SIP
uri in question[1]. I'm not sure how to account these transfers. On a
traditional PSTN network the person who caused the transfer would be the
one who is paying for the call. But I see no solution how to implement
this behaviour in SIP (because the old call isn't transfered, but the
conversational partner starts a new call with the INVITE request).
Is it somehow possible to detect if a call was caused by a transfer so
that I can insert the right X-Account header? Do I need a B2BUA like
Asterisk to implement the traditional behaviour? How do other VOIP
providers solve this problem (IMO call transfers shouldn't be such an
uncommon feature).
tia for all suggestions on how to solve this problem
/gst
[1]
http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-08.…
6 Jul
6 Jul
5:16 a.m.
Hi Günther,
Indeed, accounting the transferred calls may be trick.
A short idea that might help you:
- spy the REFER request and add to the "Refer-to" header's URI a
parameter containing the billing user (usually is FROM URI of the REFER)
- use avpops to do this -> avp_write() to get the from URI into an AVP
and subst() to added the AVP as a Refer-to URI parameter (for example
named "billing".
- look for INVITEs which have in RURI, URI with the "billing"
parameter; if so, move its value to the X-Account header; For this you
need the new avp_subst() function (only in OpenSER 0.10.x)-> the idea
will be like this: move RURI in an AVP (avp_write), extract from the avp
only the param (avp_subst) and push the avp as header (avp_pushto).
not sure if it's correct....just a thought.
regards,
bodgan
Günther Starnberger wrote:
Hello,
I'm currently working on a VOIP network where the phones register to an
OpenSER server - we also have a PSTN Gateway (Asterisk).
To be able to account the PSTN calls of a user we insert a custom header
"X-Account" which stores information about the user account. We can't
just use the From-Header for this as we allow users to e.g. create
unconditional forwards which forward the call to a defined SIP uri when
the user isn't available. If somebody creates a forward to the PSTN it
is still his account which should be accounted and which is therefor put
in the X-Account header.
This part works fine, but I'm still not sure how to handle call
transfers - e.g. when a user wants to transfer his conversational
partner to the PSTN. An unattended transfer in SIP is implemented with a
REFER request which causes the remote phone to send an INVITE to the SIP
uri in question[1]. I'm not sure how to account these transfers. On a
traditional PSTN network the person who caused the transfer would be the
one who is paying for the call. But I see no solution how to implement
this behaviour in SIP (because the old call isn't transfered, but the
conversational partner starts a new call with the INVITE request).
Is it somehow possible to detect if a call was caused by a transfer so
that I can insert the right X-Account header? Do I need a B2BUA like
Asterisk to implement the traditional behaviour? How do other VOIP
providers solve this problem (IMO call transfers shouldn't be such an
uncommon feature).
tia for all suggestions on how to solve this problem
/gst
[1]
http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-08.…
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
"
5:33 a.m.
On Wed, 2005-07-06 at 12:16 +0300, Bogdan-Andrei Iancu wrote:
Hello,
Indeed, accounting the transferred calls may be
trick.
A short idea that might help you:
- spy the REFER request and add to the "Refer-to" header's URI a
parameter containing the billing user (usually is FROM URI of the REFER)
- use avpops to do this -> avp_write() to get the from URI into an AVP
and subst() to added the AVP as a Refer-to URI parameter (for example
named "billing".
- look for INVITEs which have in RURI, URI with the "billing"
parameter; if so, move its value to the X-Account header; For this you
need the new avp_subst() function (only in OpenSER 0.10.x)-> the idea
will be like this: move RURI in an AVP (avp_write), extract from the avp
only the param (avp_subst) and push the avp as header (avp_pushto).
Thanks for the info - I already thought of something similar, but the
downside of this solution is that i would need some kind of
'ticket' (e.g. a random number) which i put into the refer-to header -
otherwise the remote peer would be able to call on someone elses credit
even without a transfer.
Something like the following steps:
* OpenSER gets a REFER and writes a random number together with a
timeout value in the database.
* OpenSER puts this number in the Refer-to header as a parameter
* On an incoming call the number is checked against the database - if it
matches the account of the person wo initiated the transfer is used -
otherwise the account of the person who sent the INVITE is used.
I hoped that there would be a simpler solution for this problem :(
How is this case usually handled in the VOIP world? Are calls just
assigned to the account of the person who sent the invite? Or are
workarounds (either your suggestion or a B2BUA which keeps track of the
calls) common?
cu
/gst
10:58 a.m.
Günther Starnberger wrote:
On Wed, 2005-07-06 at 12:16 +0300, Bogdan-Andrei Iancu
wrote:
Hello,
yes, this is a strong point
Indeed, accounting the transferred calls may be
trick.
A short idea that might help you:
- spy the REFER request and add to the "Refer-to" header's URI a
parameter containing the billing user (usually is FROM URI of the REFER)
- use avpops to do this -> avp_write() to get the from URI into an AVP
and subst() to added the AVP as a Refer-to URI parameter (for example
named "billing".
- look for INVITEs which have in RURI, URI with the "billing"
parameter; if so, move its value to the X-Account header; For this you
need the new avp_subst() function (only in OpenSER 0.10.x)-> the idea
will be like this: move RURI in an AVP (avp_write), extract from the avp
only the param (avp_subst) and push the avp as header (avp_pushto).
Thanks for the info - I already thought of something similar, but the
downside of this solution is that i would need some kind of
'ticket' (e.g. a random number) which i put into the refer-to header -
otherwise the remote peer would be able to call on someone elses credit
even without a transfer.
Something like the following steps:
* OpenSER gets a REFER and writes a random number together with a
timeout value in the database.
* OpenSER puts this number in the Refer-to header as a parameter
* On an incoming call the number is checked against the database - if it
matches the account of the person wo initiated the transfer is used -
otherwise the account of the person who sent the INVITE is used.
I hoped that there would be a simpler solution for this problem :(
a way to simplify it is to relay on acc data: log the REFER with the
FROM, REFER-to hdr (and whatever you find useful). Then, from ACC table,
you can put thing together : A <-> B, A refer to B with refer-to C,
B->C; so A must pai also fo B->C; checkings timestamps will avoid any
doubts.
Maybe using some additional random tokens to re-enforce the correlation
between the two calls will be good.
How is this case usually handled in the VOIP world? Are
calls just
assigned to the account of the person who sent the invite? Or are
workarounds (either your suggestion or a B2BUA which keeps track of the
calls) common?
I don't thing a B2BUA is really required.
regards,
bogdan
7 Jul
7 Jul
5:24 p.m.
On Wed, 2005-07-06 at 17:58 +0300, Bogdan-Andrei Iancu wrote:
hello,
a way to simplify it is to relay on acc data: log the
REFER with the
FROM, REFER-to hdr (and whatever you find useful). Then, from ACC table,
you can put thing together : A <-> B, A refer to B with refer-to C,
B->C; so A must pai also fo B->C; checkings timestamps will avoid any
doubts.
Maybe using some additional random tokens to re-enforce the correlation
between the two calls will be good.
ok - tnx - a random token in combination with the destination and
refer-to hdr seems to be the best solution for this problem. i'll try to
implement such a solution for my network.
cu
/gst
7166
days inactive
7168
days old
4 comments
2 participants
participants (2)
-
Bogdan-Andrei Iancu -
Günther Starnberger