Linksys SPA9X2 conference bridge problems

Unanswered Question
Jan 25th, 2009
User Badges:

Hello,


I'm selling/renting Linksys/Cisco phones with various SIP servers. I have seen the following behaviour with SPA942 and SPA962 when using 6.1.3a fw and conference bridge URL. When the third person is reached and there are two calls on hold, conf soft key is pressed. An INVITE to conf bridge ([email protected]) is sent for a phone which started the conference and two REFERs for other parties are originated. REFERs however have  Refer-To header point to the contact (sip:<IP ADDRESS of conf bridge>) and not to the conf bridge URL. I thought this was due to option "Refer-To target contact" being set to "Yes", so I set this option to "No", but same behaviour continued. For SIP servers which are B2BUA and not proxies this behaviour is wrong and not possible to work with, therefore I think this is bug that should be fixed.


I will attach the SIP traces with needed data.


Regards,

Ognjen

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Patrick Born Mon, 01/26/2009 - 19:29
User Badges:
  • Cisco Employee,

Hi Ognjen,


I forwarded your message and traces to our system test team. They ran two scenarios and both scenarios yielded the appropriate refer to contents in the header of the REFER messages. They feel that they were unable to reproduce the issue that you're experiencing. Here's a note from them, describing their test scenario in a softswitch environment, "There are 2 ways to make conference calls.  One using the 'conflx' and one using the 'conf' softkey.   For 'conflx' softkey, the user makes the 2 calls then presses the 'conflx' only once to connect the 2 calls.  For 'conf' softkey, the user makes the first call, presses the 'conf' key to make the second call, and then presses the 'conf' key again to complete the 3-way conference.


Scenario 1 (conflx softkey)

1)  A calls B and B answers

2) A puts B on hold then calls C and C answers

3) A presses the 'conflx' softkey to join the 3 parties.

if A wants to join a 4th party, say D then A calls D then press the 'conflx'. 

Scenario2 (conf softkey)

1) A calls B and B answers

2) A presses 'conf' softkey to call C

3) A presses 'conf' softkey again to join the 3 parties

If A wants to join a 4th party, say D then A presses the 'conf' key again to call D and presses 'conf' again to join the 4 parties."




If you wish to escalate the issue that you're experiencing, please contact the Cisco Small Business Support Center nearest you:
http://www.cisco.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html


Regards,



Patrick

----------

o.seslija Tue, 01/27/2009 - 01:24
User Badges:

Hello,


I have problems using external conference bridge URL, not integrated 3-way conference (the Conference bridge URL option is used for this as [email protected] where domain need not to be a local one). I tried using conf key as well as conflx key. The party which starts the conference is put on the conference and the other two parties which are REFERed are not. This is due to fact that REFER is sent to the AOR (SIP contact of the of the conf bridge discovered during INVITE to it), and not to the URL itself (this is ok if proxy is used but cannot be used if B2BUA is used like FreeSWITCH or Asterisk). Please check the REFER and Refered-To headers, it is clear that they point to the Contact of SIP UA which was "talking" to the phone.

Which softswitch did you test it with? Is it a proxy or B2BUA?


Regards,

Ognjen

Patrick Born Tue, 01/27/2009 - 07:32
User Badges:
  • Cisco Employee,

Hi ,


I've opened up CSCsx29152 in the Cisco Defect & Enhancement Tracking System [CDETS] in order to have the problem appropriately assessed and addressed.


I'll keep you posted on progress. Feel free to contact me at paborn at cisco if you want a progress update.


Regards,



Patrick

----------

Patrick Born Tue, 01/27/2009 - 13:31
User Badges:
  • Cisco Employee,

Hi Ognjen,



I've heard back from Engineering and the test team.

Here's what they said, "The behavior is correct; our implementation is based on softswitch/conf-bridge implementation, which many other soft switch companies follow.

