Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

SBC 8.1.1.0-26 - Changes in Refer Handling

Status
Not open for further replies.

mattKnight

Programmer
May 10, 2002
6,225
GB
Evening all.

I've upgraded some SBCs from 8.0.1 to 8.1.1.0-26 and it seems that there was a change in behaviour around refer handling. I changed no config, only the application.

Calla exiting IVR send a REFER (witha refer to a VDN in CM) message to SM and the SBC seems to convert this to a INVITE and send it to the carrier.

Rollback the code and the INVITE is sent to CM and all is good!

Anyone have any ideas? I'm suspecting an issue with the Interworking profile but I can'tsee what and, crucially, any documented reason for a behaviour change

Sadly I'm not permitted to post logs...


Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.
 
Refer handling should be enabled only on the interworking profile facing the server that can't handle it - so, only on the interworking profile for the carrier trunk

They change refer handling all the time and never mention it. Little nuances in signaling that drive you nuts.
 
Interestingly I think this is a bug in SBCE 8.1.1.0-26-19214

Our connectivity to our carriers is over UDP/5060 and internal to our ASMs over TCP/5060. Pretty standard.

On the older version of SBC (8.0.1) traceSBC shows the REINVITE packet leaving the SBC and a response is received back from the carrier. With the updated version I can see the REINVITE leave but no carrier response.

Closer inspection of the 2 REINVITE packet detail in traceSBC shows that for some reason, the REINVITE packet from the upgraded SBC is sent as TCP and not UDP. A tcpdump trace shows an attemnpted 3 way handshake (SYN sent but no SYNACK returned) This doesn't suprise me as our firewalls do not permit TCP/5060 to the carrier.

I can see no reason for the SBC to change transport protocol like that at all, let alone in-dialog, especially with no configuration changes, other than the code upgrade...

Second bug I've found this week. However I have no choice but to rollback now

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top