[asterisk-users] Asterisk 11.5 not honoring RTP port change in RE-INVITE

[Michael L. Young]

----- Original Message ----- 

> From: "Noah Engelberth" <nengelberth at team-meta.net>

> 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?

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)