Hello everyone,
I am using the onsip call features ser.cfg and am adapting it for asterisk voicemail. This is what I currently have changed:
1) In the usr_preferences table in the ser database have an entry for user 2092.
Insert into usr_preferences (username, attribute, value) values ("2092", "voicemail", "y");
2) In Route[3] (used for call invite handling)
if(avp_db_load("$ruri/username","s:voicemail")){ if(avp_check("s:voicemail", "eq/y/i")){ setflag(18); }; };
This will check if the user wants to use voicemail according to the preference that is set for them in the usr_preferences table. I they don't want to use voicemail set value to "n"
3) In failure route[1]
if (call fwd on no answer is enabled{
} else if(isflagset(18) && t_check_status("408")){ route(x); break; };
4) route[x]
{ acc_db_request("missed called", "missed_calls"); revert_uri(); rewritehostport("x.x.x.x:5064"); #port where asterisk is listening append_branch(); t_relay_to_udp(x.x.x.x", "5064"); break(); }
I am getting a 404 sent back to the phone..I suspect this is something got to do with route 1 as I have used loads of log messages and I can see the flag being set, route x being called but after the failure route, the code jumps to route 1...This is probably because in route 3 it says t_on_failure("1") followed by route 4 followed by route 1...I just don't know what to do about it....Does anyone have any suggestions?
Kindest Regards, Aisling.
-------------------Legal Disclaimer---------------------------------------
The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.
Aisling, I think the only way you can get further on this is to use ngrep and create a complete trace of the call. Then you have to match each of your log messages to each SIP message. sip_scenario can help you in drawing out who sent what. Remember that once you relay to Asterisk, Asterisk will get in the loop and these messages should also be relayed properly. My guess is that this has something to do with the OK or ACK at the end of call. Most likely you forget about a SIP message when reading your logs... ;-) (I've done it myself so many times) g-) ----- Original Message ----- From: Aisling To: serusers@lists.iptel.org Sent: Monday, October 03, 2005 09:05 PM Subject: [Serusers] voicemail route
Hello everyone,
I am using the onsip call features ser.cfg and am adapting it for asterisk voicemail. This is what I currently have changed:
1) In the usr_preferences table in the ser database have an entry for
user 2092.
Insert into usr_preferences (username, attribute, value) values
("2092", "voicemail", "y");
2) In Route[3] (used for call invite handling)
if(avp_db_load("$ruri/username","s:voicemail")){
if(avp_check("s:voicemail", "eq/y/i")){
setflag(18);
};
};
This will check if the user wants to use voicemail according to the
preference that is set for them in the usr_preferences table. I they
don't want to use voicemail set value to "n"
3) In failure route[1]
if (call fwd on no answer is enabled{
} else if(isflagset(18) && t_check_status("408")){
route(x);
break;
};
4) route[x]
{
acc_db_request("missed called", "missed_calls"); revert_uri();
rewritehostport("x.x.x.x:5064"); #port where asterisk is listening
append_branch();
t_relay_to_udp(x.x.x.x", "5064");
break();
}
I am getting a 404 sent back to the phone..I suspect this is something got to do with route 1 as I have used loads of log messages and I can see the flag being set, route x being called but after the failure route, the code jumps to route 1...This is probably because in route 3 it says t_on_failure("1") followed by route 4 followed by route 1...I just don't know what to do about it....Does anyone have any suggestions?
Kindest Regards,
Aisling.
-------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.
------------------------------------------------------------------------------
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Ok Greger, thanks for the reply.
Just a quick question, for the forward to voicemail on busy scenario, I can see the callee phone sending the 486 busy message to SER and SER sends an ACK back. At this stage I then see SER send a 404 to the caller.I presume the correct sequence instead for this would be SER forwarding the INVITE to Asterisk?
Many thanks.
-----Original Message----- From: Greger V. Teigre [mailto:greger@teigre.com] Sent: 04 October 2005 06:55 To: Aisling; serusers@lists.iptel.org Subject: Re: [Serusers] voicemail route
Aisling, I think the only way you can get further on this is to use ngrep and create a complete trace of the call. Then you have to match each of your log messages to each SIP message. sip_scenario can help you in drawing out who sent what. Remember that once you relay to Asterisk, Asterisk will get in the loop and these messages should also be relayed properly. My guess is that this has something to do with the OK or ACK at the end of call. Most likely you forget about a SIP message when reading your logs... ;-) (I've done it myself so many times) g-) ----- Original Message ----- From: Aisling mailto:ashling.odriscoll@cit.ie To: serusers@lists.iptel.org Sent: Monday, October 03, 2005 09:05 PM Subject: [Serusers] voicemail route
Hello everyone,
I am using the onsip call features ser.cfg and am adapting it for asterisk voicemail. This is what I currently have changed:
1) In the usr_preferences table in the ser database have an entry for user 2092.
Insert into usr_preferences (username, attribute, value) values ("2092", "voicemail", "y");
2) In Route[3] (used for call invite handling)
if(avp_db_load("$ruri/username","s:voicemail")){ if(avp_check("s:voicemail", "eq/y/i")){ setflag(18); }; };
This will check if the user wants to use voicemail according to the preference that is set for them in the usr_preferences table. I they don't want to use voicemail set value to "n"
3) In failure route[1]
if (call fwd on no answer is enabled{
} else if(isflagset(18) && t_check_status("408")){ route(x); break; };
4) route[x]
{ acc_db_request("missed called", "missed_calls"); revert_uri(); rewritehostport("x.x.x.x:5064"); #port where asterisk is listening append_branch(); t_relay_to_udp(x.x.x.x", "5064"); break(); }
I am getting a 404 sent back to the phone..I suspect this is something got to do with route 1 as I have used loads of log messages and I can see the flag being set, route x being called but after the failure route, the code jumps to route 1...This is probably because in route 3 it says t_on_failure("1") followed by route 4 followed by route 1...I just don't know what to do about it....Does anyone have any suggestions?
Kindest Regards, Aisling. -------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.
_____
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers -------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.
-------------------Legal Disclaimer---------------------------------------
The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.
if ser is sending you the 404, then what is asterisk sending ser
what I normally do is sip debug on asterisk and print it out, then ngrep on ser also...or just ngrep both paths, and draw it out sip_scenario is good, but a bit OTT sometimes
Iqbal
Greger V. Teigre wrote:
Aisling, I think the only way you can get further on this is to use ngrep and create a complete trace of the call. Then you have to match each of your log messages to each SIP message. sip_scenario can help you in drawing out who sent what. Remember that once you relay to Asterisk, Asterisk will get in the loop and these messages should also be relayed properly. My guess is that this has something to do with the OK or ACK at the end of call. Most likely you forget about a SIP message when reading your logs... ;-) (I've done it myself so many times) g-)
----- Original Message ----- *From:* Aisling <mailto:ashling.odriscoll@cit.ie> *To:* serusers@lists.iptel.org <mailto:serusers@lists.iptel.org> *Sent:* Monday, October 03, 2005 09:05 PM *Subject:* [Serusers] voicemail route Hello everyone, I am using the onsip call features ser.cfg and am adapting it for asterisk voicemail. This is what I currently have changed: 1) In the usr_preferences table in the ser database have an entry for user 2092. Insert into usr_preferences (username, attribute, value) values ("2092", "voicemail", "y"); 2) In Route[3] (used for call invite handling) if(avp_db_load("$ruri/username","s:voicemail")){ if(avp_check("s:voicemail", "eq/y/i")){ setflag(18); }; }; This will check if the user wants to use voicemail according to the preference that is set for them in the usr_preferences table. I they don't want to use voicemail set value to "n" 3) In failure route[1] if (call fwd on no answer is enabled{ } else if(isflagset(18) && t_check_status("408")){ route(x); break; }; 4) route[x] { acc_db_request("missed called", "missed_calls"); revert_uri(); rewritehostport("x.x.x.x:5064"); #port where asterisk is listening append_branch(); t_relay_to_udp(x.x.x.x", "5064"); break(); } I am getting a 404 sent back to the phone….I suspect this is something got to do with route 1 as I have used loads of log messages and I can see the flag being set, route x being called but after the failure route, the code jumps to route 1…….This is probably because in route 3 it says t_on_failure(“1”) followed by route 4 followed by route 1…..I just don’t know what to do about it…………Does anyone have any suggestions? Kindest Regards, Aisling. -------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt. ------------------------------------------------------------------------ _______________________________________________ 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
Hi Iqbal,
Asterisk is not sending ser anything because nothing is reaching asterisk. I have used sip debug but no sip messages are received by asterisk. Asterisk and ser are one the same machine with ser on port 5060 and asterisk on 5064.
Therefore it is SER sending the 404. The call scenario is as follows:
314 (caller) SER 2092(callee) INVITE -> <- 407 ACK -> INVITE -> <- 100 INVITE -> <- 100 <- 486 Busy ACK -> <- 404 ACK ->
The t_relay_to_udp mustn't be working to forward to asterisk....Then route 1 is invoked.....
Aisling.
-----Original Message----- From: Iqbal [mailto:iqbal@gigo.co.uk] Sent: 04 October 2005 12:02 To: Greger V. Teigre Cc: Aisling; serusers@lists.iptel.org Subject: Re: [Serusers] voicemail route
if ser is sending you the 404, then what is asterisk sending ser
what I normally do is sip debug on asterisk and print it out, then ngrep
on ser also...or just ngrep both paths, and draw it out sip_scenario is good, but a bit OTT sometimes
Iqbal
Greger V. Teigre wrote:
Aisling, I think the only way you can get further on this is to use ngrep and create a complete trace of the call. Then you have to match each of your log messages to each SIP message. sip_scenario can help you in drawing out who sent what. Remember that once you relay to Asterisk, Asterisk will get in the loop and these messages should also be relayed properly. My guess is that this has something to do with the OK or ACK at the end of call. Most likely you forget about a SIP message when reading your logs... ;-) (I've done it myself so many
times)
g-)
----- Original Message ----- *From:* Aisling <mailto:ashling.odriscoll@cit.ie> *To:* serusers@lists.iptel.org <mailto:serusers@lists.iptel.org> *Sent:* Monday, October 03, 2005 09:05 PM *Subject:* [Serusers] voicemail route Hello everyone, I am using the onsip call features ser.cfg and am adapting it for asterisk voicemail. This is what I currently have changed: 1) In the usr_preferences table in the ser database have an entry
for
user 2092. Insert into usr_preferences (username, attribute, value) values ("2092", "voicemail", "y"); 2) In Route[3] (used for call invite handling) if(avp_db_load("$ruri/username","s:voicemail")){ if(avp_check("s:voicemail", "eq/y/i")){ setflag(18); }; }; This will check if the user wants to use voicemail according to
the
preference that is set for them in the usr_preferences table. I
they
don't want to use voicemail set value to "n" 3) In failure route[1] if (call fwd on no answer is enabled{ } else if(isflagset(18) && t_check_status("408")){ route(x); break; }; 4) route[x] { acc_db_request("missed called", "missed_calls"); revert_uri(); rewritehostport("x.x.x.x:5064"); #port where asterisk is listening append_branch(); t_relay_to_udp(x.x.x.x", "5064"); break(); } I am getting a 404 sent back to the phone..I suspect this is something got to do with route 1 as I have used loads of log messages and I can see the flag being set, route x being called but after the failure route, the code jumps to route 1...This is probably because in route 3 it says t_on_failure("1") followed by route 4 followed by route 1...I just don't know what to do about it....Does anyone have any suggestions? Kindest Regards, Aisling. -------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.
------------------------------------------------------------------------
_______________________________________________ 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
-------------------Legal Disclaimer---------------------------------------
The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.
-------------------Legal Disclaimer---------------------------------------
The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.
-
Aisling -
Greger V. Teigre -
Iqbal