t_on_reply not catching 183

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

t_on_reply not catching 183

Mark Farmer
Hi everyone, I'm trying to solve an issue related to reception of early media. I am getting 183 messages back to establish the audio path but OpenSIPS is passing the 183 back to an Asterisk box without changing the SDP "c" parameter. So Asterisk tries to send audio direct instead of to the rtpproxy.

Doing some debugging, I can see that my reply route doesn't seem to be matching the 183 because I never get any logs from the reply route. Can anyone see anything wrong with it? I've checked the routing script & the reply route seems to be armed.

onreply_route[DROUTING] {

        if (is_method("BYE|CANCEL")) {
                sip_trace("htid","d");
                rtpproxy_unforce();
        }

        #if ( $rs >= 200 )
                #$acc_extra(to_usr) = $tU;

        if ($rs=~"(2[0-9][0-9])|(183)" && has_body("application/sdp")) {
            xlog("Processing reply $fU");
            if (is_from_gw("1")) {
                    xlog("Reply from Asterisk PBX");
                    setflag(INT_R);
                } else if (is_from_gw("2")) {
                        xlog("Reply from Provider");
                        setflag(EXT_R);
                }
        }

        if (isflagset(INT_R)) {
                remove_hf("P-Asserted-Identity");
                rtpproxy_answer("corwfei");
            } else if (isflagset(EXT_R)) {
                rtpproxy_answer("corwfie");
        }
}


Many thanks for any & all help.
Mark.


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: t_on_reply not catching 183

Mark Farmer
Sorry - version info:

opensips -V
version: opensips 2.4.5 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: d025b4f61
main.c compiled on 11:39:27 Apr 12 2019 with gcc 7


On Fri, 7 Jun 2019 at 10:45, Mark Farmer <[hidden email]> wrote:
Hi everyone, I'm trying to solve an issue related to reception of early media. I am getting 183 messages back to establish the audio path but OpenSIPS is passing the 183 back to an Asterisk box without changing the SDP "c" parameter. So Asterisk tries to send audio direct instead of to the rtpproxy.

Doing some debugging, I can see that my reply route doesn't seem to be matching the 183 because I never get any logs from the reply route. Can anyone see anything wrong with it? I've checked the routing script & the reply route seems to be armed.

onreply_route[DROUTING] {

        if (is_method("BYE|CANCEL")) {
                sip_trace("htid","d");
                rtpproxy_unforce();
        }

        #if ( $rs >= 200 )
                #$acc_extra(to_usr) = $tU;

        if ($rs=~"(2[0-9][0-9])|(183)" && has_body("application/sdp")) {
            xlog("Processing reply $fU");
            if (is_from_gw("1")) {
                    xlog("Reply from Asterisk PBX");
                    setflag(INT_R);
                } else if (is_from_gw("2")) {
                        xlog("Reply from Provider");
                        setflag(EXT_R);
                }
        }

        if (isflagset(INT_R)) {
                remove_hf("P-Asserted-Identity");
                rtpproxy_answer("corwfei");
            } else if (isflagset(EXT_R)) {
                rtpproxy_answer("corwfie");
        }
}


Many thanks for any & all help.
Mark.



--
Mark Farmer
[hidden email]

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: t_on_reply not catching 183

Mark Farmer
Never mind, it seems the issue was triggered by my soft client not using STUN

Fixed that bit now :)

Mark.


On Fri, 7 Jun 2019 at 10:53, Mark Farmer <[hidden email]> wrote:
Sorry - version info:

opensips -V
version: opensips 2.4.5 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: d025b4f61
main.c compiled on 11:39:27 Apr 12 2019 with gcc 7


On Fri, 7 Jun 2019 at 10:45, Mark Farmer <[hidden email]> wrote:
Hi everyone, I'm trying to solve an issue related to reception of early media. I am getting 183 messages back to establish the audio path but OpenSIPS is passing the 183 back to an Asterisk box without changing the SDP "c" parameter. So Asterisk tries to send audio direct instead of to the rtpproxy.

Doing some debugging, I can see that my reply route doesn't seem to be matching the 183 because I never get any logs from the reply route. Can anyone see anything wrong with it? I've checked the routing script & the reply route seems to be armed.

onreply_route[DROUTING] {

        if (is_method("BYE|CANCEL")) {
                sip_trace("htid","d");
                rtpproxy_unforce();
        }

        #if ( $rs >= 200 )
                #$acc_extra(to_usr) = $tU;

        if ($rs=~"(2[0-9][0-9])|(183)" && has_body("application/sdp")) {
            xlog("Processing reply $fU");
            if (is_from_gw("1")) {
                    xlog("Reply from Asterisk PBX");
                    setflag(INT_R);
                } else if (is_from_gw("2")) {
                        xlog("Reply from Provider");
                        setflag(EXT_R);
                }
        }

        if (isflagset(INT_R)) {
                remove_hf("P-Asserted-Identity");
                rtpproxy_answer("corwfei");
            } else if (isflagset(EXT_R)) {
                rtpproxy_answer("corwfie");
        }
}


