ansaurus

Question

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

Answer 1

+2 A:

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.

sipwiz 2010-06-06 22:43:54

generate the tone? rendering?I'm not familiar with these terms...

TacB0sS 2010-06-07 01:26:48

you mean start sending RTP packets?

TacB0sS 2010-06-07 01:35:49

Generate refers to the audio that your SIP device will play when it receives a certain response without RTP such as 180 Ringing (180 ringing can also have RTP but it's optional). Render refers to the audio that your SIP device will play when it does have an RTP stream available. Generate and render are not formal terms rather they are descriptive ones I have used to explain what's going on.

sipwiz 2010-06-07 01:35:55

Thank you for the explanation. I do understand what I need to do, I just don't seem to understand the order of things, as you can see in the update I posted, the numbers just don't add up, if I should start transmitting RTP packets, I need to get the IP to transmit to, and it only comes with the Session Progress, and if you'll look at the time frame, perhaps I'm wrong but this seem silly, since the server could wait 1 sec, but I have 50 ms to respond?

TacB0sS 2010-06-07 02:04:35

The B2BUA tries to set up the callee's leg (what sipwiz calls the forwarded leg) - the call between it and the callee - as soon as it receives your INVITE. It may, at its discretion, periodically send 183s. It just happened that it sent the 183 just before the callee leg failed (hopefully with the same response status-code as you received). In other words: running the test again might NOT show a 50ms time difference.

Frank Shearar 2010-06-07 08:53:22

you were right, a few times I got the session progress after the 503.I think I get the service unavailable because I don't send the Ringing response back to the B2BUA from the callee. I think I got it: the B2BUA tells both side Caller -> Ringing, Callee -> Invite from Caller, then it has about 8 sec timeout for the Callee to set the ringing back to the B2BUA before is send service unavailable back to the Caller, the Session Progress response, is just a default response I encountered it a few more times when I supplied an invite without SDP, and in another case don't remember which

TacB0sS 2010-06-07 09:37:18

Thank you guys, looking into it... although you know, I was looking for B2BUA scheme and all the schemes I saw didn't describe this case, they all sticked to the original UAS example. So that makes me wonder the SIP and SDP are very strict so, at which point did people decide that they can change the rules of the game? I know this does not effect much, but this is wrong to send a ringing from the server before the actual ringing confirmation arrives, No?

TacB0sS 2010-06-07 09:46:55

When I wrote a B2BUA a while ago, I originally had it send a 180 Ringing. A colleague of mine convinced me that 180 Ringing should be reserved for when a UA actually tells the user that there's an incoming call, and should merely send back 183s telling the caller what it's doing.

Frank Shearar 2010-06-07 11:35:31

ansaurus

tags:

views:

answers:

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

related questions