Broadsoft R14.SP9 Generic SIP Smart Proxy bug18 Sep 2009 #broadworks #sbc #sip
I ran across this during an upgrade from
Broadworks R14.SP8 to SP9.
BroadWorks appears to contain a bug when using the
Generic SIP Smart Proxy device in SP9. At the time I am writing this post Broadsoft TAC has not officially acknowledged this as a bug. The behavior did not exist in any prior version of Broadworks and I am confident Broadsoft Engineering did not intend this behavior to occur.
In this particular scenario there is an Acme Packet SBC between a
SIP endpoint and
BroadWorks. SIP registration traverses through the SBC and rewrites the
SIP URI which contains a cookie in the
SD-Contact after the phone number
acme01# show sip endpoint-ip 7025551234 User <sip:firstname.lastname@example.org> Contact ID=98488082 exp=1819 UA-Contact: UDP realm=Access local=22.214.171.124:5060 UA=126.96.36.199:4618 SD-Contact: <sip:email@example.com:5060> realm=Core Call-ID: MjVhYjQxZTcyMDA3ZDAyODAwMzA1NTI5MzFjNzU3MjE.’ SA=10.110.156.250 <– Broadworks AS Via-Key: 188.8.131.52:4618#Access!sip:firstname.lastname@example.org:4618!
In Broadworks the SIP registration for this number would show the SIP URI exactly as it appears with the cookie. However, with SP9 Broadworks sets up a SIP invite to the number and sends
email@example.com:5060 rather than
sip:firstname.lastname@example.org:5060. The cookie portion of the URI is missing and the SBC responds with a 604 global failure response.
Sheer luck would have it that enabling the
Use Business Trunking Contact under System > Resources > Identity/Device Profile Types would clear up the issue. Otherwise each number for every BroadWorks Group using
GSSP would need to be reassigned to another Device type in Broadworks and would be service impacting.