Asterisk Not Following SDP Port Change

Home » Asterisk Users » Asterisk Not Following SDP Port Change
Asterisk Users 4 Comments

Hello!

I’ve got a number of asterisk systems running asterisk 16.12.0 currently. They’re configured with PJSIP. Some of them are behind NAT, some aren’t. All systems have SIP trunks to a Sansay INX. I’ve had one-way audio issues calling a particular number. After some investigation, It seems that the audio is lost due to port changes in SDP. Other calls don’t seem to have any issues. Here’s what happens.

Good call:
1. Asterisk sends invite to Sansay INX.
2. Sansay replies 100 Trying without SDP.
3. Sansay replies 183 Progress and provides SDP. This SDP specifies a Media server and Port. Let’s say 192.168.1.2 and port 20100.
4. RTP starts to exchange. Asterisk sending to 192.168.1.2 on port 20100.
5. 200OK is received from Sansay, again it includes SDP showing 192.168.1.2
with port 20100 for RTP.
6. Call works normally.

Bad Call:
1. Asterisk sends invite to Sansay INX.
2. Sansay replies 100 Trying without SDP.
3. Sansay replies 183 Progress and provides SDP. This SDP specifies a Media server and Port. Let’s say 192.168.1.2 and port 20100.
4. RTP starts to exchange. Asterisk sending to 192.168.1.2 on port 20100.
5. 200OK is received from Sansay, This time, It includes modified STP, The IP is still 192.168.1.2, but the port is now 20180.
6. Asterisk continues to send to SDP 20100.

2nd example of bad call:
1. Asterisk sends invite to Sansay INX.
2. Sansay replies 100 Trying without SDP.
3. Sansay starts sending RTP FROM 192.168.1.2 port 20100
4. Asterisk starts sending RTP to 192.168.1.2 port 20100 (Even with force rport and comedia, and rewrite contact off, before we ever get the first SDP).
5. Sansay replies 183 Progress and provides SDP. This SDP specifies a Media server and Port. Let’s say 192.168.1.2 and port 20180 (This is a CHANGE
from step 4).
6. Asterisk is still sending to 192.168.1.2 port.20100 (Ignoring SDP in step 5 183 progress)
7. 200OK is received from Sansay, Now a third port is received, The IP is still 192.168.1.2, but the port is now 20250.
8. Asterisk continues to send to SDP 20100. (Ignoring SDP received at step
5 and 7)

I’m hoping I’m missing a simple setting here like “Ignore SDP = no” in PJSIP. But I’ve not found it yet.

Secondly, in all cases, Inbound audio (Sansay to asterisk) is fine. And the source port of RTP DOES change in both bad call examples above. But I
assume asterisk is handling it because the traffic is still arriving on the same port from asterisk’s point of view.

Why calling this one particular number results in 2-3 SDP port changes I
don’t yet know. But from what I can see, It’s not improper to have port changes in later SDP. And asterisk *should* follow them. But someone please correct me if I’m wrong.

Thank you!

