[OpenSIPS-Users] $(avp(attr)[$T_branch_idx]) is NULL for second INVITE. How to solve it ?

Wed Aug 30 05:44:50 EDT 2017

You could persist it at dialog level, once the 200 OK reply arrives in 
an onreply_route, like so:

onreply_route [store_attr] {

     $dlg_val(callee_attr) = $(avp(attr)[$T_branch_idx])

}

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 29.08.2017 20:33, Rodrigo Pimenta Carvalho wrote:
>
> Hi Liviu.
>
>
> Thank you for your reply!
>
>
> I guess the second INVITE is a Re-INVITE, as you commented.
>
> In this case, is it possible to keep stored the value of $avp(attr) 
> and use it when necessary even after receiving the Re-INVITE?
>
>
> ----------
>
>
> Yes we have a retry, not a parallel forked call, but just when the 
> Re-INVITE is received by OpenSIPS. By other side, the first INVITE is 
> for a parallel forked call, if I'm well understanding the SIP here.
>
> The first INVITE is:
>
>
>     SIP Message: INVITE sip:g1r2u3p4o5 at 127.0.0.1 SIP/2.0
> Via: SIP/2.0/TLS 
> 127.0.0.1:42194;rport;branch=z9hG4bKPjd3128578-0158-4c58-8c1c-676aa864d8ca;alias
> Max-Forwards: 70
> From: "ext1" 
> <sip:intercomB_RYg7tf4xx6JV at 127.0.0.1>;tag=469b3a48-1548-4af6-8e03-a5c855ce85f4
> To: <sip:g1r2u3p4o5 at 127.0.0.1>
> Contact: "ext1" 
> <sip:intercomB_RYg7tf4xx6JV at 127.0.0.1:42194;transport=TLS;ob>;+sip.ice
> Call-ID: 22cb74fc-3d3b-4a37-9572-32f48c9943ff
> CSeq: 21431 INVITE
> Route: <sip:intercomB_RYg7tf4xx6JV at 127.0.0.1;transport=tls;lr>
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, 
> NOTIFY, REFER, MESSAGE, OPTIONS
> Supported: replaces, 100rel, timer, norefersub
> Session-Expires: 1800
> Min-SE: 90
> Content-Type: application/sdp
> Content-Length:  1267
>
> There is more than one registered (on-line) subscriber g1r2u3p4o5. So, 
> g1r2u3p4o5 has more than one AOR. I have 3 devices online for the 
> subscriber g1r2u3p4o5.
> The reply SIP OK comes from another network (not the local one), from 
> IP 10.0.60.246. After such reply, the Re-INVITE is:
>
>
> SIP Message: INVITE sip:g1r2u3p4o5 at 10.0.60.246:59673;transport=TLS SIP/2.0
> Via: SIP/2.0/TLS 
> 192.168.0.81:54188;rport;branch=z9hG4bKPjdde63995-7ed0-436a-983f-61d0e5df9498;alias
> Max-Forwards: 70
> From: "ext1" 
> <sip:intercomB_RYg7tf4xx6JV at 127.0.0.1>;tag=469b3a48-1548-4af6-8e03-a5c855ce85f4
> To: <sip:g1r2u3p4o5 at 127.0.0.1>;tag=393a402c
> Contact: "ext1" 
> <sip:intercomB_RYg7tf4xx6JV at 127.0.0.1:42194;transport=TLS;ob>;+sip.ice
> Call-ID: 22cb74fc-3d3b-4a37-9572-32f48c9943ff
> CSeq: 21433 INVITE
> Route: <sip:icchw.jflddns.com.br:5061;transport=tls;lr;did=d53.353e0122>
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, 
> NOTIFY, REFER, MESSAGE, OPTIONS
> Supported: replaces, 100rel, timer, norefersub
> Session-Expires: 1800;refresher=uac
> Min-SE: 90
> Content-Type: application/sdp
> Content-Length:   332
>
> In this moment I need to know if the device (callee) is in another 
> network, in fact, to take some fixes in SDP of INVITEs and SIP OKs.
> The $(avp(attr)[$T_branch_idx]) should have the information that I need.
>
> If it is not possible to keep the $(avp(attr)[$T_branch_idx]) stored, 
> is it possible to know if a device is in another network when it is a 
> callee?
>
> Any hint will be very helpful !!
>
> Best regards.
>
> RODRIGO PIMENTA CARVALHO
> Inatel Competence Center
> Software
> Ph: +55 35 3471 9200 RAMAL 979
>
>
> ------------------------------------------------------------------------
> *De:* Users <users-bounces at lists.opensips.org> em nome de Liviu Chircu 
> <liviu at opensips.org>
> *Enviado:* terça-feira, 29 de agosto de 2017 12:34
> *Para:* users at lists.opensips.org
> *Assunto:* Re: [OpenSIPS-Users] $(avp(attr)[$T_branch_idx]) is NULL 
> for second INVITE. How to solve it ?
>
> Hi Rodrigo,
>
>
> Just trying to understand the flow here - could it be actually a 
> Re-INVITE that goes through your sequential routing block, thus 
> lookup() is not called, leaving $avp(attr) NULL throughout that 
> transaction?
>
>
> Regardless of the above, in OpenSIPS terms, each "branch" points to a 
> different destination. In our case, we're talking about a retry, not a 
> serial/parallel forked call. Which means that you should only bother 
> with $T_branch_idx if a lookup() could yield more than one device to 
> be contacted for the same AoR.
>
>
> Best regards,
>
> Liviu Chircu
> OpenSIPS Developer
> http://www.opensips-solutions.com
> <http://www.opensips-solutions.com/>
> 	
> Home — OpenSIPS Solutions <http://www.opensips-solutions.com/>
> www.opensips-solutions.com
> OpenSIPS is a mature Open Source implementation of a SIP server. 
> OpenSIPS is more than a SIP proxy/router as it includes 
> application-level functionalities.
>
> On 29.08.2017 18:05, Rodrigo Pimenta Carvalho wrote:
>>
>>
>> Dear SIPusers,
>>
>>
>> In my project I use to keep a valuable information in table location. 
>> This is about the state of a subscriber's localization.
>>
>> I have to read such information for the callees, every time a new 
>> branch is created and every time a INVITE is answered with SIP OK.
>>
>> So, my OpenSIPS configuration has something similar to the following 
>> code:
>>
>>
>> 1    route{
>>
>> 2           ...  // hidden code for simplification.
>>
>> 3 lookup("location","m")
>>
>> 4           ...
>>
>> 5     route(relay);
>>
>> 6    }
>>
>>
>> 7    route[relay]{
>>
>> 8       if (is_method("INVITE")) {
>> 9                ...
>> 10 t_on_branch("per_branch_ops");
>> 11 t_on_reply("handle_nat");
>> 12 t_on_failure("missed_call");
>> 13     }
>> 14     ...
>>
>> 15  }
>>
>>
>> 16    branch_route[per_branch_ops] {
>> 17        ....
>>
>> 18        $(avp(attr)[$T_branch_idx])
>>
>> 19        ...
>>
>> 20    }
>>
>>
>> 21    onreply_route[handle_nat] {
>>
>> 22        ...
>>
>> 23 $(avp(attr)[$T_branch_idx])
>>
>> 24        ...
>>
>> 25    }
>>
>> 26    ...
>>
>>
>> In a determined call, when the OpenSIPS receives the INVITE and then 
>> a SIP OK (200), the code gets right value in lines 18 and 23.
>>
>> In such call, the SIP OK (from callee) offers a kind of video that 
>> the caller can't support. In this case the caller sends another SIP 
>> INVITE with inactive video (SDP).
>>
>> In this moment, OpenSIPS gets this second INVITE and create a new branch.
>>
>> However, for this new branch, lines 18 and 23 give me NULL for 
>> $(avp(attr)[$T_branch_idx]).
>>
>>
>> How to solve this issue?
>>
>>
>> Any hint will be very helpful!!
>>
>>
>> Best regards!
>>
>>
>> P.S.: I'm not expert in SIP.
>>
>>
>> RODRIGO PIMENTA CARVALHO
>> Inatel Competence Center
>> Software
>> Ph: +55 35 3471 9200 RAMAL 979
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170830/10b6ae42/attachment.html>