[SR-Users] Kamailio with rtpproxy-ng and mediaproxy-ng: Error rewriting SDP

Sun Jul 20 19:15:33 CEST 2014

Hi,

After a long break while concentrating on other parts of my system I'll get
back to this problem. My system has changed a bit since the last setup,
although it's mostly the same: CentOS 6.5, Kamailio on 1.1.1.1:5060 and
newly added Asterisk on 1.1.1.1:5070. I use realtime integration, which
seems to work nicely. I'm able to call from a zoiper client to another
while signaling goes through Asterisk via dispatcher module functions.

I fixed my kamailio script, there was a copy paste error which caused all
my rtp profiles to be rtp/savpf, silly old me for making this mistake! Now
my script looks like this:

if ( (t_check_status("488") || t_check_status("415")) && sdp_content() ) {
if ( sdp_get_line_startswith("$avp(mline)", "m=") ) {
if ($avp(mline) =~ "SAVPF") {
$avp(rtpproxy_offer_flags) = "rtcp-mux-demux force trust-address
replace-origin replace-session-connection ICE=remove RTP/AVP";
$avp(rtpproxy_answer_flags) = "rtcp-mux-demux force trust-address
replace-origin replace-session-connection ICE=force RTP/SAVPF";
} else {
$avp(rtpproxy_offer_flags) = "rtcp-mux-demux force trust-address
replace-origin replace-session-connection ICE=force RTP/SAVPF";
$avp(rtpproxy_answer_flags) = "rtcp-mux-demux force trust-address
replace-origin replace-session-connection ICE=remove RTP/AVP";

}
}
append_branch();
rtpengine_offer($avp(rtpproxy_offer_flags));
t_on_reply("RTPPROXY_REPLY");
route(RELAY);
}

So right now my goal is to enable a call from a client using rtp/savpf to a
client using rtp/avp. The other variations of the example I can work out
later.

Now I'm getting somewhat similar results as in the beginning of this
thread, although, I am having progress as well. I'm not sure if adding
Asterisk to the mix (sip.conf has avpf=yes) will make life more difficult
but here goes:

I'll try to make a call from a ws client 660 to a zoiper client 771. Call
is established, and stays on for 2 seconds, then gets a hang up, which
originates from Asterisk, not from either client. What is strange is the
sdp descriptions:

1. SDP of the first INVITE from Kamailio to Asterisk:
v=0
o=- 850613716980436580 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS mvFMRRQODtH8zKqo5IOQHzRQw1f5U9QKuRP5
m=audio 30000 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 1.1.1.1
a=candidate:3350409123 1 udp 2122260223 192.168.0.101 62137 typ host
generation 0
a=candidate:3350409123 2 udp 2122260223 192.168.0.101 62137 typ host
generation 0
a=candidate:2999745851 1 udp 2122194687 192.168.56.1 62138 typ host
generation 0
a=candidate:2999745851 2 udp 2122194687 192.168.56.1 62138 typ host
generation 0
a=candidate:2301678419 1 tcp 1518280447 192.168.0.101 0 typ host generation
0
a=candidate:2301678419 2 tcp 1518280447 192.168.0.101 0 typ host generation
0
a=candidate:4233069003 1 tcp 1518214911 192.168.56.1 0 typ host generation 0
a=candidate:4233069003 2 tcp 1518214911 192.168.56.1 0 typ host generation 0
a=candidate:1190865175 1 udp 1686052607 2.2.2.2 62137 typ srflx raddr
192.168.0.101 rport 62137 generation 0
a=candidate:1190865175 2 udp 1686052607 2.2.2.2 62137 typ srflx raddr
192.168.0.101 rport 62137 generation 0
a=ice-ufrag:SDg+Zdks514ojBXF
a=ice-pwd:cPXTIk0phlMcfZql32v0np1o
a=ice-options:google-ice
a=fingerprint:sha-256
03:48:83:8A:E5:CF:28:C5:28:43:8B:F2:3A:AF:0A:ED:6D:E7:63:EE:87:14:43:0B:61:C5:4F:BB:9F:96:90:AA
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:2490449596 cname:UahzO270elyCvXw6
a=ssrc:2490449596 msid:mvFMRRQODtH8zKqo5IOQHzRQw1f5U9QKuRP5
898b170f-4f16-416c-b128-c7f48cebc525
a=ssrc:2490449596 mslabel:mvFMRRQODtH8zKqo5IOQHzRQw1f5U9QKuRP5
a=ssrc:2490449596 label:898b170f-4f16-416c-b128-c7f48cebc525
a=sendrecv
a=rtcp:30001
a=rtcp-mux
a=candidate:kSo5RG6Arv7JfiXg 1 UDP 1518214655 1.1.1.1 30000 typ host
a=candidate:kSo5RG6Arv7JfiXg 2 UDP 1518214654 1.1.1.1 30001 typ host

2. Asterisk responds 488 Not acceptable here

3. Second INVITE from Kamailio contains this SDP:

