Hello,

I have problems using external conference bridge URL, not integrated 3-way conference (the Conference bridge URL option is used for this as ext@domain 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

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

----------

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

Yep this is a bug.  The phone itself calls 3000@domain since thats what I told it.. but the two calls it refers to the switch has the WRONG contact in the refer-to header.  This is a bug. 

/b

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

----------

That is not the behavior we are seeing.  We are seeing the phone call the conference URI which in this case is 3000@domain.com, 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 3000@domain.com 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: [<1003>]

variable_sip_refer_to: []

That Refer-To header is WRONG.. The SPA962 calls 3000@domain.com then a refer is sent referring the other legs to mod_sofia@99.185.85.2 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

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

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

----------

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

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

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

-----------

Helllo Patrick,

any news about this?

Regards,

Ognjen