Hi, - using latest rtpengine master from github . - using kamailio configuration with rtpengine to process incoming WebRTC calls and forward as SIP/RTP calls, using rtpengine to process SRTP one side and RTP on the other side - using the same kamailio configuration file between kamailio revisions - using kamailio 4.4.0 or kamailio 4.4.1 everything works fine, but starting with kamailio 4.4.2 and newer this one does not send the same commands to rtpengine, there is no difference/error in kamailio log files
Starting with kamailio 4.4.2 the following elements are seen on socket between kamailio and rtpengine
tcpdump -i any -n -p -s0 -A port 2223 ... 14:46:48.050895 IP 127.0.0.1.47294 > 127.0.0.1.rockwell-csp2: UDP, length 194 E...p,..@...................2_12168_1 d3:ICE6:remove18:transport-protocol7:RTP/AVP7:call-id36:68c3bb30-> > e7a8-11ab-3f61-04969aef87e413:received-froml3:IP415:192.168.160.127e8:from-tag20:AKlSUpLNnHZUFwLTPDxz7:command6:deletee 14:46:48.051038 IP 127.0.0.1.rockwell-csp2 > 127.0.0.1.47294: UDP, length 74
E..f..@.@.<..............R.e2_12168_1 d7:warning38:Call-ID not found or tags didn't match6:result2:oke
14:46:48.064394 IP 127.0.0.1.36712 > 127.0.0.1.rockwell-csp2: UDP, length 194
E...p:..@............h......2_12154_1 d3:ICE6:remove18:transport-protocol7:RTP/AVP7:call-id36:68c3bb30-e7a8-11ab-3f61-04969aef87e413:received-froml3:IP415:192.168.160.127e8:from-tag20:AKlSUpLNnHZUFwLTPDxz7:command6:deletee
14:46:48.064804 IP 127.0.0.1.rockwell-csp2 > 127.0.0.1.36712: UDP, length 74
E..f..@.@.<............h.R.e2_12154_1 d7:warning38:Call-ID not found or tags didn't match6:result2:oke
...
With older kamailio 4.4.1 or 4.4.0 the kamailio sent commands including received SDP
15:03:49.229974 IP 127.0.0.1.60102 > 127.0.0.1.rockwell-csp2: UDP, length 1938
E...r...@.. ................13292_3 d3:sdp1639:v=0 o=- 6640213216577907000 2 IN IP4 127.0.0.1 s=Doubango Telecom - chrome t=0 0 a=group:BUNDLE audio a=msid-semantic: WMS 9yLYCKgUvouNO6bYmskX60S0VD3SCy7KRuf6 m=audio 52254 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126 c=IN IP4 192.168.160.127 a=rtcp:52255 IN IP4 192.168.160.127 a=candidate:143086084 1 udp 2122260223 192.168.160.127 52254 typ host generation 0 network-id 1 a=candidate:143086084 2 udp 2122260222 192.168.160.127 52255 typ host generation 0 network-id 1 a=candidate:1174712052 1 tcp 1518280447 192.168.160.127 9 typ host tcptype active generation 0 network-id 1 a=candidate:1174712052 2 tcp 1518280446 192.168.160.127 9 typ host tcptype active generation 0 network-id 1 ...
Starting with kamailio 4.4.2 is there any recommended rtpengine revision to use or new configuration parameters to set ?
Thanks. Regards.
Can you try with latest kamailio from branch 4.4 (freshly released 4.4.4)?
I haven't spotted any relevant change in rtpengine module of kamailio between 4.4.1 and 4.4.2.
Same thing with 4.4.4. [kamailio.txt](https://github.com/kamailio/kamailio/files/581049/kamailio.txt)
Maybe @rfuchs or @linuxmaniac can comment if something has changed in the master branch rtpengine application or something else got broken that has such effect.
Tried to replace rtpengine_manage() with appropriate rtpengine_offer(), rtpengine_answer(), ...etc and it works. It seems rtpengine_manage() is sending delete command, considering execution in route_type FAILURE_ROUTE, could it be a side effect from GH #676 ?
Could be. The best way is to use rtpengine_manage() function in a branch route for requests, then you know it's done only when forwarding the request.
Considering such route for async queries
` route[REQUESTRTJSON] { ` ` xlogl("L_INFO", "Requesting JSON routes\n"); ` ` t_newtran(); ` ` $http_req(hdr) = "Expect:"; ` ` $http_req(timeout) = DEFAULTHTTPTIMEOUTMSEC; ` ` http_async_query("http://127.0.0.1/webrtcwslb/forwarder.php?forwardservice=kamailiort&rU=$... ` }`
And answer processed in
`route[HTTPRTJSONREPLY] {` ` if($http_ok) {` ` xlogl("L_INFO", "route[HTTPRTJSONREPLY]: status $http_rs\n");` ` xlogl("L_INFO", "route[HTTPRTJSONREPLY]: body $http_rb\n");` ` json_get_field($http_rb,"routing", "$var(routing)");` ` if($var(routing)=="location") {` ` route(LOCATION);` ` exit;` ` }` ` xlogl("L_INFO", "route[HTTPRTJSONREPLY]: init routes\n");` ` rtjson_init_routes("$http_rb");` ` xlogl("L_INFO", "route[HTTPRTJSONREPLY]: pushing routes\n");` ` rtjson_push_routes();` ` xlogl("L_INFO", "route[HTTPRTJSONREPLY]: pushed routes\n");` ` t_on_branch("MANAGE_BRANCH");` ` t_on_failure("MANAGE_FAILURE");` ` route(RELAY);` ` exit;` ` } else {` ` xlogl("L_INFO", "route[HTTPRTJSONREPLY]: error $http_err\n");` ` exit;` ` }` `}`
the cfgtrace gives
2016-11-16T09:29:36.869221+01:00 localhost (12040) ERROR: *** cfgtrace:request_route=[REQUESTRTJSON] c=[/product/CCAPI/WebRTC/Kamailio/etc/1479284325.480324_f0b20d2e1c37d2fa3dfed1126a48aacaf79c2ab6//kamailio.cfg] l=581 a=26 n=http_async_query ... 2016-11-16T09:29:36.912117+01:00 localhost (12035) ERROR: *** cfgtrace:failure_route=[HTTPRTJSONREPLY] c=[/product/CCAPI/WebRTC/Kamailio/etc/1479284325.480324_f0b20d2e1c37d2fa3dfed1126a48aacaf79c2ab6//kamailio.cfg] l=607 a=16 n=if
so HTTPRTJSONREPLY route is considered as failure_route, such state is kept when calling route(RELAY) and further raising the following code in rtpengine on INVITE for rtpengine_manage() function `if (msg->first_line.type == SIP_REQUEST) {` `...` ` if(method==METHOD_INVITE && nosdp==0) {` ` msg->msg_flags |= FL_SDP_BODY;` ` if(tmb.t_gett!=NULL && tmb.t_gett()!=NULL` ` && tmb.t_gett()!=T_UNDEFINED)` ` tmb.t_gett()->uas.request->msg_flags |= FL_SDP_BODY;` ` if(route_type==FAILURE_ROUTE)` ` return rtpengine_delete(msg, flags);` ` return rtpengine_offer_answer(msg, flags, OP_OFFER, 0);` ` }`
On kamailio 4.4.1 rtpengine_offer_answer() was called, but now rtpengine_delete() is called due to (route_type==FAILURE_ROUTE)
Do you execute rtpengine_manage() inside route[RELAY] or in branch_route[MANGE_BRANCH]?
inside route[RELAY]. route[HTTPRTJSONREPLY] calls route[RELAY] calls route[SETUP_BY_TRANSPORT] which calls rtpengine_manage()
You should move the rtpengine_manage() in a branch route (or the route block where it is, to be called from a branch route). That's the best way even for non-async cases.
Closed #855.
I added a note to the readme of rtpproxy at the description of rtpengine_manage about this behaviour.
I will try to find a way to better handle this case. If you want this feature and don't want to be forgotten, you can open a new item on this tracker as a feature request to get the desired function behaviour.
-
Daniel-Constantin Mierla -
Laurent Glayal