[SR-Users] Kamailio <-> Asterisk MWI

[Daniel-Constantin Mierla]

Hello,

On 11/27/12 4:38 PM, Daniel Tryba wrote:
> I'm trying to get the MWI indicator on endpoints to work by redirecting the
> SUBSCRIBE to the voicemail server (asterisk) using usc_replace_(to|from).
> This works fine for the initial request but the next subscribe will fail since
> the to/from don't get rewritten, which is indicated by the error:
> ERROR: uac [replace.c:250]: decline FROM replacing in sequential request in
> auto mode (has TO tag)
in auto mode, the From/To will be updated automatically for requests 
within dialog. So just relay the subscribe if it has To tag, don't call 
the function to update the header.

Cheers,
Daniel

>
> This occurs when the modparam "uac","restore_mode" is manual or auto. When set
> to none the redirect will be correct but all responses have to be rewritten
> manually (I'm a beginner and I don't want to do this just yet). And since uac
> has knowledge about this having being rewritten, sending the original from/to
> looks like like a bug to me (more probable a misconfiguration/omission of
> something crucial withing dialog responses :)
>
> Changes to the (default debian package) config, in route
> route[PRESENCE] in if(is_method("SUBSCRIBE"))
>
> if( is_method("SUBSCRIBE"))
> {
>    if(search_hf("Event", "message-summary", "a"))
>    {
>      if (!www_authenticate("$fd", "subscriber")) {
>        www_challenge("$fd", "1");
>        exit;
>      }
>
>      if(avp_db_query("SELECT value FROM usr_preferences WHERE username='$au'
> and attribute='voicemail' ORDER BY value limit 1"))
>      {
>        $avp(voicemail)=$avp(i:1);
>
>        $avp(subscrfrom)=$fu;
>        avp_subst("$avp(subscrfrom)", "/sip:.*@/sip:$avp(voicemail)@/");
>        uac_replace_from("$avp(subscrfrom)");
>        uac_replace_to("","sip:$avp(voicemail)@$sel(cfg_get.voicemail.srv_ip):
> $sel(cfg_get.voicemail.srv_port)");
>        remove_hf("Authorization");
>
>        $ru = "sip:" + $avp(voicemail) + "@" + $sel(cfg_get.voicemail.srv_ip) +
> ":" + $sel(cfg_get.voicemail.srv_port);
>        route(RELAY);
>      }
>    }
>    else
>    {
>      handle_subscribe();
>      t_release();
>    }
> }
> exit;
>
> 192.168.34.226 is the sip device, 192.168.32.40 kamailio, 192.168.32.41 the
> voicemailserver.
>
> Initial request:
> U 192.168.34.226:5852 -> 192.168.32.40:5060
> SUBSCRIBE sip:grandstream at sip.local SIP/2.0.
> From: "Daniel" <sip:grandstream at sip.local>;tag=67d8f67065827fe2.
> To: <sip:grandstream at sip.local>.
>
> Gets rewritten to:
> U 192.168.32.40:5060 -> 192.168.32.41:5060
> SUBSCRIBE sip:0880100782 at 192.168.32.41:5060 SIP/2.0.
> From: "Daniel" <sip:0880100782 at sip.local>;tag=67d8f67065827fe2.
> To: <sip:0880100782 at 192.168.32.41:5060>.
>
> The response gets relayed to the endpoint and MWI will light up since there is
> a message.
>
> But next subscribe update from the endpoint triggers the "decline FROM
> replacing in sequential request" error and thus the subscribe send to
> voicemail is the original to/from:
> U 192.168.32.40:5060 -> 192.168.32.41:5060
> SUBSCRIBE sip:0880100782 at 192.168.32.41:5060 SIP/2.0.
> From: "Daniel" <sip:grandstream at sip.local>;tag=67d8f67065827fe2.
> To: <sip:grandstream at sip.local>;tag=as324de8f3.
>
> Resulting in a 404 since the to/from are not the real peername on the
> voicemail server. How do I force Kamailio to rewrite the from/to without doing
> this manually for a requests/responses (restore_mode none)? The easy way out
> of this problem would be to have a 1 to 1 relation for the Kamailio
> subscribers and voicemail peers. But uac_replace should work (somehow).
>
> Attached is a full capture of the subscribe/notify. Running 3.3.2+squeeze from
> http://deb.kamailio.org/kamailio/. Machine is also running topoh module
> (192.168.0.1).
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121130/71e209e3/attachment.htm>