Summary:	ASTERISK-22069: unexpected absence of connectedline update if set before answering
Reporter:	Birger "WIMPy" Harzenetter (wimpy)	Labels:
Date Opened:	2013-07-11 18:17:11	Date Closed:	2013-07-24 18:34:36
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Channels/chan_iax2
Versions:	SVN	Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) iaxdebug
Description:	chan_iax does not send connectedline information on answer if the CONNECTEDLINE function has been used with ",i". As the connectedline information isn't useful before answer, the presence or absence of ",i" shouldn't make a difference at that point. (At least) On chan_sip it actually doesn't make a difference.
Comments:	By: Rusty Newton (rnewton) 2013-07-16 19:45:56.068-0500 Please attach: * An Asterisk log with "iax2 set debug on" , VERBOSE, DEBUG turned up to 5 * An IAX pcap covering the same call as shown in the Asterisk log * Relevant dialplan and iax.conf config By: Matt Jordan (mjordan) 2013-07-16 21:22:00.574-0500 I'm not surprised this was broken in trunk at this point. Connected Line was pretty much in a non-working state in trunk due to the bridging architecture changes until r394249, which is when Josh merged in the COLP changes for two-party bridges. If you re-test with trunk after that point, do you get the same behavior? By: Birger "WIMPy" Harzenetter (wimpy) 2013-07-16 22:44:49.286-0500 It worked in all other situations. I think I should find time for testing tomorrow. By: Birger "WIMPy" Harzenetter (wimpy) 2013-07-18 20:42:32.291-0500 Ok, when reading more carefully the situation is not exactly what I expected. The IAX debug shows two calls, the first only uses CONNECTEDLINE with ",i" and sends no CNLINE. The second call uses CONNECTEDLINE without ",i" and does send a CNLINE. However it does so *before* ANSWER. That doesn't seem to make sense. But on further thought, maybe it has to be done this way with IAX? This was today's SVN version. By: Matt Jordan (mjordan) 2013-07-19 11:57:00.831-0500 So, after some inspection, I think that is expected behavior. The {{i}} is the inhibit flag - which is to say, "I want to set connected line information, but I don't want to send it yet". From the [wiki page on COLP|https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information]: {quote} It is up to the channel technology to determine when to act upon connected line updates before the call is answered. ISDN will just store the updated information until the call is answered. SIP will immediately update the caller with a Re-INVITE. Since the connected line information can be sent while a call is connected, you may need to prevent the channel driver from acting on a partial update. The 'i' option is used to inhibit the channel driver from sending the changed information immediately. {quote} Granted, that doesn't explicitly call out IAX. However, from some inspection, its behavior does appear to be to send a CNLINE update immediately upon receiving a connected line update control frame. That control frame is created by the {{CONNECTEDLINE}} function when set without the {{i}} option - and any call to it that does not specify the {{i}} option will trigger a full update of connected line information on that channel. You should also get an automatic update when you get bridged or transferred, but that's the "normal" updates. So: I don't think there is a bug here, but just the way that IAX happens to handle connected line. By: Birger "WIMPy" Harzenetter (wimpy) 2013-07-19 12:17:07.662-0500 Ok, when looking for CONENCTEDLINE on the wiki, I didn't end up there. But the information there is inconsistent. First it says "to be sent when the call is answered", which is what I'd expect as well and the section name of "COLP" seems to imply. Then it says "SIP will immediately update the caller with a Re-INVITE" which is not the behavior I see. chan_sip will also just store the information and send it out once the call is answered, just like the first paragraph says and which seems logical to me. So if only for consistency of behavior between channeltypes, I think chan_iax2 should do it the same way. By: Matt Jordan (mjordan) 2013-07-20 17:55:20.491-0500 I understand there may be a lack of consistency as to the timing of IAX2's sending of COLP versus some other channel driver. Is there a behavioral problem that is occurring? That is, does the endpoint communicating over IAX2 not display connected party information when it should, or does it display it too soon? By: Birger "WIMPy" Harzenetter (wimpy) 2013-07-22 17:27:46.312-0500 I guess it might be viewed as expected behavior of Answer() in some way. As connected line information doesn't make sense before the call is answered, the presence/absence if ",i" to CONNECTEDLINE should probably not make any difference as the information is actually sent when the call is answered. That's what chan_sip and chan_dahdi do, but chan_iax2 differs. I'm not sure about the structure of IAX and if ANSWER and CNLINE need to be transmitted as separate messages. But even if it has to happen before answering the call internally, it would be goo if that was invisible to the user. By: Rusty Newton (rnewton) 2013-07-24 17:48:39.513-0500 If you update CONNECTEDLINE with ",i" before the call is answered, does chan_iax2 send out a CNLINE? By: Birger "WIMPy" Harzenetter (wimpy) 2013-07-24 17:56:24.517-0500 No, it doesn't. That was the whole point. (and the first line of this issue) By: Rusty Newton (rnewton) 2013-07-24 18:33:48.548-0500 The first line of the description says: bq. chan_iax does not send connectedline information on answer if the CONNECTEDLINE function has been used with ",i". This says "on answer", not, before. A few of the comments had me confused as to the entire scope of your concern. The summary line (not description) doesn't specify with or without the ",i" option. It sounds like the behavior is expected from Matt's analysis and what is documented on the wiki. Without the ",i" it should send it out and update immediately and if it is before the call is answered then it's up to the particular channel technology. I'm going to close this out as Not a Bug, but if you think the behavior should change feel free to file a feature request with a patch to change the behavior of chan_iax2 and when it will or won't send out the CNLINE in respect to call state. By: Rusty Newton (rnewton) 2013-07-24 18:36:44.461-0500 If the discussion needs to continue then let's do that on the dev list so others can more easily get involved. We can always re-open this issue if the consensus is that this is more buggy and less a desired change in expected behavior.