Hello,
I'm running the latest Kamailio 4.1 branch and rtpengine:master:15640991d7fc9d398749f77460b821296cccdcb6, and am running into a curious issue where the SDP body is duplicated (included twice) on a second branch.
The scenario is that call goes out on branch #1 and an rtpproxy_offer("ow-") is made. That branch fails with a 503 and another branch goes out with the same offer to a different destination.
The original SDP offer on branch #1:
v=0 o=Sansay-VSXi 188 1 IN IP4 rtpengine s=Session Controller c=IN IP4 rtpengine t=0 0 m=audio 32816 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv a=rtcp:32817
The SDP offer on branch #2 ends up being:
v=0 o=Sansay-VSXi 188 1 IN IP4 rtpengine s=Session Controller c=IN IP4 rtpengine t=0 0 m=audio 32816 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv a=rtcp:32817 v=0 o=Sansay-VSXi 188 1 IN IP4 rtpengine s=Session Controller c=IN IP4 rtpengine t=0 0 m=audio 32816 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv a=rtcp:32817
Interestingly enough, this seems to be premeditated, because on the first one, the Content-Length is 237, and on the second, 434. So, something clearly thinks that this is an appropriate thing to do.
If it makes a difference, I'm using two rtpengines RR'd in a set.
I am unable to reproduce this in my development environment and am unsure as to whether it's something that happens in all circumstances where there is such failover, or only intermittently. Still, is there any reason why it could be?
Thanks!
On 07/13/14 12:03, Alex Balashov wrote:
Hello,
I'm running the latest Kamailio 4.1 branch and rtpengine:master:15640991d7fc9d398749f77460b821296cccdcb6, and am running into a curious issue where the SDP body is duplicated (included twice) on a second branch.
Do you have any other SDP rewriting operations in your kamailio config?
cheers
No. But, of course, rtpproxy_offer() is being called on both branches.
On 13 July 2014 21:01:40 GMT-04:00, Richard Fuchs rfuchs@sipwise.com wrote:
On 07/13/14 12:03, Alex Balashov wrote:
Hello,
I'm running the latest Kamailio 4.1 branch and rtpengine:master:15640991d7fc9d398749f77460b821296cccdcb6, and am running into a curious issue where the SDP body is duplicated
(included
twice) on a second branch.
Do you have any other SDP rewriting operations in your kamailio config?
cheers
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0671 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
On 07/13/14 21:11, Alex Balashov wrote:
No. But, of course, rtpproxy_offer() is being called on both branches.
I'm not too familiar with the internals of the branching logic, but if you send out the same SDP a second time, you don't need to call _offer() again. If you do want to call it again (say, with different flags), you'd have to undo the changes done by the first call and then call it again. The msg_apply_changes() function may come in useful.
cheers
Richard Fuchs writes:
I'm not too familiar with the internals of the branching logic, but if you send out the same SDP a second time, you don't need to call _offer() again. If you do want to call it again (say, with different flags), you'd have to undo the changes done by the first call and then call it again. The msg_apply_changes() function may come in useful.
are you sure that msg_apply_changes is needed? i have thought that sdp changes made in branch_route are only visible in that branch.
-- juha
On 07/14/14 08:47, Juha Heinanen wrote:
Richard Fuchs writes:
I'm not too familiar with the internals of the branching logic, but if you send out the same SDP a second time, you don't need to call _offer() again. If you do want to call it again (say, with different flags), you'd have to undo the changes done by the first call and then call it again. The msg_apply_changes() function may come in useful.
are you sure that msg_apply_changes is needed? i have thought that sdp changes made in branch_route are only visible in that branch.
Like I said, I'm not familiar with the internals, so I'm mostly guessing. But I know that when you try to rewrite an SDP already rewritten by rtpengine, then you get these kind of strange duplication effects. Perhaps Alex can post a dumbed-down version of his config.
cheers
Hello,
I am not calling rtpproxy_offer() from branch_route (though perhaps I should be), but rather from a request route called from a failure_route. However, rtpproxy_offer() does get called every time on every branch, and perhaps that is the route of my mistake.
I'll investigate more and see what I can figure out. It seems to me that the aim should be to call rtpproxy_offer() from branch_route and have it work precisely as Juha expects, because I need to have the option of hairpinning media on some branches and not on others.
-- Alex
On 07/14/2014 08:41 AM, Richard Fuchs wrote:
On 07/13/14 21:11, Alex Balashov wrote:
No. But, of course, rtpproxy_offer() is being called on both branches.
I'm not too familiar with the internals of the branching logic, but if you send out the same SDP a second time, you don't need to call _offer() again. If you do want to call it again (say, with different flags), you'd have to undo the changes done by the first call and then call it again. The msg_apply_changes() function may come in useful.
cheers
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
After doing a little testing, what I can say is that this only happens with the rtpproxy-ng module, not regular rtpproxy module.
Whether it's a "misbehaviour" is hard to say. I'm still investigating.
On 07/14/14 09:45, Alex Balashov wrote:
After doing a little testing, what I can say is that this only happens with the rtpproxy-ng module, not regular rtpproxy module.
Whether it's a "misbehaviour" is hard to say. I'm still investigating.
This is because rtpproxy-ng/rtpengine always replaces the entire SDP body, whereas rtpproxy only replaces individual parts (such as the port number). Perhaps there's a better way to do this than using the lump mechanism?
cheers
This was solved by making the rtpproxy_offer() from a branch_route, as Juha suggested. It also works correctly now if branch #1 needs RTP relay and branch #2 does not.
-
Alex Balashov -
Juha Heinanen -
Richard Fuchs