[Home]

Summary:ASTERISK-09378: atxfer target receives broken From SIP heaer
Reporter:Dmitry Andrianov (dimas)Labels:
Date Opened:2007-05-03 16:58:59Date Closed:2007-07-11 19:59:10
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 9661-small.patch
( 1) error2.txt
( 2) error3.txt
( 3) stdexten.txt
Description:Three participants:
 1001 (X-Lite, 192.168.7.239)
 1002 (eyeBeam, 192.168.7.239)
 1011 (X-Lite, 192.168.10.202)

Scenario:
1. 1002 calls 1001
2. 1001 accepts call
3. 1001 starts attended transfer (*2)
4. 1001 dials 1011
5. 1011 sees incoming call, callerID is complete garbage


****** ADDITIONAL INFORMATION ******

It is important who does transfer. If at step 3 caller instead of callee initiates atxfer, then target (1011) sees normal callerID. Only if callee initiates transfer, target sees garbage.
Comments:By: Olle Johansson (oej) 2007-05-04 08:25:44

Yes, that is garbage indeed. Can you please add a check of the callerid name in the dial plan before you dial out so we can see what the status is at that moment in the life of your call. Thanks.
By: Dmitry Andrianov (dimas) 2007-05-04 09:07:56

I have added stdexten.txt - the AEL stdexten macro thru which all internal calls go. I have added following lines per your request:

       NoOp(${CALLERID(name)});
       NoOp(${CALLERID(num)});
       NoOp(${CALLERID(all)});

Attached error3.txt with new dump. As I see, the lines above already display boken caller when doing transfer.

Let me know it I can help somehow else.
By: Olle Johansson (oej) 2007-05-09 08:49:15

This means it's not an SIP issue any more.
By: Dmitry Andrianov (dimas) 2007-05-09 19:39:16

But it is still an issue. I can not change category anyway.
By: Dmitry Andrianov (dimas) 2007-06-01 19:32:55

Ooookey, guys. There are many bugs here. Or maybe these are features :)

The garbage itself is caused by the ast_get_hint function which returns success even if ast_get_extension_app_data returned NULL (see the code).

I would suggest changing its code to something like:

int ast_get_hint(char *hint, int hintsize, char *name, int namesize, struct ast_channel *c, const char *context, const char *exten)
{
struct ast_exten *e = ast_hint_extension(c, context, exten);
if (!e)
return 0;

if (hint)
ast_copy_string(hint, ast_get_extension_app(e), hintsize);

if (name) {
const char *tmp = ast_get_extension_app_data(e);
if (!tmp)
return 0;

ast_copy_string(name, tmp, namesize);
}

return -1;
}


Which fixes garbage - now callerid(name) is empty now.

But that is not ideal solution too because theoretically this function can be used to ask both hint and name at the same time. And when it is unable to obtain name, it will fail although it actually obtained hint Ok.

Quick grep shows that this function actually is used only a few times to obtain either hint OR name, never together. To me it means this function needs to be split into two independent functions: something like ast_get_hint and ast_get_hint_name probably. In case of two functions the choice should you return success or failure is straightforward.
By: Dmitry Andrianov (dimas) 2007-06-01 19:37:23

Ah, and I said "many bugs" because my fix heals the problem with garbage but I still do not have proper callerid(name). It looks like this happens because all my phones register into one context ('default') while dial in another ('ael-default') which includes registration context. And asterisk looks for hints in the 'ael-default' context and does not find anything. Will need research a bit more.

So I would not close this issue even if you patch Asterisk against initially reported garbage...


By: Dmitry Andrianov (dimas) 2007-06-02 08:08:21

Finally, I read doxygen for ast_get_hint and it clearly says it returns nonzero if hint exists. Which means my initial suggestion how to fix the code was wrong - it will break function's contract.

I'm attaching better (I hope) patch against 1.4 branch - 9661-small.patch. It just makes sure that if someone calls ast_get_hint asking for name AND hint extension exist BUT there are no name, function will be returning success (as per doxygen) but will put empty string into the buffer.


What I do not understand completely is why app_dial.c function get_cid_name uses ast_get_hint at all. I believe everybody expect name (in the case of SIP, cid_name, comming from users.conf for example) but why hint???
Should I fill another issue with that?
By: Joshua C. Colp (jcolp) 2007-06-04 13:00:40

Fixed in 1.4 as of revision 67066 and trunk as of revision 67067 a little differently. The function just expected the buffer to already be cleared out, as for your other issue please feel free to open an issue with all available information and details.