Our SIP service provider has suggested that audio is failing on some of our outbound calls as Asterisk is not sending RTP to the IP they have sent in the 200 OK, and instead, it’s incorrectly sending it to the IP they sent in the 183 Session Progress. They have advised that Asterisk should use the IP address from the most recent packet containing SDP information. They have confirmed that one of their devices is sending an incorrect RTP IP address in the SDP of the 183 Session Progress, but they then send the correct RTP IP address in the 200 OK - however, our system should automatically navigate around this problem. Any suggestions or pointers as to where I should be looking to correct this would be very much appreciated. Thanks.
Check the sequence numbers in the SDP. It sounds like they are failing to update the sequence number correctly.
If so, there is a work around for chan_sip, by using ignoresdpversion.
2 Likes
Thanks this seems like it’s exactly the problem! The version numbers of the sessions are identical whereas they should be increasing (and typically I thought they used timestamps - is this not the case?)
Is your 183 reliable? If so then your provider is wrong. From rfc3261 Section 13.2.1 second bullet point:
If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specification, that is
only the final 2xx response to that INVITE. That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer. The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE.
According to the RFC the first reliable response containing an SDP is to be used. Subsequent ones are ignored.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.