Hi, let me try and explain a few things that will hopefully clarify things up..
1. a 200 OK is a response to a request. Hence it can only be sent by the called party. This is an inbound call to CUBE, in sip language this is a request sent by the ITSP. For the call to complet CUBE needs to send the following
1a.Upon recieve if the initial INVITE, sends a trying ( this is used to stop re-transmission, so tha the other part knows that I have received your request)
1b. Sends a session progress (183 with SDP) or a ringing 180
1c. Then sends a 200 OK with SDP.
1d. FInally ITSP (or the originator of the request) needs to send an ACK to the 200 OK.
Secondly, the via header can be a little confusing..but here is the summary.
The required (it is mandatory) Via header field is used to record the SIP route taken by a request and is used to route a response back to the originator. A UA generating a request records its own address in a Via header field.
As you can see in the via header above your ITSP has put its ip address and that is where all signalling responses to this request must go. It is important to note that all further responses to this request will contain this via header field. Part of this is because a UA will copy mandatory sip header fields from the originator when it recieves a request. So your 100 trying, 180 ringing, 200 OK sent by CUBE will have this via header field
Now to the contact field, and you are right..this is where the issue is..We need to first of all understand the contact header..so here are a few lines
The Contact header field is used to convey a URI that identifies the resource
requested or the request originator, depending on whether it is present in a request
or response. Once a Contact header fi eld has been received, the URI can
be cached and used for routing future requests within a dialog. For example, a
Contact header field in a 200 OK response to an INVITE can allow the acknowledgment ACK message and all future requests during this call to bypass proxies and go directly to the called party
In some cases, the Contact URI may not resolve directly
to the user agent. For example, a UA behind a fi rewall ALG will need to use a
Contact URI that resolves to the fi rewall ALG address
From this we can deduct that your ITSP needs to send the ACK back to the URI in the contact header field..The problem here is that the host portion of your contact header field "10.0.250.4" is not reachable from the ITSP, hence the reason why we do not get the ACK back from the ITSP.
Contact: <sip:5195132407@10.0.250.4:5060
For the call that worked, the host portion of the contact header field contains a routable IP address, hence why this worked.
To understand more on sip traces please refer to this document I wrote a while back..
https://supportforums.cisco.com/document/113271/understanding-sip-traces
Back to the issue..the question is why is CUBE sending its internal ip as its contact host..This may be a bug! You can use the following sip profile to modify this:
NB: you wuill also need to modify your connection-info value because this is where your media is sent to. I also saw that your 200 OK had multiple connection-info values. This can cause one way audio issues..The last sip profile removes the duplicate..
voice class sip-profiles 1
response 200 sip-header Contact modify "<sip:(.*)@10.0.250.4:5060>" "<sip:\1@10.0.1.67:5060>"
response 200 sdp-header Connection-Info modify "10.0.250.4" "10.0.1.67"
response 200 sdp-header Connection-Info remove
Then apply this on the dial-peer going to your ITSP
dial-peer voice 50 voip
voice-class sip profiles 1
Remember to apply this on both CUBES
Please rate all useful posts
