SIP Session Problem in CUBE

[Levent Ozturk]

Hi,

The attached config is for a CUBE that is used in the following scenario: A 3rd party SIP client on the untrusted network initiates a SIP call towards CUBE (to 192.168.198.81) and CUBE sends an INVITE to the CallCenter which is in the trusted network and completes the call. (The INVITE goes from 192.168.255.82 to 172.30.252.17)

The source port on CUBE is 54245 destined to port 5060. The problem starts at this point. The Call Center responds from its port 5060 to CUBE's port 5060 instead of the source port that originated the INVITE (port 54245). At this point I expect the respond to arrive at port 54245. Did anybody experience such a behaviour? ( Even though the Call Center answers to the wrong port, audio call gets established.) The problem here is that the SIP client that originates the call thinks that the session is not established and does not start video (which actually works when CUBE is not involved).

Thanks,

Levent

[Ayodeji Okanlawon]

I dont see the CUBE as been the issue here...The call center sends a 200 OK response to the CUBE via UDP port 5060..instead of port 54245....Should the call center not send the response to the originating port? I dont think there is away fro CUBE to perform port conversion at the transport layer... When CUBE is not involved..Does your sip client do a conversion to prot 5060? How does it work in that scenario

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Jagpreet Singh]

Hi Levent,

     The reply will always be on the port 5060, becuase that is the port the CUBE is listening on, just like the CUCM server or a Cisco SIP endpoint. Have a look at the Contact field in the Invite, that is where the Contact Center will reply to:

Contact == ""

Regards,

Jagpreet