[OpenSIPS-Users] multi-leg accounting in case of redirect

Ruchir ruchir.lists at gmail.com
Thu Aug 21 13:29:58 CEST 2008


Oh I see. Then how we can get correct leg source, leg destination &
forwarding reason?

On Thu, Aug 21, 2008 at 3:50 PM, Bogdan-Andrei Iancu <bogdan at voice-system.ro
> wrote:

> Hi Ruchir,
>
> I see in the onreply_route you get the diversion type (src_user_reply).
> Also you try to populate the src avp, but as in onreply_route a reply is
> processed, the $rU will not work - there is no RURI in a reply.
>
> Regards,
> Bogdan
>
> Ruchir wrote:
>
>> I'm populating it from onreply route. Below is my onreply route.
>> if($hdr(Diversion)!=null)
>>    {
>>        avp_delete("$avp(s:src_user_reply)");
>>        $avp(s:src_user_reply) = $hdr(Diversion);
>>        xlog("Client call forwarding to $avp(s:src_user_reply)\n ");
>>        avp_subst("$avp(s:src_user_reply)",
>> "/(.*)<sip:(.*)@(.*)>;reason=(.*)/\4/");
>>        $avp(s:src) = $rU;
>>        switch($avp(s:src_user_reply))
>>        {
>>            case "unconditional":
>>                $avp(s:call_type) = "cwfd";
>>                break;
>>            case "user-busy":
>>                $avp(s:call_type) = "cwfdbusy";
>>                break;
>>            case "no-answer":
>>                $avp(s:call_type) = "cwfdnoanswer";
>>                break;
>>            default:
>>                log("no forwarding\n");
>>        }
>>        xlog("FORWARDING REASON: $avp(s:call_type) \n ");
>>
>>    }
>>
>> On Tue, Aug 19, 2008 at 5:49 PM, Bogdan-Andrei Iancu <
>> bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> wrote:
>>
>>    Hi Ruchir,
>>
>>    I see in failure route you are using route[1] to do the job if a
>>    redirect happens. How exactly are you populating in the second set
>>    of caller/callee in route[1] ?
>>
>>    Regards,
>>    Bogdan
>>
>>    Ruchir wrote:
>>
>>        Here it is. route[1] is relay route.
>>
>>           failure_route[1]
>>           {
>>               xlog("------- failure_route[1] ----- \n ");
>>               t_on_branch("1");
>>
>>               if(t_check_status("302"))
>>               {
>>                   xlog("------- t_check_status(302) ----- \n ");
>>                             get_redirects("4:1","Redirected");
>>                   route(1);
>>               }                 if( t_check_status("486") &&
>> isbflagset(17))
>>               {
>>                   xlog("------- t_check_status(486) -- isflagset(17)
>>        -----
>>           \n ");
>>                           end_media_session();
>>                   #resetbflag(6);
>>                   append_hf("SRC-USER: $rU\r\n");
>>                   if(avp_pushto("$ruri","$avp(s:cfwdbusy)"))
>>                   {
>>                       append_hf("SRC-CALL-TYPE: cfwdbusy\r\n");
>>                       append_hf("CFWD: YES\r\n");
>>                       avp_delete("$avp(s:cfwdbusy)");
>>                       resetbflag(17);
>>                       append_branch();
>>                       append_hf("PREV_STATUS: $T_reply_code\r\n");
>>                       #route(5);
>>                       $avp(i:120) = $avp(s:inv_timeout);
>>                       route(1);
>>                       exit;
>>                   }
>>               }                    if( t_check_status("408") &&
>>        isbflagset(18))
>>               {
>>                   xlog("------- t_check_status(408) -- isflagset(18)
>>        -----
>>           \n ");
>>
>>                           end_media_session();
>>                   #resetbflag(6);
>>                   append_hf("SRC-USER: $rU\r\n");
>>
>>                           if(avp_pushto("$ruri","$avp(s:cfwdnoanswer)"))
>>                           {
>>                       append_hf("SRC-CALL-TYPE: cfwdnoanswer\r\n");
>>                       append_hf("CFWD: YES\r\n");
>>                       avp_delete("$avp(s:cfwdnoanswer)");
>>                                   resetbflag(18);
>>                                   append_branch();
>>                       append_hf("PREV_STATUS: $T_reply_code\r\n");
>>                       route(5);
>>                       $avp(i:120) = $avp(s:inv_timeout);
>>                       route(1);
>>                       exit;
>>
>>                           }
>>                           else if(isbflagset(4))
>>                   {
>>                       xlog("------- t_check_status(408) -- Voicemail
>>        -----
>>           \n ");
>>
>> if(!t_write_unix("/tmp/sems_sock","voicemail/voicemail_headers"))
>>                           {
>>                               xlog("----------------- Error--- not
>>           communicating----------- \n ");
>>                               exit;
>>                           }
>>                       exit;
>>                   }
>>                   }
>>
>>                     }
>>
>>
>>        On Mon, Aug 11, 2008 at 2:07 AM, Bogdan-Andrei Iancu
>>        <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>
>>        <mailto:bogdan at voice-system.ro
>>        <mailto:bogdan at voice-system.ro>>> wrote:
>>
>>           Could you post your complete failure route (if not a
>>        secret;) ) ?
>>
>>           Regards,
>>           Bogdan
>>
>>
>>           Ruchir wrote:
>>
>>               Yes. I've used uac_redirect module and I'm using
>>                get_redirects function to load the contacts to
>>        redirect to.
>>
>>               On Sun, Aug 10, 2008 at 4:02 PM, Bogdan-Andrei Iancu
>>               <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>
>>        <mailto:bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>>
>>               <mailto:bogdan at voice-system.ro
>>        <mailto:bogdan at voice-system.ro>
>>               <mailto:bogdan at voice-system.ro
>>        <mailto:bogdan at voice-system.ro>>>> wrote:
>>
>>                  Hi Ruchir,
>>
>>                  Are you using uac_redirect module to process the 3xx
>>        replies on
>>                  server?
>>
>>                  Regards,
>>                  Bogdan
>>
>>                  Ruchir wrote:
>>
>>                      Yes. I've set unconditional forwarding in
>>        linksys pap2.
>>               So it
>>                      sends "302 temporarily moved".
>>
>>                      On Sat, Aug 9, 2008 at 4:36 PM, Bogdan-Andrei Iancu
>>                      <bogdan at voice-system.ro
>>        <mailto:bogdan at voice-system.ro> <mailto:bogdan at voice-system.ro
>>        <mailto:bogdan at voice-system.ro>>
>>               <mailto:bogdan at voice-system.ro
>>        <mailto:bogdan at voice-system.ro> <mailto:bogdan at voice-system.ro
>>        <mailto:bogdan at voice-system.ro>>>
>>                      <mailto:bogdan at voice-system.ro
>>        <mailto:bogdan at voice-system.ro>
>>               <mailto:bogdan at voice-system.ro
>>        <mailto:bogdan at voice-system.ro>>
>>                      <mailto:bogdan at voice-system.ro
>>        <mailto:bogdan at voice-system.ro>
>>               <mailto:bogdan at voice-system.ro
>>        <mailto:bogdan at voice-system.ro>>>>> wrote:
>>
>>                         Hi Ruchir,
>>
>>                         The redirect on the phone is done via the 3xx
>>        replies?
>>
>>                         Regards,
>>                         Bogdan
>>
>>                         Ruchir wrote:
>>
>>                             I've set avp and radius_extra param
>>        properly. If I
>>                      handle call
>>                             forwarding from server side, everything works
>>               fine. I
>>                      get leg
>>                             source, destination, forward reason, etc.
>>               perfectly. The
>>                             problem is there only when I do call
>>        forwarding
>>               from phone.
>>
>>                             On Fri, Aug 8, 2008 at 8:08 PM, Pablo
>>        Hernan Saro
>>                             <pablosaro at gmail.com
>>        <mailto:pablosaro at gmail.com>
>>               <mailto:pablosaro at gmail.com
>>        <mailto:pablosaro at gmail.com>> <mailto:pablosaro at gmail.com
>>        <mailto:pablosaro at gmail.com>
>>               <mailto:pablosaro at gmail.com <mailto:pablosaro at gmail.com>>>
>>                      <mailto:pablosaro at gmail.com
>>        <mailto:pablosaro at gmail.com>
>>               <mailto:pablosaro at gmail.com
>>        <mailto:pablosaro at gmail.com>> <mailto:pablosaro at gmail.com
>>        <mailto:pablosaro at gmail.com>
>>               <mailto:pablosaro at gmail.com <mailto:pablosaro at gmail.com>>>>
>>                             <mailto:pablosaro at gmail.com
>>        <mailto:pablosaro at gmail.com>
>>               <mailto:pablosaro at gmail.com <mailto:pablosaro at gmail.com>>
>>                      <mailto:pablosaro at gmail.com
>>        <mailto:pablosaro at gmail.com>
>>               <mailto:pablosaro at gmail.com
>>        <mailto:pablosaro at gmail.com>>> <mailto:pablosaro at gmail.com
>>        <mailto:pablosaro at gmail.com>
>>               <mailto:pablosaro at gmail.com <mailto:pablosaro at gmail.com>>
>>                      <mailto:pablosaro at gmail.com
>>        <mailto:pablosaro at gmail.com>
>>               <mailto:pablosaro at gmail.com
>>        <mailto:pablosaro at gmail.com>>>>>> wrote:
>>
>>                                I believe that it's not about how
>>        OpenSER or
>>               OpenSIPS
>>                             implements
>>                                multi-leg accounting, it's about how
>>        you do.
>>                                Particularly how you set up two important
>>               parameters for
>>                             the acc
>>                                module: multi_leg_info and db_extra. In my
>>               case, I
>>                      set up
>>                             one avp
>>                                for source leg, another for
>>        destination leg
>>               and two avps
>>                             for extra
>>                                information: the state of the call and a
>>                      classification of
>>                             the dst.
>>                                The "state of the call", for me, means
>>        when
>>               it's a
>>                      call, a
>>                             fw or
>>                                whatever; while the "classification of
>>        the dst"
>>                      means if dst is
>>                                national, long distance, international.
>>                                So, you have to set up avps as the
>>               information you
>>                      need and
>>                             make
>>                                sure to set it to proper values before the
>>               acc module
>>                             writes the
>>                                row in your db.
>>                                BTW, take care of using Diversion
>>        header...
>>               It's a draft
>>                             from 2004
>>                                and it's expired. Not all UAC/UAS has this
>>               implemented.
>>                                I hope it helps.
>>                                Cheers
>>
>>                                Pablo
>>
>>
>>                                On Fri, Aug 8, 2008 at 4:05 AM, Ruchir
>>                             <ruchir.lists at gmail.com
>>        <mailto:ruchir.lists at gmail.com>
>>               <mailto:ruchir.lists at gmail.com
>>        <mailto:ruchir.lists at gmail.com>>
>>        <mailto:ruchir.lists at gmail.com <mailto:ruchir.lists at gmail.com>
>>               <mailto:ruchir.lists at gmail.com
>>        <mailto:ruchir.lists at gmail.com>>>
>>                      <mailto:ruchir.lists at gmail.com
>>        <mailto:ruchir.lists at gmail.com>
>>               <mailto:ruchir.lists at gmail.com
>>        <mailto:ruchir.lists at gmail.com>>
>>        <mailto:ruchir.lists at gmail.com <mailto:ruchir.lists at gmail.com>
>>               <mailto:ruchir.lists at gmail.com
>>        <mailto:ruchir.lists at gmail.com>>>>
>>                                <mailto:ruchir.lists at gmail.com
>>        <mailto:ruchir.lists at gmail.com>
>>               <mailto:ruchir.lists at gmail.com
>>        <mailto:ruchir.lists at gmail.com>>
>>                      <mailto:ruchir.lists at gmail.com
>>        <mailto:ruchir.lists at gmail.com>
>>               <mailto:ruchir.lists at gmail.com
>>        <mailto:ruchir.lists at gmail.com>>>
>>                             <mailto:ruchir.lists at gmail.com
>>        <mailto:ruchir.lists at gmail.com>
>>               <mailto:ruchir.lists at gmail.com
>>        <mailto:ruchir.lists at gmail.com>>
>>                      <mailto:ruchir.lists at gmail.com
>>        <mailto:ruchir.lists at gmail.com>
>>               <mailto:ruchir.lists at gmail.com
>>        <mailto:ruchir.lists at gmail.com>>>>>> wrote:
>>
>>                                    I'm using uac_redirect module to
>>        handle
>>               redirect
>>                      from
>>                             UA and
>>                                    doing accounting from openser.
>>        Redirect works
>>                      fine so
>>                             as cdr
>>                                    but I'm not able to store CDR
>>        records for
>>               multi-leg
>>                             accounting
>>                                    properly.
>>
>>                                    I have set onreply avp by
>>
>>                                        modparam("tm",
>>        "onreply_avp_mode", 1)
>>
>>
>>                                    I've set following in onreply route
>>
>>
>>                                        if($hdr(Diversion)!=null)
>>                                        {
>>
>>  avp_delete("$avp(s:src_call_type)");
>>                                        $avp(s:src_call_type) =
>>        $hdr(Diversion);
>>
>>                                        xlog("Client call forwarding to
>>                             $avp(s:src_user_reply)\n ");
>>
>>
>>  avp_subst("$avp(s:src_user_reply)",
>>
>>  "/(.*)<sip:(.*)@(.*)>;reason=(.*)/\4/");
>>
>>
>>
>>                                        switch($avp(s:src_call_type))
>>                                        {
>>                                        case "unconditional":
>>                                        $avp(s:call_type) = "cwfd";
>>                                        break;
>>                                        case "user-busy":
>>                                        $avp(s:call_type) = "cwfdbusy";
>>                                        break;
>>                                        case "no-answer":
>>                                        $avp(s:call_type) =
>>        "cwfdnoanswer";
>>                                        break;
>>                                        default:
>>                                        log("no forwarding\n");
>>                                        }
>>
>>                                        }
>>
>>                                    But the problem is that records
>>        are not
>>                      generated the
>>                             way we
>>                                    expect and the way it works in normal
>>               forwarding
>>                      using
>>                                    usr_preferences. For example call is
>>               forwarded
>>                      from one
>>                             user
>>                                    to another, the first leg of the call
>>               should be
>>                      logged
>>                             as it
>>                                    should normally be($fU in leg
>>        source, $rU
>>               in leg
>>                             destination &
>>                                    calltype=call) and in next cdr
>>        log, it should
>>                      log with
>>                                    forwarding details(Forwarding user
>>        in leg
>>                      source, forwarded
>>                                    user in leg destination &
>>        calltype=cfwd).
>>               But it
>>                      actually
>>                                    generates 5 records(1 failed
>>        invite, 2 ok
>>                      invites & 2 byes,
>>                                    instead of 2 invites & 2 byes) of the
>>               call. Also
>>                      as we set
>>                                    calltype and leg source in onreply
>>        route,
>>               it'll
>>                      store that
>>                                    date for the first leg of the CDR
>>        which
>>               should
>>                      not happen.
>>
>>                                    Is the same limitation is there in
>>               OpenSIPS or
>>                      it has
>>                             better
>>                                    uac_redirect module?
>>
>>                                    I'll consider switching to
>>        OpenSIPS if it
>>               solves
>>                      this
>>                             issue.
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20080821/8edde6e3/attachment-0001.htm 


More information about the Users mailing list