Hello,
welcome to the world of SIP, where the end devices are supposed to be the intelligent network, not the network itself.
To really make this and other features ISDN-like features work in the network, one needs a b2bua somewhere.
A---SER---B2BUA---SER---B C---^ ^accounting SER
A calls from PSTN, B2BUA receives the call, sends INVITE to B B sends 302 to B2BUA. B2BUA sends INVITE in the name of B to C.
Regards, Martin
-----Original Message----- From: serusers-bounces@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Atle Samuelsen Sent: Wednesday, December 22, 2004 9:40 AM To: Richard Cc: serusers@lists.iptel.org Subject: Re: [Serusers] call log and accounting for forwarded and referredcalls
At the moment SER does'nt do recursion on 302. If ser had done this, The world would be a bether place for all us. Anyhow. in a A-B-C-D scenario.. A should pay to B, B to C and C to D.
-Atle
- Richard richard@o-matrix.org [041222 09:04]:
-----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com] Sent: Tuesday, December 21, 2004 9:25 PM To: Richard Cc: serusers@lists.iptel.org Subject: [Serusers] call log and accounting for forwarded
and referred
calls
Richard writes:
When a SIP call is blind-transferred with REFER and
forwarded with "302
moved temporarily", UA would start a brand new call.
The problem is how
to
log and account for their calls. For example, A calls
B, B sends 302
and
uses C's number as contact. The new call is made from
A to C. The call
log
would show it is from A to C. The call log should at
least have an
indication of B forwarding the call. Also B is
supposed to pay the
bill.
It
is not A although the call log shows it is A to C. A
has no knowledge
that a
toll call is made when calling B.
richard,
i disagree that in case of 302, b should pay the bill.
302 means "b has
moved to c and it is up to you if you want to try this new uri".
if you want b to pay the bill, then b should configure
ser to FORWARD
the call to c, not to REDIRECT a to c.
The issue is that A has no choice to be forwarded or not.
When a 302 is
received by A, there is no option for A to continue or
reject the call. In
this example, B (an IP phone) sets his phone forwarding to
C which is a long
distance number. A is from PSTN. When A makes a call to B,
B sends 302 to
the PSTN gateway. The gateway forwards the call to ser
which routes it back
to C via the PSTN gatway. So in ser's call log, I see a
call from A to C.
Apparently I can't charge A or C. Only B is in my domain.
But B is not even
in the second call log. In my understanding, if B sets the
forward setting
on his phone to a toll number, he should be the one paying the bill.
This also applies even if A is in my domain.
Cheers, Richard
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Martin Koenig writes:
To really make this and other features ISDN-like features work in the network, one needs a b2bua somewhere.
no you don't. ser can quite easily be made to turn the 302 to an another invite, where b is listed as caller in rpid or diversion header.
but as i have said many times already, this would violate the called party's right to tell to the calling party where he can be reached IF the calling party wishes to try that other destination.
-- juha
Hello,
To really make this and other features ISDN-like features
work in the
network, one needs a b2bua somewhere.
no you don't. ser can quite easily be made to turn the 302 to an another invite, where b is listed as caller in rpid or diversion header.
Could you please elaborate further how to enable this feature?
but as i have said many times already, this would violate the called party's right to tell to the calling party where he can be reached IF the calling party wishes to try that other destination.
That's why i said ISDN-like features. If the final call destination (f.e. a cellphone number) should not be revealed to the caller, then a b2bua is nessecary. Or to put it different: What about the called party's right to deflect calls to any possible destination without further interaction with the caller.
Best regards, Martin
Martin Koenig writes:
no you don't. ser can quite easily be made to turn the 302 to an another invite, where b is listed as caller in rpid or diversion header.
Could you please elaborate further how to enable this feature?
you write a reply route function where you take the uri(s) from the contact header and add them as new branches to the request.
That's why i said ISDN-like features. If the final call destination (f.e. a cellphone number) should not be revealed to the caller, then a b2bua is nessecary.
yes.
Or to put it different: What about the called party's right to deflect calls to any possible destination without further interaction with the caller.
that the called party can be easily done by making ser to FORWARD, not redirect the call.
-- juha
Hello,
Or to put it different: What about the called party's right to deflect calls to any possible destination without further
interaction with
the caller.
that the called party can be easily done by making ser to FORWARD, not redirect the call.
D'accord. Use lookup("aliases") or similar.
Regards, Martin
no you don't. ser can quite easily be made to turn the 302 to an another invite, where b is listed as caller in rpid or diversion header.
How do you turn 302 to an INVITE in ser?
I made simple function to avp.c with a new function called contact2attr and put it in the reply_route. Then in failure route just using attr2uri, append_branch, and relaying the new invite again (ofcourse adding diversion header first so guy would be billed).
Jens Davidsen
How do you turn 302 to an INVITE in ser?
I made simple function to avp.c with a new function called contact2attr and put it in the reply_route. Then in failure route just using attr2uri, append_branch, and relaying the new invite again (ofcourse adding diversion header first so guy would be billed).
That sounds a good plan. So this whole process is transparent to the caller. Does ser support diversion on accounting? The acc table doesn't have such a field.
Another thing is for REFER. If the referred-by field is filled properly in the new INVITE by the caller, we can use this for accounting. Again the same issue is how to add this into acc table.
Thanks, Richard
At 11:36 PM 12/22/2004, Richard wrote:
no you don't. ser can quite easily be made to turn the 302 to an another invite, where b is listed as caller in rpid or diversion header.
How do you turn 302 to an INVITE in ser?
http://www.iptel.org/ser/doc/seruser/seruser.html#REDIRECTSERVER
-jiri
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
-
Jens Davidsen -
Jiri Kuthan -
Juha Heinanen -
Martin Koenig -
Richard