4 thoughts on - Asterisk Not Following SDP Port Change

  • –000000000000be493d05bca76559
    Content-Type: text/plain; charset=”UTF-8″

    Thanks for the reply, Joshua.

    Here’s a screenshot of the ladder diagram for the call. A is Asterisk S is Sansay M is Sansay Media Server.

    [image: image.png]

    SDP for the first 183
    Session Description Protocol
    Session Description Protocol Version (v): 0
    Owner/Creator, Session Id (o): Sansay-VSXi 188 1 IN IP4
    XX.XX.XX.12
    Session Name (s): Session Controller
    Connection Information (c): IN IP4 XX.XX.XX.46
    Time Description, active time (t): 0 0
    Media Description, name and address (m): audio 14996 RTP/AVP 0
    101
    Media Attribute (a): rtpmap:0 PCMU/8000
    Media Attribute (a): rtpmap:101 telephone-event/8000
    Media Attribute (a): fmtp:101 0-15
    Media Attribute (a): ptime:20
    Media Attribute (a): sendrecv

    SDP for the 2nd 183
    Session Description Protocol
    Session Description Protocol Version (v): 0
    Owner/Creator, Session Id (o): Sansay-VSXi 188 1 IN IP4
    XX.XX.XX.12
    Session Name (s): Session Controller
    Connection Information (c): IN IP4 XX.XX.XX.46
    Time Description, active time (t): 0 0
    Media Description, name and address (m): audio 15104 RTP/AVP 0
    101
    Media Attribute (a): rtpmap:0 PCMU/8000
    Media Attribute (a): rtpmap:101 telephone-event/8000
    Media Attribute (a): fmtp:101 0-15
    Media Attribute (a): ptime:20
    Media Attribute (a): sendrecv

    SDP for the 200OK.
    Session Description Protocol
    Session Description Protocol Version (v): 0
    Owner/Creator, Session Id (o): Sansay-VSXi 188 1 IN IP4
    XX.XX.XX.12
    Session Name (s): Session Controller
    Connection Information (c): IN IP4 XX.XX.XX.46
    Time Description, active time (t): 0 0
    Media Description, name and address (m): audio 15252 RTP/AVP 0
    101
    Media Attribute (a): rtpmap:0 PCMU/8000
    Media Attribute (a): rtpmap:101 telephone-event/8000
    Media Attribute (a): fmtp:101 0-15
    Media Attribute (a): sendrecv
    Media Attribute (a): ptime:20

    Still working on the logs, But gather anything from that so far?

    In this case, asterisk always sent to the first provided RTP port of 14996.

    –000000000000be493d05bca76559
    Content-Type: text/html; charset=”UTF-8″
    Content-Transfer-Encoding: quoted-printable

    Thanks for the reply, Joshua.

    Here's a screenshot of the ladder diagram for the call.
    A is Asterisk
    S is Sansay
    M is Sansay Media Server.
    image.png
    SDP for the first 183
            Session Description Protocol
                Session Description Protocol Version (v): 0
                Owner/Creator, Session Id (o): Sansay-VSXi 188 1 IN IP4 XX.XX.XX.12
                Session Name (s): Session Controller
                Connection Information (c): IN IP4 XX.XX.XX.46
                Time Description, active time (t): 0 0
                Media Description, name and address (m): audio 14996 RTP/AVP 0 101
                Media Attribute (a): rtpmap:0 PCMU/8000
                Media Attribute (a): rtpmap:101 telephone-event/8000
                Media Attribute (a): fmtp:101 0-15
                Media Attribute (a): ptime:20
                Media Attribute (a): sendrecv
               

    SDP for the 2nd 183
            Session Description Protocol
                Session Description Protocol Version (v): 0
                Owner/Creator, Session Id (o): Sansay-VSXi 188 1 IN IP4 XX.XX.XX.12
                Session Name (s): Session Controller
                Connection Information (c): IN IP4 XX.XX.XX.46
                Time Description, active time (t): 0 0
                Media Description, name and address (m): audio 15104 RTP/AVP 0 101
                Media Attribute (a): rtpmap:0 PCMU/8000
                Media Attribute (a): rtpmap:101 telephone-event/8000
                Media Attribute (a): fmtp:101 0-15
                Media Attribute (a): ptime:20
                Media Attribute (a): sendrecv

    SDP for the 200OK.
            Session Description Protocol
                Session Description Protocol Version (v): 0
                Owner/Creator, Session Id (o): Sansay-VSXi 188 1 IN IP4 XX.XX.XX.12
                Session Name (s): Session Controller
                Connection Information (c): IN IP4 XX.XX.XX.46
                Time Description, active time (t): 0 0
                Media Description, name and address (m): audio 15252 RTP/AVP 0 101
                Media Attribute (a): rtpmap:0 PCMU/8000
                Media Attribute (a): rtpmap:101 telephone-event/8000
                Media Attribute (a): fmtp:101 0-15
                Media Attribute (a): sendrecv
                Media Attribute (a): ptime:20

    Still working on the logs, But gather anything from that so far?
    In this case, asterisk always sent to the first provided RTP port of 14996.

    On Wed, Mar 3, 2021 at 12:06 PM Joshua C. Colp <jcolp@digium.com> wrote:
    On Wed, Mar 3, 2021 at 12:51 PM Nick Olsen <nick@141networks.com> wrote:
    Hello!

    I've got a number of asterisk systems running asterisk 16.12.0 currently. They're configured with PJSIP.
    Some of them are behind NAT, some aren't.
    All systems have SIP trunks to a Sansay INX.
    I've had one-way audio issues calling a particular number. After some investigation, It seems that the audio is lost due to port changes in SDP. Other calls don't seem to have any issues. Here's what happens.
    Good call:
    1. Asterisk sends invite to Sansay INX.
    2. Sansay replies 100 Trying without SDP.
    3. Sansay replies 183 Progress and provides SDP. This SDP specifies a Media server and Port. Let's say 192.168.1.2 and port 20100.
    4. RTP starts to exchange. Asterisk sending to 192.168.1.2 on port 20100.
    5. 200OK is received from Sansay, again it includes SDP showing 192.168.1.2 with port 20100 for RTP.
    6. Call works normally.
    Bad Call:
    1. Asterisk sends invite to Sansay INX.
    2. Sansay replies 100 Trying without SDP.
    3. Sansay replies 183 Progress and provides SDP. This SDP specifies a Media server and Port. Let's say 192.168.1.2 and port 20100.
    4. RTP starts to exchange. Asterisk sending to 192.168.1.2 on port 20100.
    5. 200OK is received from Sansay, This time, It includes modified STP, The IP is still 192.168.1.2, but the port is now 20180.
    6. Asterisk continues to send to SDP 20100.
    2nd example of bad call:
    1. Asterisk sends invite to Sansay INX.
    2. Sansay replies 100 Trying without SDP.
    3. Sansay starts sending RTP FROM 192.168.1.2 port 20100
    4. Asterisk starts sending RTP to 192.168.1.2 port 20100 (Even with force rport and comedia, and rewrite contact off, before we ever get the first SDP).
    5. Sansay replies 183 Progress and provides SDP. This SDP specifies a Media server and Port. Let's say 192.168.1.2 and port 20180 (This is a CHANGE from step 4).
    6. Asterisk is still sending to 192.168.1.2 port.20100 (Ignoring SDP in step 5 183 progress)
    7. 200OK is received from Sansay, Now a third port is received, The IP is still 192.168.1.2, but the port is now 20250.
    8. Asterisk continues to send to SDP 20100. (Ignoring SDP received at step 5 and 7)
    I'm hoping I'm missing a simple setting here like "Ignore SDP = no" in PJSIP. But I've not found it yet.
    Secondly, in all cases, Inbound audio (Sansay to asterisk) is fine. And the source port of RTP DOES change in both bad call examples above. But I assume asterisk is handling it because the traffic is still arriving on the same port from asterisk's point of view.
    Why calling this one particular number results in 2-3 SDP port changes I don't yet know. But from what I can see, It's not improper to have port changes in later SDP. And asterisk *should* follow them. But someone please correct me if I'm wrong.
    Actual SDP and Asterisk debug log would most likely be needed to see what is going on.

    Joshua C. Colp
    Asterisk Technical Lead
    Sangoma Technologies


    _____________________________________________________________________
    — Bandwidth and Colocation Provided by http://www.api-digital.com

    Check out the new Asterisk community forum at: https://community.asterisk.org/

    New to Asterisk? Start here:
          https://wiki.asterisk.org/wiki/display/AST/Getting+Started

    asterisk-users mailing list
    To UNSUBSCRIBE or update options visit:
       http://lists.digium.com/mailman/listinfo/asterisk-users

    –000000000000be493d05bca76559

  • One thing that does stand out is they aren’t obeying the RFC, as the version number in the o line should be incremented[1]. PJSIP is more tolerant of that though I believe. It did jog my memory though on an option[2][3] which may apply here. You’ll want to set it both in system and on the endpoint.

    [1] https://tools.ietf.org/html/rfc4566#page-11
    [2]
    https://github.com/asterisk/asterisk/blob/master/configs/samples/pjsip.conf.sample#L1096
    [3]
    https://github.com/asterisk/asterisk/blob/master/configs/samples/pjsip.conf.sample#L889

  • accept_multiple_sdp_answers=yes fixed it.

    It now follows SDP a total of 3 times in my tests.

    I had found this setting before posting. And had toggled it. But it didn’t make any difference until defined in system (in addition to the endpoint itself).

    Thanks for your help!