[OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6

[Chris Stone]

Ovidiu,

On Mon, Feb 7, 2011 at 4:19 PM, Ovidiu Sas <osas at voipembedded.com> wrote:
> By default, opensips does not modify the SDP.
> Double check your config.  If you don't need to touch SDP, make sure
> that you are not loading nathelper or mediaproxy.  Those are the two
> modules that are changing SDP.

Made sure neither of these were being loaded and used - mediaproxy
was, but nathelper was not. I need neither, so removed, restarted
opensips, tested a call. No change - problem persisted. So, dropped
down to a bare config:

#-----------------------------------------------------------------------
debug=9          # debug level (cmd line: -dddddddddd)
fork=yes
log_stderror=no  # (cmd line: -E)

children=25
check_via=no      # (cmd. line: -v)
dns=off           # (cmd. line: -r)
rev_dns=off       # (cmd. line: -R)
port=5060

# for more info: sip_router -h

# ------------------ module loading ----------------------------------
mpath="/usr/lib64/opensips/modules"

# ----------------- setting module-specific parameters ---------------


route{
        forward("67.212.153.179");
        exit;
}
#-----------------------------------------------------------------------

Restarted OpenSIPS with the above, and problem persists - SDP routing
modified (apparently) and Opensips proxies the audio.

Incoming from upstream:

    INVITE sip:17204497101 at 67.212.153.178:5060;transport=udp SIP/2.0\r\n
    From: "STONE C AND C"
<sip:+13038382386 at 208.94.157.10:5060>;tag=a9d5ed0-13c4-4d509b92-1bc5e644-648c7598\r\n
    To: <sip:17204497101 at 67.212.153.178:5060>\r\n
    Call-ID: CXC-260-758763d0-a9d5ed0-13c4-4d509b92-1bc5e643-43d2bf0a at 208.94.157.10\r\n
    CSeq: 1 INVITE\r\n
    Via: SIP/2.0/UDP
208.94.157.10:5060;branch=z9hG4bK-11150e-4d509b92-1bc5e644-273291f1\r\n
    Max-Forwards: 69\r\n
    P-Asserted-Identity: "STONE C AND C  "
<sip:+13038382386 at cxc.dashcs.com:5060>\r\n
    Supported: timer,100rel\r\n
    Content-Disposition: session;handling=required\r\n
    Contact: <sip:+13038382386 at 208.94.157.10:5060;maddr=208.94.157.10;transport=udp>\r\n
    Session-Expires: 1800\r\n
    Content-Type: application/sdp\r\n
    Content-Length: 238\r\n
    \r\n
    v=0\r\n
    o=Acme_UAS 0 1 IN IP4 208.94.157.10\r\n
    s=SIP Media Capabilities\r\n
    c=IN IP4 208.94.157.10\r\n
    t=0 0\r\n
    m=audio 22684 RTP/AVP 0 18 101\r\n
    a=rtpmap:0 PCMU/8000\r\n
    a=rtpmap:18 G729/8000\r\n
    a=rtpmap:101 telephone-event/8000\r\n
    a=maxptime:20\r\n
    a=sendrecv\r\n

Outgoing to Asterisk:

    INVITE sip:17204497101 at 67.212.153.178:5060;transport=udp SIP/2.0\r\n
    From: "STONE C AND C"
<sip:+13038382386 at 208.94.157.10:5060>;tag=a9d5ed0-13c4-4d509b92-1bc5e644-648c7598\r\n
    To: <sip:17204497101 at 67.212.153.178:5060>\r\n
    Call-ID: CXC-260-758763d0-a9d5ed0-13c4-4d509b92-1bc5e643-43d2bf0a at 208.94.157.10\r\n
    CSeq: 1 INVITE\r\n
    Via: SIP/2.0/UDP
67.212.153.178:5060;branch=z9hG4bK-11150e-4d509b92-1bc5e644-273291f1\r\n
    Via: SIP/2.0/UDP
208.94.157.10:5060;branch=z9hG4bK-11150e-4d509b92-1bc5e644-273291f1\r\n
    Max-Forwards: 69\r\n
    P-Asserted-Identity: "STONE C AND C  "
<sip:+13038382386 at cxc.dashcs.com:5060>\r\n
    Supported: timer,100rel\r\n
    Content-Disposition: session;handling=required\r\n
    Contact: <sip:+13038382386 at 67.212.153.178:5060;maddr=208.94.157.10;transport=udp>\r\n
    Session-Expires: 1800\r\n
    Content-Type: application/sdp\r\n
    Content-Length: 240\r\n
    \r\n
    v=0\r\n
    o=Acme_UAS 0 1 IN IP4 67.212.153.178\r\n
    s=SIP Media Capabilities\r\n
    c=IN IP4 67.212.153.178\r\n
    t=0 0\r\n
    m=audio 22684 RTP/AVP 0 18 101\r\n
    a=rtpmap:0 PCMU/8000\r\n
    a=rtpmap:18 G729/8000\r\n
    a=rtpmap:101 telephone-event/8000\r\n
    a=maxptime:20\r\n
    a=sendrecv\r\n

I've got to be missing something stupid - the setup works great under
1.4 - would expect as well or better under 1.6 - but appears that
there's some config option or default that I'm missing....

But, with such a basic config as above, not sure what it would
be.....Would sure seem that, by some default, OpenSIPS proxies the
audio, no?


Thanks!


Chris