v=0
o=- 850613716980436580 2 IN IP4 1.1.1.1
s=-
t=0 0
a=msid-semantic: WMS mvFMRRQODtH8zKqo5IOQHzRQw1f5U9QKuRP5
m=audio 30004 RTP/AVP 111 103 104 0 8 106 105 13 126
c=IN IP4 1.1.1.1
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:2490449596 cname:UahzO270elyCvXw6
a=ssrc:2490449596 msid:mvFMRRQODtH8zKqo5IOQHzRQw1f5U9QKuRP5
898b170f-4f16-416c-b128-c7f48cebc525
a=ssrc:2490449596 mslabel:mvFMRRQODtH8zKqo5IOQHzRQw1f5U9QKuRP5
a=ssrc:2490449596 label:898b170f-4f16-416c-b128-c7f48cebc525
a=sendrecv
a=rtcp:30005
v=0
o=- 850613716980436580 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS mvFMRRQODtH8zKqo5IOQHzRQw1f5U9QKuRP5
m=audio 30004 RTP/AVP 111 103 104 0 8 106 105 13 126
c=IN IP4 1.1.1.1
a=candidate:3350409123 1 udp 2122260223 192.168.0.101 62137 typ host
generation 0
a=candidate:3350409123 2 udp 2122260223 192.168.0.101 62137 typ host
generation 0
a=candidate:2999745851 1 udp 2122194687 192.168.56.1 62138 typ host
generation 0
a=candidate:2999745851 2 udp 2122194687 192.168.56.1 62138 typ host
generation 0
a=candidate:2301678419 1 tcp 1518280447 192.168.0.101 0 typ host generation
0
a=candidate:2301678419 2 tcp 1518280447 192.168.0.101 0 typ host generation
0
a=candidate:4233069003 1 tcp 1518214911 192.168.56.1 0 typ host generation 0
a=candidate:4233069003 2 tcp 1518214911 192.168.56.1 0 typ host generation 0
a=candidate:1190865175 1 udp 1686052607 2.2.2.2 62137 typ srflx raddr
192.168.0.101 rport 62137 generation 0
a=candidate:1190865175 2 udp 1686052607 2.2.2.2 62137 typ srflx raddr
192.168.0.101 rport 62137 generation 0
a=ice-ufrag:SDg+Zdks514ojBXF
a=ice-pwd:cPXTIk0phlMcfZql32v0np1o
a=ice-options:google-ice
a=fingerprint:sha-256
03:48:83:8A:E5:CF:28:C5:28:43:8B:F2:3A:AF:0A:ED:6D:E7:63:EE:87:14:43:0B:61:C5:4F:BB:9F:96:90:AA
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:2490449596 cname:UahzO270elyCvXw6
a=ssrc:2490449596 msid:mvFMRRQODtH8zKqo5IOQHzRQw1f5U9QKuRP5
898b170f-4f16-416c-b128-c7f48cebc525
a=ssrc:2490449596 mslabel:mvFMRRQODtH8zKqo5IOQHzRQw1f5U9QKuRP5
a=ssrc:2490449596 label:898b170f-4f16-416c-b128-c7f48cebc525
a=sendrecv
a=rtcp:30005
a=rtcp-mux
a=candidate:kSo5RG6Arv7JfiXg 1 UDP 1518214655 1.1.1.1 30004 typ host
a=candidate:kSo5RG6Arv7JfiXg 2 UDP 1518214654 1.1.1.1 30005 typ host

There may be something off in my Asterisk configs since it's Asterisk that
responds 488, but see how Kamailio responds, SDP contains 2 similar m=
lines. Is there something I might be doing wrong in configuring rtpengine?
The INVITE going to the called client has nice clean rtp with RTP/AVP
profile.

I installed the latest rtpengine today. One thing I noticed the command
rtpengine --version output is undefined. Just a minor thing but good to
know.

Thank you for all your wonderful effort so far! Please let me know if you
need any logs or traces and I'll provide them asap.

cheers,
Olli

2014-04-21 17:18 GMT+03:00 Richard Fuchs <rfuchs at sipwise.com>:

> On 04/12/14 09:31, Olli Heiskanen wrote:
> > Hello,
> >
> > I'm probably still doing something wrong, I still get 488 from the
> > grandstream. Also zoiper refuses the call with 415 Unsupported Media
> Type.
> >
> > According to the module description I tried to change my config to this:
> > Btw, thanks for enabling verbose flags, those are more readable when
> > working on the config file.
> >
> > if ( t_check_status("488") && sdp_content() ) {
> >   if ( sdp_get_line_startswith("$avp(mline)", "m=") ) {
> >     if ($avp(mline) =~ "SAVPF") {
> >       $avp(rtpproxy_offer_flags) = "rtcp-mux-demux force trust-address
> > replace-origin replace-session-connection ICE=force RTP/SAVPF";
> >       $avp(rtpproxy_answer_flags) = "rtcp-mux-demux force trust-address
> > replace-origin replace-session-connection ICE=remove RTP/SAVPF";
> >     } else {
> >       $avp(rtpproxy_offer_flags) = "rtcp-mux-demux force trust-address
> > replace-origin replace-session-connection ICE=remove RTP/SAVPF";
> >       $avp(rtpproxy_answer_flags) = "rtcp-mux-demux force trust-address
> > replace-origin replace-session-connection ICE=force RTP/SAVPF";
> >     }
> >   }
> > }
> >
>
> I see that you're trying to talk RTP/SAVPF in all cases. Is this what
> you want? Or do you want to bridge between RTP/AVP and /SAVPF? Assuming
> that the granstream doesn't support SRTP, you should replace the first
> and the last occurrences in this snippet with "RTP/AVP".
>
> >
> > Below is the output from tail -f /var/log/messages when trying to call
> > from wsclient to gsclient
> > (are there any debug options etc to enable full logs being written to
> > syslog to help get the whole data out?)
>
> It's not rtpengine which is cutting off the log lines, it's probably the
> syslog daemon handling them. On my system I have rsyslogd and it's
> handling very long log lines quite nicely.
>
> >
> > I tried using -s0 option when using ngrep but the sdp still gets cut off
> > for some reason, that didn't help much... Although I think there are
> > full sdp when I write the output to a pcap file. I wonder if there's a
> > trick to force full packets onto ngrep output without writing to file?
>
> I believe ngrep works on a per-packet basis only, which fails as soon as
> the UDP packets get fragmented. I have more luck using wireshark as it
> reassembles fragments.
>
> cheers
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140720/3b3f07a6/attachment.html>