13 Jul
2014
13 Jul
'14
9:03 p.m.
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!
--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
14 Jul
14 Jul
6:01 a.m.
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
6:11 a.m.
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(a)sipwise.com> wrote:
On 07/13/14 12:03, Alex Balashov wrote:
--
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
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
5:41 p.m.
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
5:47 p.m.
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
5:51 p.m.
On 07/14/14 08:47, Juha Heinanen wrote:
Richard Fuchs writes:
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
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.
5:58 p.m.
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:
--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
6:45 p.m.
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.
--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
7:03 p.m.
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
8:20 p.m.
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 - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
3577
days inactive
3578
days old
9 comments
3 participants
participants (3)
-
Alex Balashov -
Juha Heinanen -
Richard Fuchs