Getting RINGING response on SIP UAC without sending it from the other UAC

I hope this would be my last question about this SIP subject, I have managed to overcome the last issue I had by asking a friend to help me from a remote computer, I'm able to connect between the computers, but here is the thing, according to all the examples I saw, the Callee should invoke the Ringing response, but in my application case I didn't implement it yet, but I still receive on the Caller UAC a Ringing response, this is the SIP messages that are on the caller end:

Outgoing Request 5:

INVITE sip:320@hostName.hn SIP/2.0
Contact: "Client 310" <sip:310@hostName.hn>
From: "Client 310" <sip:310@hostName.hn>
Max-Forwards: 32
CSeq: 2 INVITE
Call-ID: f8d171d3278788df9e03eb9cf3acba70@xxx.xxx.x.xxx
Allow: INVITE,CANCEL,ACK,BYE,OPTIONS
Content-Type: application/sdp
Proxy-Authorization: Digest username="310",nonce="012afffb",realm="asterisk",uri="sip:310@hostName.hn",algorithm=MD5,response="d19ca5b98450b4be7bd4045edb8a3a2f"
Via: SIP/2.0/UDP hostName.hn:5060
To: "Client 320" <sip:320@hostName.hn>;tag=as5a8fa200
Content-Length: 257

v=0
o=310 7108915969559970847 7108915969559970847 IN IP4 xxx.xxx.x.xxx
s=-
i=Nu-Art Software - TacB0sS VoIP information
c=IN IP4 xxx.xxx.x.xxx
m=audio 3312 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000

Incoming Response 6:

SIP/2.0 100 Trying
Via: SIP/2.0/UDP hostName.hn:5060;branch=f8d171d3278788df9e03eb9cf3acba70-xxx.xxx.x.xxx-2-invite-hostName.hn-5060333732;received=79.181.6.233
From: "Client 310" <sip:310@hostName.hn>
To: "Client 320" <sip:320@hostName.hn>;tag=as5a8fa200
Call-ID: f8d171d3278788df9e03eb9cf3acba70@xxx.xxx.x.xxx
CSeq: 2 INVITE
User-Agent: Freeswitch 1.2.3
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY,INFO
Supported: replaces
Contact: <sip:320@yy.yy.yy.yy>
Content-Length: 0

Incoming Response 7:

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP hostName.hn:5060;branch=f8d171d3278788df9e03eb9cf3acba70-xxx.xxx.x.xxx-2-invite-hostName.hn-5060333732;received=79.181.6.233
From: "Client 310" <sip:310@hostName.hn>
To: "Client 320" <sip:320@hostName.hn>;tag=as5a8fa200
Call-ID: f8d171d3278788df9e03eb9cf3acba70@xxx.xxx.x.xxx
CSeq: 2 INVITE
User-Agent: Freeswitch 1.2.3
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY,INFO
Supported: replaces
Contact: <sip:320@yy.yy.yy.yy>
Content-Length: 0

Call to: 320@hostName.hn is Ringing

Incoming Respons开发者_高级运维e 8:

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP hostName.hn:5060;branch=f8d171d3278788df9e03eb9cf3acba70-xxx.xxx.x.xxx-2-invite-hostName.hn-5060333732;received=79.181.6.233
From: "Client 310" <sip:310@hostName.hn>
To: "Client 320" <sip:320@hostName.hn>;tag=as5a8fa200
Call-ID: f8d171d3278788df9e03eb9cf3acba70@xxx.xxx.x.xxx
CSeq: 2 INVITE
User-Agent: Freeswitch 1.2.3
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY,INFO
Supported: replaces
Contact: <sip:320@yy.yy.yy.yy>
Content-Type: application/sdp
Content-Length: 264

v=0
o=root 27669 27669 IN IP4 yy.yy.yy.yy
s=session
c=IN IP4 yy.yy.yy.yy
t=0 0
m=audio 10914 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

Incoming Response 9:

SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP hostName.hn:5060;branch=f8d171d3278788df9e03eb9cf3acba70-xxx.xxx.x.xxx-2-invite-hostName.hn-5060333732;received=79.181.6.233
From: "Client 310" <sip:310@hostName.hn>
To: "Client 320" <sip:320@hostName.hn>;tag=as5a8fa200
Call-ID: f8d171d3278788df9e03eb9cf3acba70@xxx.xxx.x.xxx
CSeq: 2 INVITE
User-Agent: Freeswitch 1.2.3
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY,INFO
Supported: replaces
Content-Length: 0

I do not respond to the invite, that is why all this is happening, but why am I getting a ringing if I'm not the one sending it.

Thanks,

Adam.

Update:

If you will notice the times that I get the responses:

Incoming Response 7: 1275879030656 Ringing

Incoming Response 8: 1275879038734 Session Progress

Incoming Response 9: 1275879038781 Service Unavailable

I don't understand the logic here, I have 8 sec from the first Ringing to the session progress, but from the Session Progress to the Service Unavailable I have 47ms?

How does this makes sense? 50 ms to do what? time to analyze the response + time to open an RTP session + time to construct a response + time to construct SDP + time it takes the server to receive the message - the time it takes the 503 message to arrive to my UAC, isn't this cutting little close? at which point am I suppose to response to the server?

Thanks again for all your help Wiz.

Because the FreeSwitch server you are calling is a B2BUA and must be configured to generate ring back independently of the forwarded call leg. If the server you were calling was a SIP Proxy without B2BUA capabilities you would not get any ringing or other reponses until the SIP device at the far end responded.

Responses 7 and 8 will cause your softphone to ring. For response 7, 180 Ringing, it's up to your softphone to generate the tone. For response 8, 183 Session Progress with RTP, your softphone will receive a progress indication from the FreeSwitch server that it should be rendering.

Update: The reason for the timings you're seeing are again down to the fact that you're placing the call to a B2BUA, in this case FreeSwitch. It looks like it's configured to send a Ringing response automatically when a new call is received and in the meantime it is processing its dialplan to work out what to do with the call. Somewhere in that dialplan there appears to be a command to indicate session progress which is where the 183 response comes in but then it must get to the end of the dialplan or encounter an error which results in the 503 response.

It's unlikely you would get the same pattern of responses if you were communicating directly to a UAS.

The only action required from your end of the call, you are acting as the UAC, is to ACK the final response, in this case the 503. Your SIP stack does need to do something with the 180 and 183 responses to let the user know what's happening but you don't need to respond to them as they are what's called informational responses and the UAS doesn't want a response to them. There actually is an enhancement to the SIP standard dealing with reliable processing of provisional responses but it's optional and I wouldn't worry about it at this point if I was you.