[Home]

Summary:ASTERISK-06539: Problems with GROUP variables on SIP transfers
Reporter:nenadr (nenadr)Labels:
Date Opened:2006-03-14 04:25:26.000-0600Date Closed:2006-05-12 09:55:46
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Recently I have to start limiting number of calls to SIP phones using GROUP() and GROUPCOUNT() functions, because we have got SPA 941 phones on which you cannot disable CallWaiting feature. After a couple of days testing I have got on a conclusion that SIP Transfers do not handle GROUP variables properly. I have tested it with * 1.2.4, "macro-superdial" from Wiki for handling GROUP() and GROUPCOUNT(), and and using "group show channels" before, during and after transfer to see what is happening with group variables. Setup for test is: ext. SIP/209, ext. SIP/269 and ext.109 which is on Zap/g1 (E1 PRI). All SIP exts. are defined as friends and there is no call-limit in config.

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

First scenario:

I call from 209 to 269 (SIP to SIP call) and group show channels show:

Channel                    Group                 Category
SIP/209-8112               269                   (default)

I put 209 on hold and dial 109 from 269 (SIP to Zap)and group show channels shows:
Channel                    Group                 Category
SIP/269-4331               109                   (default)
SIP/209-8112               269                   (default)

Then I press transfer key on 269 (109 and 209 gets connected) and group show channels show:
Channel                    Group                 Category
SIP/209-8112               269                   (default)

and I cannot no longer call 269 although it is free for calls!


Second scenario:

I call 109 from 209 (SIP to Zap) and group show channels show:
Channel                    Group                 Category
SIP/209-e06a               109                   (default)

Then I put that call on hold and call 269 from 209 (SIP to SIP) and i get:
group show channels
Channel                    Group                 Category
SIP/209-53d5               269                   (default)
SIP/209-e06a               109                   (default)

Then I press transfer on 209 (Zap 109 and sip 269 gets connected) and I get:
group show channels
Channel                    Group                 Category
2 active channels

Now both SIP phones (209 and 269) can get new calls which is OK for 209 but it shouldn't be for the 269 because it is in conversation.
Comments:By: Olle Johansson (oej) 2006-03-29 16:21:00.000-0600

Check the OUTBOUND_GROUP dialplan variable in for app_dial().

Your are setting the INBOUND channel to belong to the callee's group. You want the OUTBOUND channel to belong to the callee's group and the INBOUND channel to belong to the caller's group.
By: nenadr (nenadr) 2006-04-03 00:50:39

oej: sorry, I didn't notice your post - it seems that Mantis doesn't send emails anymore when a new note is posted (at least I didn't got any mail from bugtracker in a while, and there was activity on bugs I monitor).

Anyway, I think I have tried testing with OUTBOUND_GROUP variable also, but with the same results. I'll try to do some tests with OUTBOUND_GROUP today again just to make sure, and I'll post both dialplan and the results.

I don't know is this relevant to the issue, but I was just looking at the chan_sip source for 1.2.4 - it seems to me that in SIP transfer attempt_transfer() is called, and it is calling ast_channel_masqarade() which doesn't call clone_variables() function, and that is the only function where GROUP variables are skipped in cloning process (ast_do_masqarade() does on the other hand) ?


By: Serge Vecher (serge-v) 2006-05-04 09:25:34

nenadr: how did your testing go?
By: Serge Vecher (serge-v) 2006-05-12 09:55:46

nenadr: if this issue is still reproducible in latest 1.2 branch (rev > 26000), please reopen the issue.

Thanks.