SoundPoint IP335 not following RFC concerning SIP transactions?

[Anonymous]

Hello!

I have noticed a problem on the Polycom SoundPoint IP 335, which I think might be a bug on the device, however, I would like some input on what others might think.

Firmare: 4.0.1

Transport protocol: UDP

The thing that I have observed is about when the phone do a switch over from its primary registrar, to its secondary, due to failure of the first one. When the phone sends registrations to the secondary server it does not use a new Branch ID, but the same one as it used when it sent its request to the primary registrar. My firewall does not like this, and therefore the phone fails to register on the secondary server.

Scenario: 

- Phone is placed behind a firewall. 

- Phone learns about Registrar 1 and Registrar 2 with DNS SRV.

- Phone is registered on Registrar 1, with Registrar 2 as backup.

- Unplug Registrar 1.

- After a while, the phone tries to re-register on Registrar 1, with (example)-Branch ID 12345abc 

- After three unsuccessful tries, the phone now try to register on Registrar 2, now with the same (example)-Branch ID of 12345abc. 

 -  The firewall, which keep track of SIP transactions, does not like this, and rewrite the destination IP to the one associated with the Branch ID i.e. Registrar 1.

- The phone can't register.

At first I blamed the firewall, however, after reading RFC 3263, Locating SIP Servers, I found out that it states the following:

"If a failure occurs, the client SHOULD create a new request, which is identical
to the previous, but has a different value of the Via branch ID than the previous (and therefore constitutes a
new SIP transaction). That request is sent to the next element in the list as specified by RFC 2782."

- RFC 3263, Session Initiation Protocol (SIP): Locating SIP Servers, Page 7, 4.3 Details of RFC 2782 Process 

It seems like it is the phone that is the faulty part here, because of that it is not following the RFCs. What do you think? Is it the phone that is behaving in the wrong way? Should I file a bug report?

Thanks

Sebastian 

[Anonymous]

Good Day,

Was this resolved? Yesterday we were with a client testing a resiliency solution using 2 Juniper SRX100 Routers which are allowing all traffic in both directions. These are connected to a RSTP Ring on the LAN with a set Root Bridge. On the WAN, these connect to 2 SRX210 routers via OSPF. On the LAN SRX100 which is the RSTP Ring we are using VRRP so a common default gateway is always known. On the LAN of the SRX210 the same applies.

When we fail one of the SRX100's the IP Phone that is connected to the ring works, however if we place both links into service, the IP phone goes Unavailable. We thought this was a routing issue, however we generated a UDP stream using two Test sets, JDSU and EXFO and traffic reconverged every time. We also tried using a Yealink IP Phone and a 3CX Soft Phone and both worked without an issue.  The difference with this scenario is that the PBX does not change nor does the switching path only the routing path

Is there some default setting regarding resiliency that is on or needs to be tweaked? I am also not using a DNS server, just static IP addressing and default gateway. Any information will be greatly appreciated, thanks.

[SteffenBaierUK]

Hello all,

the Failover and Re-registration behavior is in details explained in the Engineering Advisory 66546 which can be found => here <=

If you are using the latest available software and still believe that a RFC violation is the case please raise a support ticket via your Polycom reseller.

Best Regards

Steffen Baier