asterisk users - Aug 2013 - Asterisk 11.5 not honoring RTP port change in RE-INVITE

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20130826/16bcf3fa/attachment.htm>

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