| Summary: | ASTERISK-21673: Asterisk conversion of 183 without SDP to 180 breaks interoperability with Microsoft Lync | ||||||
| Reporter: | dcitelecom (dcitelecom) | Labels: | |||||
| Date Opened: | 2013-04-23 13:00:29 | Date Closed: | 2013-04-25 17:58:26 | ||||
| Priority: | Major | Regression? | |||||
| Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability | ||||
| Versions: | 11.3.0 | Frequency of Occurrence | |||||
| Related Issues: |
| ||||||
| Environment: | FreePBX distro 3.211.63-7 Centos 6.3, Asterisk 11.3.0 | Attachments: | ( 0) Early_media_Asterisk_11_log.txt | ||||
| Description: | Voxbone DID (defined in inbound routes) is sent out to customer trunk ABCco (TCP) trunk. They reply with 183 session progress (early media announcement) and Asterisk sends 180 ringing back to Voxbone.
This is problematic where the DID is forwarded to a cell phone and the phone is off or the forwarding number was entered wrong. In both cases the user should hear an early media announcement that the user is not available or the number is not in service. Instead they hear a ring tone and don't know there is a problem. Log attached {noformat} DIALPLAN exten => #0216479999999,1,Set(__FROM_DID=$ {EXTEN} ) exten => #0216479999999,n,Gosub(app-blacklist-check,s,1()) exten => #0216479999999,n,Gosub(sub-record-cancel,s,1()) exten => #0216479999999,n,Set(__REC_POLICY_MODE=never) exten => #0216479999999,n,Set(CDR(did)=$ {FROM_DID} ) exten => #0216479999999,n,ExecIf($[ "$ {CALLERID(name)} " = "" ] ?Set(CALLERID(name)=$ {CALLERID(num)} )) exten => #0216479999999,n,Set(CHANNEL(musicclass)=none) exten => #0216479999999,n,Set(__MOHCLASS=none) exten => #0216479999999,n,Set(__CALLINGPRES_SV=$ {CALLERPRES()} ) exten => #0216479999999,n,Set(CALLERPRES()=allowed_not_screened) exten => #0216479999999,n(dest-ext),Goto(ext-trunk,5,1) {noformat} {noformat} [ABCAsia] (trunk 5) disallow=all type=peer host=202.xxx.xxx.xxx transport=tcp allow=alaw allow=ulaw relaxdtmf=yes dtmfmode=rfc2833 directmedia=yes context=from-ABCco-HK {noformat} | ||||||
| Comments: | By: dcitelecom (dcitelecom) 2013-04-23 13:01:18.526-0500 debug By: Michael L. Young (elguero) 2013-04-23 16:36:09.846-0500 I think the problem is that we get a 183 Session Progress without SDP from your customer's Lync server. Therefore, we treat it as a 180. By: dcitelecom (dcitelecom) 2013-04-24 14:33:29.665-0500 From what I understand this this treatment isn't compliant with the standard. 183 should always be passed on as 183. SDP in 183 should not be the basis for playing the ring back tone for it's the SDP in the 180 that should be the basis. Lync sends the 180 later if it is able to ring the endpoint. Can this be accepted as a bug in Asterisk and resolved? Otherwise Asterisk is not Lync compatible which is kind of important. Thanks. By: Michael L. Young (elguero) 2013-04-24 17:18:36.119-0500 Well, it is hard to answer. I did a bunch of research before replying and I found comments indicating that Lync, for whatever reason, has decided to do something that most commercial implementations do not do; send 183 without SDP. I even found a Microsoft forum post where someone was asking about this and the response was basically "is the application Lync certified? Make sure to only use Lync certified apps." I am paraphrasing that. I could not find anything stating that 183 _has_ to contain SDP. I think that is where the sticky point is. There are some PBX servers out there that send 183 without SDP kind of like a "keepalive" while it is Trying. That is why Asterisk currently ignores 183 without SDP due to one of those servers according to the comment in the code. Everything I could find expects 183 to have SDP and I could not find anything stating how to handle 183 without SDP. I even found where perhaps some PBXes send 183 with SDP after a 100 Trying and then afterwards send 183 without SDP. If Lync was doing that, then we could handle that easily. Here is how understand things based on what I have read and going back to the source, that being RFC 3261. From RFC 3261: {quote} 13.2 UAC Processing 13.2.1 Creating the Initial INVITE ... There are special rules for message bodies that contain a session description - their corresponding Content-Disposition is "session". _SIP uses an offer/answer model_ where one UA _sends a session_ _description, called the offer,_ which contains a proposed description of the session. The offer indicates the desired communications means (audio, video, games), parameters of those means (such as codec types) and addresses for receiving media from the answerer. The other _UA responds with another session description, called the_ _answer,_ which indicates which communications means are accepted, the parameters that apply to those means, and addresses for receiving media from the offerer. An offer/answer exchange is within the context of a dialog, so that if a SIP INVITE results in multiple dialogs, each is a separate offer/answer exchange. The offer/answer model defines restrictions on when offers and answers can be made (for example, you cannot make a new offer while one is in progress). This results in restrictions on where the offers and answers can appear in SIP messages. In this specification, offers and answers can only appear in INVITE requests and responses, and ACK. The usage of offers and answers is further restricted. ... {quote} (I added italics around some of the key points.) Basic SIP depends on an Offer/Answer model. Asterisk is making an offer and Lync is never answering. How is Asterisk to establish a media connection if it doesn't know that the other endpoint has accepted the offer? {quote} 21.1.5 183 Session Progress The 183 (Session Progress) response is used to convey information about the progress of the call that is not otherwise classified. The Reason-Phrase, header fields, or message body MAY be used to convey more details about the call progress. {quote} This doesn't necessarily mean automatically that there is going to be Early Media. 183 means Session Progress not Early Media, although it can be used for that I guess and that is how I have commonly heard 183 referred to by. Unless I am missing something. I would be glad to hear from someone else though in regards to this. My comment above was just pointing out why this was happening in Asterisk and that there seems to be a good reason why it is being handled this way. It seems that if someone wants early media the most common way to do so is to have 183 with SDP (the answer). By: David Woolley (davidw) 2013-04-25 08:06:34.340-0500 This may be relevant: From 1.6.1 to 1.6.2: * SIP no longer sends the 183 progress message for early media by default. Applications requiring early media should use the progress() dialplan app to generate the progress message. http://svn.digium.com/svn/asterisk/branches/1.6.2/UPGRADE.txt Also, Asterisk is a back to back user agent, and so there is no standard that says that packets received from one of the two user agents should be forwarded by the other. Any requirement to forward 183 only applies to proxies. By: dcitelecom (dcitelecom) 2013-04-25 08:20:19.341-0500 For me this issue is more about interoperability than standards. The progress() application in the dialplan does not work in this case and there is currently no way in Asterisk to make this work. Lync (and many other PBX's) send 183 Session Progress without SDP so Asterisk treats it as 180 instead of 183. This behavior is debatable but my goal is simply for Asterisk to work with Lync and the easiest way to do this would be to have a trunk variable in Asterisk (sip.conf I guess) on how to treat 183 session progress. The default could be as it is now and the other option would be to always respond to 183 with 183. That way Asterisk could be configured on a per trunk basis to be compatible with every PBX out there and the change would not affect current configurations. Since Asterisk 11 is still very much in development this seems to me a very desirable option and if you google the issue it seems this affects many Asterisk users not just us. By: Michael L. Young (elguero) 2013-04-25 09:06:21.763-0500 Asterisk 11 is not in development... that would be Asterisk 12. New features will not go into Asterisk 11. The only problem I see is that we never negotiate a media session with Lynx. We make an offer but they never tell us that they accept that offer. Does Lync support the preferred audio codec that we offered? How is Asterisk to know which codec to use for the media stream? Is Asterisk supposed to just _assume_ that what it offered was acceptable and start accepting media? I could foresee a whole bunch of support issues caused by that. I wonder which PBXs you refer to when you say "many other PBX's"? I would think those other PBXs would show up when doing research and the only PBX that popped up in my search was Lync. I saw a post out there were someone modified their PBX / SIP Proxy (not sure if they were using Asterisk, a different PBX or a SIP proxy) to handle working with Lync by detecting that they were communicating with Lync server. Unfortunately, they felt they couldn't share it as it was a "trade secret". It is sad that Lync decided to do things their own way instead of what is being done in the real world. I make that comment solely based on the reading I have done on this subject of 183 with or without SDP. If what you are looking for is a feature to be added to allow this on a per peer or global basis, then we need to have a patch attached to this issue or, if you do not have a patch, discuss this openly (which would reach a greater audience) on the mailing lists (http://www.asterisk.org/support/mailing-lists). We do not accept feature requests without a patch on the issue tracker. Hope you don't feel that I am trying to shoot this down. As you can see, it is not a simple thing to just turn on or an easy policy change. By: Matt Jordan (mjordan) 2013-04-25 09:15:19.692-0500 This is most likely running into the patch provided for ASTERISK-14412. Ironically, that patch was provided for interoperability as opposed to standards (I sense a pattern here...), but has caused interoperability problems with other PBXs. There have been a few other complaints about this behavior. As an aside, any time you think "we should change this just for interoperability reasons", it's good to err on the cautious side. Essentially, Alcatel PBXs would send us a 183 with no SDP. This caused issues in that Asterisk would ignore the message and we would fail to indicate ringing or MoH to the other side. As a result, we decided to just treat it as a 180 Ringing. As Michael has alluded to, changing this behavior to accommodate Lync would break our interoperability with legacy Alcatel PBXs. Solving an interoperability problem with Lync would simply break someone else. As much as I hate *yet another* lever in Asterisk to pull, this should probably be configurable somehow - either we treat 183 with no SDP as a 180, OR we transmit a 183 session progress to the other side. By: dcitelecom (dcitelecom) 2013-04-25 09:46:04.433-0500 Yes. It should be configurable. Lync has a fairly large (growing) user base and it would kind of make sense to be compatible with them. I do not propose to change the legacy behavior of Asterisk as that would break compatibility with other PBXs. A flag to simply let the user decide how to handle 183 would not break anything and (in my case) fix the issue. Of course if this can only be considered for Asterisk 12 then I don't know what to do as we unfortunately need a solution now. I just wanted to get this to work. If I had a patch I would gladly share it but then I wouldn't really have a problem. It's unfortunate that there seems to be no way currently to get this to work. By: Rusty Newton (rnewton) 2013-04-25 17:57:38.291-0500 The consensus here is that this is not a bug, but essentially a feature request for interoperability functionality between Asterisk and Microsoft Lync (possibly other systems unamed). Since we don't generally accept feature requests without a patch I'm going to close this out as Suspended until someone provides a patch. As you mentioned this feature would not be released in Asterisk until Asterisk 12 (that does not necessarily mean that the patch wouldn't be compatible with 11, if you wanted to run a backported version..) Here's more information on our [New Feature Process|https://wiki.asterisk.org/wiki/display/AST/New+Feature+Process]. For further discussion and if you want to try to find someone to write a patch for you - I recommend bringing this feature request up on the asterisk-users and asterisk-dev lists. asterisk-dev is probably the best place to find a dev who may be interested. Some members of the community even offer [bounties|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties] on their bugs to increase the incentive for getting help. If you or someone else starts working on the issue and provides a patch you can feel free to comment on here, the asterisk-dev list or the #asterisk-bugs IRC chatroom to have the issue re-opened. By: dcitelecom (dcitelecom) 2013-04-26 23:32:12.810-0500 Apparently sending PRACK (100rel) in the initial invite would force Lync to send 183 with SDP. Unfortunately does not offer PRACK in the initial invite when prack is enabled in the trunk. Asterisk currently only accepts PRACK but does not initiate it. Is that something that could be changed in Asterisk 11 for interoperability with Lync? By: Michael L. Young (elguero) 2013-04-26 23:49:17.775-0500 Olle has a branch with PRACK support for Asterisk 11. http://svnview.digium.com/svn/asterisk/team/oej/darjeeling-prack-11/ Maybe that has what you need? By: dcitelecom (dcitelecom) 2013-04-26 23:59:42.603-0500 Isn't this already in Asterisk 11? I can see PRACK supported in the trunk facing Lync when I use the setting "prack=yes" but only when Lync initiates the call with PRACK in the invite. My problem is that Asterisk does not offer PRACK in the initial invite. How would I contact them if I want to offer a bounty for the change? By: Rusty Newton (rnewton) 2013-04-29 19:06:37.130-0500 {quote} How would I contact them if I want to offer a bounty for the change? {quote} https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties [OEJ|https://wiki.asterisk.org/wiki/display/~oej/Home] is often in #asterisk-dev (irc.freenode.net) as "oej". Bounties are for incentive on bug resolution. A bounty may help get code written, but whether a specific feature or feature set actually gets put into Asterisk depends on many other factors decided upon by the Asterisk development team. Hence the links I provided on the https://wiki.asterisk.org/wiki/display/AST/New+Feature+Process | ||||||