Hello,
are you proxying the media stream all the time now? Or just when the one of the party is behind the nat? I have in mynd the sceanrio when the initial callee is behind nat, it sends back redirect, and the new destination is public...
Cheers, Daniel
On 01/12/07 14:36, Howard Tang wrote:
Hi Daniel,
Thank you very much, the problem fixed.
Regards, Howard
On 1/11/07, Daniel-Constantin Mierla daniel@voice-system.ro wrote:
Hello,
as i see in your failure route you close mediaproxy nat handling -- try to keep it on. ALso, the contacts in redirect message might be natted even when initial destination wasn't -- you have to deal with this case as well (start nat handling).
Cheers, Daniel
On 01/09/07 14:23, Howard Tang wrote:
Hi Daniel,
by using the following code in the failure_route block, i am able to have a better accounting record for billing. However, i am having one way audio problem which i believe it is related to NAT. I have tested forward a call on a UA which is on public ip, which works prefectly. However, when i tested it with UA which is behind NAT, one way audio happen when the UA send 302 reply to forward a call..
failure_route[1] { end_media_session(); # Handle 302 Redirects if (t_check_status("302")) { get_redirects("*"); t_relay(); }; }
Anyone has an idea on how i can fix this?
Regards, Howard
On 1/9/07, Daniel-Constantin Mierla daniel@voice-system.ro wrote:
Hello,
when the call A -> B is forwarded to C, then you need to have in your script:
avp_write("A", "$avp(i:110)"); avp_write("B", "$avp(i:111)"); avp_write("B", "$avp(i:110)"); avp_write("C", "$avp(i:111)");
A, B, C are the SIP addresses of the parties involved in this call.
Cheers, Daniel
On 01/08/07 23:14, Howard Tang wrote:
Hi,
Did anyone successfully setup call accounting for call forward?
I have
been searching for a working example for few days on google, I
still
couldn't find any working example.
The config I have at the moment is
modparam("acc", "multi_leg_enabled", 1) modparam("acc", "src_leg_avp_id", 110) modparam("acc", "dst_leg_avp_id", 111)
In the main route, if (!method=="REGISTER" && !method=="NOTIFY") { avp_write("$from/username", "$avp(i:110)"); avp_write("$ruri/username", "$avp(i:111)"); };
Let say A call B and B forward call to C, the record in the acc
table
is all A to C without B in any one of the record for billing purpose. The Call forward was set on the UA.
Can anyone give me a hand on this please?
Hi Daniel,
I think i have configurated to have proxyed the media stream when one of the party is behind the nat.
I was having problem before i removed the end_media_session in the failure_route[1], when i call from pstn to ua behind nat and ua forward a call back to another pstn number, after the call forwarded, no audio.
Now i have removed the end_media_session in the failure_route[1], everything works well.
But i found another problem just now about call accounting on transferred call. On my Desktop sip phone, there is a transfer button which allow me to transfer the current call to a different users/pstn number.
(B called A, which B talking to A, B transferred the phoen to C) In the accounting table, i can see something in following
B@1.1.1.1 A@1.1.1.1 Invite 200 B@1.1.1.1 A@1.1.1.1 ACK 200 B@1.1.1.1 A@1.1.1.1 REFER 200 B@1.1.1.1 A@1.1.1.1 NOTIFY 200 B@1.1.1.1 C@1.1.1.1 Invite 200 B@1.1.1.1 C@1.1.1.1 ACK 200 B@1.1.1.1 C@1.1.1.1 BYE 200
I would like to see if there a way to have a proper accounting for this function. If it is too hard to do, i may jsut want a solution to block user transfering the call.
I am not good at programming, if you can provide me a example, that will be good.
Regards, Howard
On 1/15/07, Daniel-Constantin Mierla daniel@voice-system.ro wrote:
Hello,
are you proxying the media stream all the time now? Or just when the one of the party is behind the nat? I have in mynd the sceanrio when the initial callee is behind nat, it sends back redirect, and the new destination is public...
Cheers, Daniel
On 01/12/07 14:36, Howard Tang wrote:
Hi Daniel,
Thank you very much, the problem fixed.
Regards, Howard
On 1/11/07, Daniel-Constantin Mierla daniel@voice-system.ro wrote:
Hello,
as i see in your failure route you close mediaproxy nat handling -- try to keep it on. ALso, the contacts in redirect message might be natted even when initial destination wasn't -- you have to deal with this case as well (start nat handling).
Cheers, Daniel
On 01/09/07 14:23, Howard Tang wrote:
Hi Daniel,
by using the following code in the failure_route block, i am able to have a better accounting record for billing. However, i am having one way audio problem which i believe it is related to NAT. I have tested forward a call on a UA which is on public ip, which works prefectly. However, when i tested it with UA which is behind NAT, one way audio happen when the UA send 302 reply to forward a call..
failure_route[1] { end_media_session(); # Handle 302 Redirects if (t_check_status("302")) { get_redirects("*"); t_relay(); }; }
Anyone has an idea on how i can fix this?
Regards, Howard
On 1/9/07, Daniel-Constantin Mierla daniel@voice-system.ro wrote:
Hello,
when the call A -> B is forwarded to C, then you need to have in your script:
avp_write("A", "$avp(i:110)"); avp_write("B", "$avp(i:111)"); avp_write("B", "$avp(i:110)"); avp_write("C", "$avp(i:111)");
A, B, C are the SIP addresses of the parties involved in this call.
Cheers, Daniel
On 01/08/07 23:14, Howard Tang wrote:
Hi,
Did anyone successfully setup call accounting for call forward?
I have
been searching for a working example for few days on google, I
still
couldn't find any working example.
The config I have at the moment is
modparam("acc", "multi_leg_enabled", 1) modparam("acc", "src_leg_avp_id", 110) modparam("acc", "dst_leg_avp_id", 111)
In the main route, if (!method=="REGISTER" && !method=="NOTIFY") { avp_write("$from/username", "$avp(i:110)"); avp_write("$ruri/username", "$avp(i:111)"); };
Let say A call B and B forward call to C, the record in the acc
table
is all A to C without B in any one of the record for billing purpose. The Call forward was set on the UA.
Can anyone give me a hand on this please?