| Summary: | ASTERISK-20633: Asterisk SIP channel handling of MOH media re-INVITES not RFC 3264 compliant | ||||||
| Reporter: | sohosys (sohosys) | Labels: | |||||
| Date Opened: | 2012-10-31 00:58:06 | Date Closed: | 2012-11-19 09:33:32.000-0600 | ||||
| Priority: | Minor | Regression? | |||||
| Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability | ||||
| Versions: | 1.8.15.0 | Frequency of Occurrence | Constant | ||||
| Related Issues: |
| ||||||
| Environment: | asterisk 1.8.15.0 on CentOS 5 | Attachments: | ( 0) mohdebug.pdf | ||||
| Description: | When asterisk is connected to a SIP peer that uses a re-INVITE to place a call on Music On Hold, but omits the "a=sendrecv" tag in the SDP the handling of the SDP offer by Asterisk is not RFC 3264 compliant. This is the case when interoperating with Broadsoft Broadworks , Cisco Call Manager and presumably some other IP PBXs.
When the call is placed on hold the connected Broadworks platform first requests that the current media is stopped by sending a re-INVITE with a=”inactive” in the SDP. Asterisk accepts this SDP offer and starts MOH. The connected Broadworks platform then sends another re-INVITE with a new media endpoint IP address and port belonging to a media server that is streaming the MOH (this re-INVITE does not contain “a=sendrecv” in the SDP, but does contain a new media endpoint IP and port). Asterisk ACKs the SDP offer with “a=inactive” based on what appears to be logic that says “the media was previously inactive, and the re-INVITE does not explicitly request sendrecv, so we assume that the intention is to leave the media inactive”. According to RFC 3264 “If the offerer wishes to both send and receive media with its peer, it MAY include an a=sendrecv" attribute, or it MAY omit it, since sendrecv is the default.” The RFC compliant method of handling this SDP offer would be to evaluate each re-INVITE without regard to the previous media state and assume the default of sendrecv when there is no a=inactive, a=sendonly, or a=recvonly in the SDP. I have confirmed with both Broadsoft and Cisco that their products by design do not send a=sendrecv in the SDP when directing media to a media server to playback MOH or IVR prompts, and they both claim that this is RFC compliant, and the RFC supports their claims. | ||||||
| Comments: | By: sohosys (sohosys) 2012-10-31 01:07:05.161-0500 the attached sip debug has three items highlighted, the are; 1)asterisk starts MOH, 2)broadworks re-INVITES with the intention of establishing media to a media server, and 3) asterisk sends a 200 OK with an SDP containing a=inactive to a re-INVITE that should result in sendrecv media according to RFC 3264 By: Michael L. Young (elguero) 2012-11-02 00:27:45.187-0500 Can you try adding in sip.conf, ignoresdpversion=yes for the peer going to the Broadsoft and Cisco? I just looked at another issue for a Cisco device where the SDP session version is not being used/sent properly. In looking at your debug, I am seeing that the SDP session version is not being sent properly either. In fact, the whole "o=" line is not right when trying to re-INVITE Asterisk to the MOH stream. Let me explain. The invite from Broadsoft that changes the stream to "inactive" has this: o=BroadWorks 562265 2 IN IP4 172.16.18.130 c=IN IP4 172.16.18.130 a=inactive Asterisk sees that the SDP session version changed from "1" to "2" in the "o=" line. It therefore processes the SDP and therefore ACKS back showing that Asterisk has set the stream to "inactive" while increasing its own SDP session version by 1. From Asterisk: o=root 771287585 771287587 IN IP4 10.0.0.229 c=IN IP4 10.0.0.229 a=inactive The re-Invite from Broadsoft has the following: o=BroadWorks 562270 1 IN IP4 10.1.75.183 c=IN IP4 10.1.75.183 Notice that the "o=" line is different. That actually is not correct and I will paste below what RFC 3264 says about this. Ignoring that fact, Asterisk only looks at the SDP session version and it sees it set to "1". Since 1 is less than the previous version number that was 2, Asterisk ignores the SDP and ACKs back with the exact same SDP info as before. From Asterisk: o=root 771287585 771287587 IN IP4 10.0.0.229 c=IN IP4 10.0.0.229 a=inactive The Broadsoft device then takes the call off of hold and sends: o=BroadWorks 562265 3 IN IP4 172.16.18.130 c=IN IP4 172.16.18.130 a=sendrecv The increase in SDP session version to "3" triggers Asterisk to process the SDP. Remember from up above, the last modified SDP that Asterisk processed had the SDP session version at "2". Try setting ignoresdpversion=yes in sip.conf for this peer and let us know if that works. It will force Asterisk to process the SDP, ignoring the sdp session version. Here is what the RFC says in section 8 in regards to modifying the session. {quote} 8 Modifying the Session At any point during the session, either participant MAY issue a new offer to modify characteristics of the session. It is fundamental to the operation of the offer/answer model that the exact same offer/answer procedure defined above is used for modifying parameters of an existing session. The offer MAY be identical to the last SDP provided to the other party (which may have been provided in an offer or an answer), or it MAY be different. We refer to the last SDP provided as the "previous SDP". If the offer is the same, the answer MAY be the same as the previous SDP from the answerer, or it MAY be different. 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. If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number. The answerer MUST be prepared to receive an offer that contains SDP with a version that has not changed; this is effectively a no-op. However, the answerer MUST generate a valid answer (which MAY be the same as the previous SDP from the answerer, or MAY be different), according to the procedures defined in Section 6. {quote} So, that pretty much sums it up. The "o=" line MUST be identical except that the version in the origin field MUST increment by one from the previous SDP. That did not happen from what was sent from the Broadsoft. Therefore, Asterisk treated it as a no-op and responded back properly with the same previous SDP. By: Michael L. Young (elguero) 2012-11-19 08:59:06.245-0600 Did you get a chance to try this out yet? Please report back on what you found out. Thanks By: sohosys (sohosys) 2012-11-19 09:08:01.505-0600 Yes, and the setting ignoresdpversion=yes did provide a workaround. There is still some question around this. The vendors that we are trying to interop with disagree with the diagnosis that the problem is casued by the SDP version number not incrementing properly with the argument that when one of the endpoints in the media stream changes that a new session identifier with version 1 should be created. Both arguments have some validity at face value, and I have not been able to quickly find anything in the RFCs that clarifies this. Do you have an opinion on this or a reference to a RFC that supports the Asterisk position? By: Michael L. Young (elguero) 2012-11-19 09:20:53.528-0600 I quoted RFC3264 section 8 in my prior comment. I am not sure how much clearer it needs to be for those you are trying to interop with. All aspects of the session can be modified except for the following: the "o=" line which includes the SDP version. The "o=" line MUST be identical and the version MUST increment by one if there was a change from the previous SDP (the last SDP provided). Please take a look at the RFC3264 quote again in my prior comment for its full context. It seems pretty clear to me. {quote} If the offered SDP is different from the previous SDP, some constraints are placed on its construction, discussed below. {quote} {quote} 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. {quote} By: sohosys (sohosys) 2012-11-19 09:38:19.498-0600 So you maintain that even though a new invite (re-invite) to a different endpoint was sent that there is not a "new session" being established? I understand what RFC3264 is stating, but if you believe that changing one of the endpoints creates a new session it is irrelevant. If this is the belief then it only applies when one of the endpoints in an established media session wish to change the parameters of the established media session. I am not trying to be argumentitive, and I dont have a strong opinion either way, just trying to get everyone to see it the same way so we can all agree on what is right and what is wrong. I guess the definition of "session" as it is used in RFC3264 is the key. By: Matt Jordan (mjordan) 2012-11-19 10:11:53.241-0600 The fact that the destination IP address changed is immaterial. I'd argue that because the INVITE request containing the new destination IP address occurs within a dialog, i.e., it is a re-INVITE, it is hence part of the existing 'session'. RFC 3264 notes that the Offer/Answer model it describes exists within the context of a higher layer, i.e., SIP. It is SIP that determines the session, not the SDP contained in the SIP messages. Section 8.3.1 also notes that you can, within an existing session, modify the address/port/transport: {quote} 8.3.1 Modifying Address, Port or Transport The port number for a stream MAY be changed. To do this, the offerer creates a new media description, with the port number in the m line different from the corresponding stream in the previous SDP. If only the port number is to be changed, the rest of the media stream description SHOULD remain unchanged. The offerer MUST be prepared to receive media on both the old and new ports as soon as the offer is sent. The offerer SHOULD NOT cease listening for media on the old port until the answer is received and media arrives on the new port. Doing so could result in loss of media during the transition. Received, in this case, means that the media is passed to a media sink. This means that if there is a playout buffer, the agent would continue to listen on the old port until the media on the new port reached the top of the playout buffer. At that time, it MAY cease listening for media on the old port. The corresponding media stream in the answer MAY be the same as the stream in the previous SDP from the answerer, or it MAY be different. If the updated stream is accepted by the answerer, the answerer SHOULD begin sending traffic for that stream to the new port immediately. If the answerer changes the port from the previous SDP, it MUST be prepared to receive media on both the old and new ports as soon as the answer is sent. The answerer MUST NOT cease listening for media on the old port until media arrives on the new port. At that time, it MAY cease listening for media on the old port. The same is true for an offerer that sends an updated offer with a new port; it MUST NOT cease listening for media on the old port until media arrives on the new port. Of course, if the offered stream is rejected, the offerer can cease being prepared to receive using the new port as soon as the rejection is received. To change the IP address where media is sent to, the same procedure is followed for changing the port number. The only difference is that the connection line is updated, not the port number. The transport for a stream MAY be changed. The process for doing this is identical to changing the port, except the transport is updated, not the port. {quote} By: Michael L. Young (elguero) 2012-11-19 10:13:07.573-0600 Asking questions is a good thing. If you don't ask questions, you never learn or understand things. You are correct. Understanding what a "session" _is_, is very important. Therefore, from the SIP RFC3261, in reading it, it is clear about what a session is. Here are some quotes about re-INVITES under section 14 of RFC3261: {quote} 14 Modifying an Existing Session A successful INVITE request (see Section 13) establishes both a dialog between two user agents and a session using the offer-answer model. Section 12 explains how to modify an existing dialog using a target refresh request (for example, changing the remote target URI of the dialog). This section describes how to modify the actual session. This modification can involve changing addresses or ports, adding a media stream, deleting a media stream, and so on. This is accomplished by sending a new INVITE request within the same dialog that established the session. An INVITE request sent within an existing dialog is known as a re-INVITE. {quote} So, a re-INVITE is modifying an actual session that is already established. It is not establishing a new session. Under the section for UAC Behavior: {quote} If the session description format has the capability for version numbers, the offerer SHOULD indicate that the version of the session description has changed. {quote} Here it discusses the version number in the session description. It mentions that the version number should be used to indicate a change. RFC3264 defines how to use that version number, which I have quoted up above. That version number MUST increment, not start over at 1. We are not establishing a new session... we are modifying an existing one. The section for UAS Behavior: {quote} If a UA receives a re-INVITE for an existing dialog, it MUST check any version identifiers in the session description or, if there are no version identifiers, the content of the session description to see if it has changed. If the session description has changed, the UAS MUST adjust the session parameters accordingly, possibly after asking the user for confirmation. Versioning of the session description can be used to accommodate the capabilities of new arrivals to a conference, add or delete media, or change from a unicast to a multicast conference. {quote} Again, the RFC mentions using a version for the session description for changing media streams. The use of the version number is defined in RFC3264 as I have already quoted before. I hope this helps to clarify what a session is and how re-INVITES work. Essentially, a re-INVITE is modifying an existing session, not creating a new one. Therefore, the SDP version number should follow what is established in the RFC3264. By: Private Name (falves11) 2017-04-13 18:11:21.368-0500 I am facing this exact issue with Broadsoft, but I use PJSIP Asterisk version 13.5 Is there a workaround for this issue in PJSIP or I am bound to go back to old and obsolete technology? Thanks in advance for helping. PD I just confirmed that it works indeed with the SIP channel and the setting recommended here. | ||||||