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

Wed Aug 30 08:00:05 EDT 2017

Hi.

Very good.

Thank you very much!

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: quarta-feira, 30 de agosto de 2017 06:44
Para: users at lists.opensips.org
Assunto: Re: [OpenSIPS-Users] $(avp(attr)[$T_branch_idx]) is NULL for second INVITE. How to solve it ?

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

[http://www.opensips-solutions.com/imgs/slideshow/slide1.jpg]<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 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><sip:intercomB_RYg7tf4xx6JV at 127.0.0.1>;tag=469b3a48-1548-4af6-8e03-a5c855ce85f4
    To: <sip:g1r2u3p4o5 at 127.0.0.1><sip:g1r2u3p4o5 at 127.0.0.1>
    Contact: "ext1" <sip:intercomB_RYg7tf4xx6JV at 127.0.0.1:42194;transport=TLS;ob><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><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><sip:intercomB_RYg7tf4xx6JV at 127.0.0.1>;tag=469b3a48-1548-4af6-8e03-a5c855ce85f4
    To: <sip:g1r2u3p4o5 at 127.0.0.1><sip:g1r2u3p4o5 at 127.0.0.1>;tag=393a402c
    Contact: "ext1" <sip:intercomB_RYg7tf4xx6JV at 127.0.0.1:42194;transport=TLS;ob><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><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><mailto:users-bounces at lists.opensips.org> em nome de Liviu Chircu <liviu at opensips.org><mailto:liviu at opensips.org>
Enviado: terça-feira, 29 de agosto de 2017 12:34
Para: users at lists.opensips.org<mailto: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/imgs/slideshow/slide1.jpg]<http://www.opensips-solutions.com/>

Home — OpenSIPS Solutions<http://www.opensips-solutions.com/>
www.opensips-solutions.com<http://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<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto: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/41f13eda/attachment-0001.html>