----- Original Message ----- > From: "Noah Engelberth" <nengelbe...@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) -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