Many thanks for any & all help.
Mark.



--
Mark Farmer
[hidden email]


--
Mark Farmer
[hidden email]

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: t_on_reply not catching 183

S. Rosenberg
Are you missing a fix_natted_contact somewhere? That should in most cases eliminate the need of  stun.

On Fri, Jun 7, 2019, 2:14 PM Mark Farmer <[hidden email]> wrote:
Never mind, it seems the issue was triggered by my soft client not using STUN

Fixed that bit now :)

Mark.


On Fri, 7 Jun 2019 at 10:53, Mark Farmer <[hidden email]> wrote:
Sorry - version info:

opensips -V
version: opensips 2.4.5 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: d025b4f61
main.c compiled on 11:39:27 Apr 12 2019 with gcc 7


On Fri, 7 Jun 2019 at 10:45, Mark Farmer <[hidden email]> wrote:
Hi everyone, I'm trying to solve an issue related to reception of early media. I am getting 183 messages back to establish the audio path but OpenSIPS is passing the 183 back to an Asterisk box without changing the SDP "c" parameter. So Asterisk tries to send audio direct instead of to the rtpproxy.

Doing some debugging, I can see that my reply route doesn't seem to be matching the 183 because I never get any logs from the reply route. Can anyone see anything wrong with it? I've checked the routing script & the reply route seems to be armed.

onreply_route[DROUTING] {

        if (is_method("BYE|CANCEL")) {
                sip_trace("htid","d");
                rtpproxy_unforce();
        }

        #if ( $rs >= 200 )
                #$acc_extra(to_usr) = $tU;

        if ($rs=~"(2[0-9][0-9])|(183)" && has_body("application/sdp")) {
            xlog("Processing reply $fU");
            if (is_from_gw("1")) {
                    xlog("Reply from Asterisk PBX");
                    setflag(INT_R);
                } else if (is_from_gw("2")) {
                        xlog("Reply from Provider");
                        setflag(EXT_R);
                }
        }

        if (isflagset(INT_R)) {
                remove_hf("P-Asserted-Identity");
                rtpproxy_answer("corwfei");
            } else if (isflagset(EXT_R)) {
                rtpproxy_answer("corwfie");
        }
}


Many thanks for any & all help.
Mark.



--
Mark Farmer
[hidden email]


--
Mark Farmer
[hidden email]
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: t_on_reply not catching 183

Mark Farmer
Thanks. The soft client is registered to an Asterisk box so I don't think that's the issue here.



On Sat, 8 Jun 2019 at 00:58, Schneur Rosenberg <[hidden email]> wrote:
Are you missing a fix_natted_contact somewhere? That should in most cases eliminate the need of  stun.

On Fri, Jun 7, 2019, 2:14 PM Mark Farmer <[hidden email]> wrote:
Never mind, it seems the issue was triggered by my soft client not using STUN

Fixed that bit now :)

Mark.


On Fri, 7 Jun 2019 at 10:53, Mark Farmer <[hidden email]> wrote:
Sorry - version info:

opensips -V
version: opensips 2.4.5 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: d025b4f61
main.c compiled on 11:39:27 Apr 12 2019 with gcc 7


On Fri, 7 Jun 2019 at 10:45, Mark Farmer <[hidden email]> wrote:
Hi everyone, I'm trying to solve an issue related to reception of early media. I am getting 183 messages back to establish the audio path but OpenSIPS is passing the 183 back to an Asterisk box without changing the SDP "c" parameter. So Asterisk tries to send audio direct instead of to the rtpproxy.

Doing some debugging, I can see that my reply route doesn't seem to be matching the 183 because I never get any logs from the reply route. Can anyone see anything wrong with it? I've checked the routing script & the reply route seems to be armed.

onreply_route[DROUTING] {

        if (is_method("BYE|CANCEL")) {
                sip_trace("htid","d");
                rtpproxy_unforce();
        }

        #if ( $rs >= 200 )
                #$acc_extra(to_usr) = $tU;

        if ($rs=~"(2[0-9][0-9])|(183)" && has_body("application/sdp")) {
            xlog("Processing reply $fU");
            if (is_from_gw("1")) {
                    xlog("Reply from Asterisk PBX");
                    setflag(INT_R);
                } else if (is_from_gw("2")) {
                        xlog("Reply from Provider");
                        setflag(EXT_R);
                }
        }

        if (isflagset(INT_R)) {
                remove_hf("P-Asserted-Identity");
                rtpproxy_answer("corwfei");
            } else if (isflagset(EXT_R)) {
                rtpproxy_answer("corwfie");
        }
}


Many thanks for any & all help.
Mark.



--
Mark Farmer
[hidden email]


--
Mark Farmer
[hidden email]
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Mark Farmer
[hidden email]

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users