Asterisk 11.5 Not Honoring RTP Port Change In RE-INVITE

Home » Asterisk Users » Asterisk 11.5 Not Honoring RTP Port Change In RE-INVITE
Asterisk Users 2 Comments

I have an Asterisk 11.5 system, using SIP Realtime and operating as a ITSP. One of my customer’s endpoints is a NetVanta 7100 PBX system that has a SIP trunk connection to my Asterisk box. The NV 7100 has a public IP on it that doesn’t have any NAT between it and my Asterisk system. When the customer transfers a call from one handset to a voicemail box, the NV 7100 sends a RE-INVITE to Asterisk with SDP information for a different RTP port number. Asterisk is ACKing the RE-INVITE, but never changes media over to the new port number.

AdTran is saying it’s Asterisk’s problem, since the Wireshark trace shows Asterisk is ACKing the re-invite but not changing ports. I do see that the Session ID number is different in the two invites (the REINVITE has a higher ID number than the original 200 OK that sets up the call – my test call was inbound to the NV7100). However, the REINVITE’s version number is lower (1) than the 200 OK’s SDP version number (which was the same as the SDP Session ID number). I see in the sip.conf.sample file that “By default, Asterisk will honor the session version number in SDP packets and will only modify the SDP session if the version number changes”. Given that I don’t have ignoresdpversion=yes either globally or for this peer, does this mean that Asterisk will only honor new SDP packets if the version is higher, or will it honor any change? Or should I be looking somewhere else?

Thank you,

Noah Engelberth MetaLINK Technologies

2 thoughts on - Asterisk 11.5 Not Honoring RTP Port Change In RE-INVITE

  • —– Original Message —–

    You have pretty much found what the issue is. The AdTran is not properly incrementing the SDP version.

    Look at the comments on these issues for clarification on why Asterisk is actually following the RFC3264:

    https://issues.asterisk.org/jira/browse/ASTERISK-20633
    https://issues.asterisk.org/jira/browse/ASTERISK-20642
    https://issues.asterisk.org/jira/browse/ASTERISK-21411

    RFC3264
    “If the offered SDP is different from the previous SDP, some constraints are placed on its construction, discussed below.”

    “Nearly all aspects of the session can be modified. New streams can be added, existing streams can be deleted, and parameters of existing streams can change. When issuing an offer that modifies the session, the “o=” line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST
    increment by one from the previous SDP.”

    Therefore, in order to work with devices that do not handle the SDP version properly, sip.conf has the “ignoresdpversion” option.

    Michael
    (elguero)

  • Thank you for your reply. I figured that was what was happening, but didn’t know of a good place to go looking so I could forward the right information on to NetVanta support. I appreciate you taking the time to provide me that information.

    Thank you,

    Noah Engelberth System Administration MetaLINK Technologies nengelberth@team-meta.net
    419-990-0342