Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parallel fork of calls with same Call-ID #39

Closed
ovoshlook opened this issue Oct 17, 2014 · 3 comments
Closed

parallel fork of calls with same Call-ID #39

ovoshlook opened this issue Oct 17, 2014 · 3 comments

Comments

@ovoshlook
Copy link

Hello. I try to do parallel fork calls to endpoints that have same username and different destination URI through Kamailio. Logic of my script:

checking location table for rows with needed account
get info from contact at loop

for every step

check technology (sip or ws)
handle call with rtpengine
append_branch with existing destination for this account
rewrite packet with rtpengine to needed technology

after loop
forward packets via t_relay

sql_query("ca", "select contact from location where username='$tU'", "ra");
xlog("rows: $dbr(ra=>rows) cols: $dbr(ra=>cols)\n");

        if($dbr(ra=>rows)>0){
            $var(i)=0;
             while($var(i)<$dbr(ra=>rows)){

                xlog("L_INFO","SQL query return contact {$dbr(ra=>[$var(i),0])} for {$tU} at step {$var(i)}\n");

                if ($dbr(ra=>[$var(i),0])=~"transport=ws"){ 
                    xlog("L_INFO", "This is a Websocket call to endpoint");
                    sql_pvquery("ca", "select received from location where contact='$dbr(ra=>[$var(i),0])'","$var(recieved)");
                    xlog("L_INFO","SQL query return recieved {$var(recieved)} for {$tU}\n");
                    $du=$var(recieved);
                    xlog("L_INFO", "Request going FROM ASTERISK to WS. Destination is {$du}\n");
                    xlog("L_INFO","Websocket Destination URI is {$var(recieved)} for {$tU}\n");
                    rtpproxy_manage("froc+SP");
                    t_on_reply("REPLY_FROM_WS");
                    append_branch("sip:$tU@$du");
                    $var(i) = $var(i) + 1;
                }

                else
                {   
                    xlog("L_INFO", "This is a classic UDP call to endpoint");

                    $du="sip:"+$(dbr(ra=>[$var(i),0]){s.select,1,@});
                    xlog("L_INFO","Classic Destination URI is {$dbr(ra=>[$var(i),0])} for {$tU}\n");
                    rtpproxy_manage("co");
                    t_on_reply("MANAGE_CLASSIC_REPLY");
                    append_branch("sip:$tU@$du");
                    $var(i) = $var(i) + 1;
                }
                #append_branch("sip:$tU@$du");

            }   
        }
        return 1;

So it customised schema of standart example

seturi("sip:a@example.com");
append_branch("sip:b@example.com");
append_branch("sip:c@example.com");
append_branch("sip:d@example.com");

t_relay();

At my test I have 2 endpoints with WS and UDP phones (at fist step ir WS and 2 step it UDP). when I do these steps (at my script) I see packet at TCP dump and saw that sended only one packet to UDP but body of packet is WS. Then I saw log of kamailio. I see that at second step packet changed body to WS body (so strange because other steps before and after goes for UDP (as at logic of script))

All calls going form asterisk via UDP.

I think my problem may be at rtpengine that already handle packetd with this Call-ID and gives same result for other flags to this packet at second step.

Does it right?

@rfuchs
Copy link
Member

rfuchs commented Oct 27, 2014

Closing as this is already being handled on the kamailio mailing list

@rfuchs rfuchs closed this as completed Oct 27, 2014
@GGGO
Copy link

GGGO commented Oct 27, 2014

Hello !

I would like to know if this issue is solved sipwise/mediaproxy-ng#23
in rtpengine code. It seems to be related to this issue, so.

My test is very simple, I have 2 endpoints connecting to the same username (201). One using TLS/SRTP, the other one using UDP/RTP.

If I call 201, the 2 endpoints ring but I can see that rtpengine overwrites the offer of the other one. And finally got this error: "SRTP output wanted, but no crypto suite was negotiated"

I use the kamailio-advanced.cfg provided with default installation of kamailio(4.2.0). And I think lookup(location) doesn't work with rptengine even if modparam("registrar", "append_branches", 1).

kamailio seems to reuse same callid and branch value for the 2 calls, so rtpengine can't detect 2 sessions.

@ovoshlook, this is why you don't use lookup(location) and build manually the branches ?

Thank you !

@ovoshlook
Copy link
Author

I not use lookup becasue I use WebSocket based endpoints and kamailio can
not resolve contact field data fro this endpoints. I use received field to
set Destination URI for this endpoints. so I need custom query to database
for finding this endpoints.

2014-10-28 1:12 GMT+04:00 GGGO notifications@github.com:

Hello !

I would like to know if this issue is solved sipwise/mediaproxy-ng#23
sipwise/mediaproxy-ng#23
in rtpengine code. It seems to be related to this issue, so.

My test is very simple, I have 2 endpoints connecting to the same username
(201). One using TLS/SRTP, the other one using UDP/RTP.

If I call 201, the 2 endpoints ring but I can see that rtpengine
overwrites the offer of the other one. And finally got this error: "SRTP
output wanted, but no crypto suite was negotiated"

I use the kamailio-advanced.cfg provided with default installation of
kamailio(4.2.0). And I think lookup(location) doesn't work with rptengine
even if modparam("registrar", "append_branches", 1).

kamailio seems to reuse same callid and branch value for the 2 calls, so
rtpengine can't detect 2 sessions.

@ovoshlook https://github.com/ovoshlook, this is why you don't use
lookup(location) and build manually the branches ?

Thank you !


Reply to this email directly or view it on GitHub
#39 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants