Different Local SIP port for each SIP account on W60P

[SPC_Support_Hassan]

Hi Yealink Support,

We have the same issue with new Dect phones as it is already reported on http://forum.yealink.com/forum/showthrea...+SIP+port. Different SIP accounts registered on different handsets of a same base fail oftenly to make calls between them (to transfer a call for example).
The possible solution to this issue is the use of intercom. This solution is acceptable when the internal calls to SIP extensions are only between the Handsets registered to a same base. If the user wants to make a call to a handset registered in another base or another desk phone, the process for call transfer will be different. It means that in an office with some Dect phones and Desk phones, the attended call trasfer process between Dect phones to Dect phones (of same base) and Dect phones to any other phone will be different. Which is not accepted by the customer.

We have received the same issue from several customers and we have been able to solve the issue with the FW 25.73.0.40 for W52P and W56P but in those customers where we have W60P this issue cannot be fixed coz there is no V73 for this model.

As you have commented on above mentioned thread that from V80 onwards all the SIP accounts would use the same SIP port, could you please let me know...
1) Why Yealink has changed it?
2) Was there a demand from any market or any wrong behavior of previous mechanism has driven Yealink to take this step?

Is there any solution on the roadmap? Like something that do Grandstream phones as it is described below?

We have also see in Grandstream Dect phones that allow the user to create different profiles and assign SIP accounts, Handsets and Local SIP port to each profile. Morever, Grandstream phones also offer the possibility to use "Random Local SIP port" for each profile which gives extra control to the administrator.

Looking forward to you replies.

BR,
SPC

[SPC_Support_Hassan]

Hi Yealink support,

Any updates about this issue?

BR,

[Elaine_Yealink]

Hi SPC Support,

Answers to your question below:
1) Why Yealink has changed it?
The reason is that new machnism is following SIP standard.
2) Was there a demand from any market or any wrong behavior of previous mechanism has driven Yealink to take this step?
Some of the customers reported registration failed issue when PBX asked for a fixed registration port.
3）Is there any solution on the roadmap? Like something that do Grandstream phones as it is described below?
So far, we don't have roadmap to change this machenism.

So we'd better focus on the issue that you get from customer to see if it is caused by the fixed SIP port. I am sorry but confused with the description above. Please help to confirm:
1. The mentioned post is about registration failed issue. But I think in your case, the accounts can be registered successfully?
2. If not, what is the error for the failed registration? Please provide pcap and syslog for this.
3. What do you mean by this? The problem is cannot make calls between handsets registered to same base? Or it is the different process of transfer operation? Please explain clearly:
"The possible solution to this issue is the use of intercom. This solution is acceptable when the internal calls to SIP extensions are only between the Handsets registered to a same base. If the user wants to make a call to a handset registered in another base or another desk phone, the process for call transfer will be different. It means that in an office with some Dect phones and Desk phones, the attended call trasfer process between Dect phones to Dect phones (of same base) and Dect phones to any other phone will be different. Which is not accepted by the customer."

Regards
Elaine

[SPC_Support_Hassan]

Hi Ealine,

Thanks for your replies.
A customer who works with different brands has reported this issue and says that they have Yealink and Grandstream Dect phones. On Grandstream phones they can create different profiles, assign desired SIP accounts to a profile (there can be one or more SIP accounts in a profile) and each profile can have a different "Local SIP Port"
On the other hand, on Yealink phones it is not possible.

The main problem that the customer faces is that when there are more than one SIP accounts on a base, with the registration of second account, the first one is de-registered and that first account stays out of the game.

I'm trying to get the traces of this issue, will provide the traces as soon as possible.

BR,
SPC

[Elaine_Yealink]

Hi SPC support,

If you get traces from customer, please raise a ticket to get higher priority.
Regards
Elaine

[SPC_Support_Hassan]

Hi Ealine,

We have been trying to get the traces from the customer but after contacting them last week they told us that they have replaced the W60P with Grandstream Dect Solution
It won't be possible for us to get the traces.
I hope that you could check internally if Yealink plans to have comparable features with Grandstream's dect solutions.

BR,
SPC

[msncookie]

I believe I'm having a similar issue on the W60B where enabling a second account causes the registrations for both accounts to start flapping up and down. I am behind a firewall and the server is a VOIP provider across the country. If I disable one of the accounts, the remaining one works fine.

I believe the issue might be the single source port being shared across accounts. Is there anything I can try to help make this work behind a firewall? If source port is always the same for all accounts, how does the W60B direct return traffic to the correct account? Does it use SIP headers for this?

Thanks very much.

[Asanka]

We've also encountered multiple issues relating this this especially on cordless units. Standard handsets (Eg. T46G/S) does not cause any issues as such.
It would be great if we can have the ability to define a listen port for each account just like the Cisco SPA series phones.

Maybe set an option on the unit to give us the ability switch between either a single SIP listen port or multiple ports assigned to each account.

[SteveD101]

Was this ever resolved? We seem to be having the same issue.