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.
On Wed, Mar 3, 2021 at 12:06 PM Joshua C. Colp <jcolp at digium.com>
wrote:
> On Wed, Mar 3, 2021 at 12:51 PM Nick Olsen <nick at 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
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _____________________________________________________________________
> -- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20210303/c316fd61/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 118155 bytes
Desc: not available
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20210303/c316fd61/attachment-0001.png>
Joshua C. Colp
2021-Mar-03 22:20 UTC
[asterisk-users] Asterisk not following SDP port change
On Wed, Mar 3, 2021 at 5:55 PM Nick Olsen <nick at 141networks.com> wrote:> > 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. >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 -- Joshua C. Colp Asterisk Technical Lead Sangoma Technologies Check us out at www.sangoma.com and www.asterisk.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20210303/c2ad215e/attachment.html>