We have to force Refer-To to use contact, not configurable, or this option will not work (if someone mis-config'd).


... ... A partner who wishes to implement their own solution should follow same compatible method instead of insisting on doing it their own way. SIP is a very wild standard; you can do very different things but still claim it's compliant. To support non-compatible conf bridge needs to be studied.

FYI, I would take this as a feature enhancement."


I noticed that the test team had used an unreleased version of phone code and also shared your response with them. They responded with, "We retested with the conf controller on 6.1.3(a) while leaving all other parties on 6.1.5 since it's the controller that's in question.

Here are the results:

Using conf soft key and connecting 4 parties (controller + 3 others) ==> Passed

Using conf_Lx and connecting 3 parties ==> Passed

Using conf_Lx and connecting 3 parties then added 4th also via conf_Lx ==> Passed

Audio was confirmed on all lines. 

Msg Trace showed REFER formulated correctly.

We are testing Broadsoft Rel14sp5 as B2BUA."


In summary, bugid "CSCsx29152" will be closed as "not a bug" but the feature request is on Voice Engineering's to-do list.


Regards,



Patrick

--------


Message was edited by: Patrick Born

Patrick Born Wed, 01/28/2009 - 10:51
User Badges:
  • Cisco Employee,

Hi Brian,


In our implementation, the B2BUA knows beforehand, which conference to place calls into when they are referred to the server.


Here's how it is designed to work in our implementation:

The conference controller UA sends to the B2BUA server, an INVITE to the conference call.

The B2BUA waits for the REFERs.

Once the REFERs are received, we invite all the other parties.


Our goal is to provide a working solution for our customers, to this end, I'm requesting a feature enhancement to address this situation.


Thanks for your participation.


Regards,



Patrick

----------

briankwest Wed, 01/28/2009 - 11:11
User Badges:

That is not the behavior we are seeing.  We are seeing the phone call the conference URI which in this case is [email protected], The other two calls are referred back to the b2bua with the refer-to incorrectly set.  It should be setting the refer-to to the conference URI when doing the refer.  There is no other way to know which conference to use otherwise.  This isn't a feature enhancement... it should already put [email protected] which is the Conference URI into the Refer-to header when sending the refer.  Otherwise you're left guessing what conference to place the call in since the phone sends the Refer to transfer the caller its at fault.


Example we see this:



variable_sip_h_Referred-By: []

variable_sip_refer_to: []


That Refer-To header is WRONG.. The SPA962 calls [email protected] then a refer is sent referring the other legs to [email protected] which is WRONG.


I'm trying to point out this IS a bug.  I don't get how the B2BUA going to know which conference to refer to when the refer is WRONG.


/b




o.seslija Tue, 01/27/2009 - 17:03
User Badges:

Hello,


thanks for the reply. What is the standard for the conf bridge implementation that is mentioned here? Is there some docs about that?

If that option is misconfigured for the Nortel/Cisco I guess you can document that, like you document everything else (Set refer-to to contact for Cisco/Nortel; set to URL for anything else). I don't see how is this behaviour SIP compliant; how can this packet be parsed to end up in the proper extension/server which does conferencing? SRTP was non-compliant for ages and you guys made IETF SRTP to work after popular demands.

Why is this option made to work with any other vendor I've tested with (Snom, Aastra)? Why is the conference bridge URL not said to work only with Cisco/Nortel anywhere in the docs?

I'm really disappointed for the clear admittance that Refer-To header is sent totally non-compliant because it has to comply to Cisco/Nortel, and you are calling this behaviour a proper one. I know that FreeSWITCH developers cope everyday making workarounds for not-compatible equipment. It's a shame to be a case with Linksys cause it's really popular brand of phones.

I don't sell Cisco/Nortel switches nor I will most probably, cause I have market for open-source products installations and I will continue to do so. I really want to continue sell Linksys gear so please help me.


Regards,

Ognjen

Patrick Born Wed, 01/28/2009 - 11:09
User Badges:
  • Cisco Employee,

Hi Ognjen,


I've shared your comments and concerns with our quality test team, the engineering team, product management, and the documentation team.

Thanks for your concern and constructive input.


Our goal is to help you be successful selling and using our products, so I appreciate you describing the challanges you experience.


Regards,



Patrick

----------

o.seslija Wed, 01/28/2009 - 11:50
User Badges:

Hi Patrick,


thanks for the reply and your thoughts. I'm trying to make my users feel more comfortable to use Linksys phones, hence all these questions. FreeSWITCH as a very fast developing product is gaining popularity amongst the users, so it's a very big mistake to just not support it imho. I know that the FS developers (like Brian) are very open-minded and dedicated to SIP compliance. That being said, I would like to ask you to go to IRC #freeswitch channel sometimes and chat with us, so we can help each other.


Regards,

Ognjen

Moderator Tue, 02/03/2009 - 06:57
User Badges:

Hi Ognjen,


If you are satisfied with the answers to your questions, could you please take a moment to mark the thread as answered? Using this system will help other users who have similar needs as you.


Thank you,


Cisco Moderation Team

o.seslija Tue, 02/03/2009 - 07:07
User Badges:

Hi,


I'm still waiting for the replies for the discussion that was continued privately between Patrick and myself.


I can close this, but this issue is still being discussed afaik.


Regards,

Ognjen

Patrick Born Tue, 02/03/2009 - 08:29
User Badges:
  • Cisco Employee,

Moderator,


This issue is still undergoing investigation and testing. I am in almost daily communication with Ognjen.

I've not updated the forum because of the amount of detail in our communication.

I'll post information and / or a summary once we've something concrete to share.


Regards,



Patrick

-----------

o.seslija Sun, 05/03/2009 - 01:44
User Badges:

Helllo Patrick,


any news about this?


Regards,

Ognjen

Actions

This Discussion