Asterisk Auto-Replies Call Flow to SIPp UAC

Asterisk Asterisk SIP
#1

Hello experts,
I’m trying to stress test Asterisk v11.18.0 using SIPp v3.3.

The issue is that Asterisk receives the mass call requests from SIPp running as a UAC, and immediately answers those SIP calls as per the standard SIP call flow without actually sending any messages to the UAS. As below:
–> INVITE
<-- 100 Trying
<-- 200 OK
–> ACK
–> BYE
<-- 200 OK

What I want is to see

  • My sip.conf has extensions 8001 and 8002 configured.
    [8001]
    type=friend
    defaultuser=8001
    host=dynamic
    secret=
    context=phones
    nat=force_rport
    allow=gsm
    allow=ulaw
    allow=alaw

[8002]
type=friend
defaultuser=8002
host=dynamic
secret=
context=phones
nat=force_rport
allow=gsm
allow=ulaw
allow=alaw

  • My extensions.conf has a standard simple call flow configured.
    exten => 8001,1,Dial(SIP/8001,20)
    exten => 8001,2,Ringing()
    exten => 8001,3,Answer()
    exten => 8001,4,Hangup()

exten => 8002,1,Dial(SIP/8002,20)
exten => 8002,2,Ringing()
exten => 8002,3,Answer()
exten => 8002,4,Hangup()

  • I’m running SIPp UAC as:

sipp -sn uac -r 1 -m 5 -l 5 -s 8001 -ap

1 call per second, 5 calls.

If I run the SIPp as a UAS as below, it doesn’t change anything at all. And Asterisk is still replying the UAC call flow by itself.

sipp -sn uas -s 8001 -ap

Please help me understand why this is happening ?

Is SIPp actually capable of acting as a UAS to simulate a full end-to-end SIP call flow !

Please help :slight_smile:
Thanks alot

#2

You have a fundamental misunderstanding of Asterisk dialplans. For a successful call, steps 2, 3, and 4 will never be reached. They serve no useful purpose for what you are trying to do and should be deleted.

The right hand entity in your message sequence chart is a UAS, not a UAC. Phones are not UACs; they are UACs or UAS depending on which way the current transaction is going. You use UAS correctly in your narrative.

The outgoing call will fail with cause 20, as your simulation never registers the dynamic host. As a consequence priority 1 will fall through to Ringing, which will cause 180 Ringing to be sent, and Answer which will cause 200 OK to be sent, and finally Hangup, which is the same as dropping off the end, and will cause BYE to be sent. Nothing will be sent UAS on the right as Asterisk does not know where to send it.

Enabling even basic logging in Asterisk should have shown you what was going wrong.

The Asterisk Dial application handles the whole outgoing leg and will not return until one side or the other hangs up, or the call fails.

Also, without a disallow, your allows will have no effect. All supported codecs will be offered. type=friend should usually be type=peer, but your setup probably does require friend, as everything is coming from the same address.

1 Like
#3

Hi David,

You are right. I kept only the ‘Dial’ line on my dial plan, then had to modify the XML files of SIPp, and eventually I got everything running successfully.

Thanks a lot.

#4

My extensions.conf has a standard simple call flow configured.
exten => 8001,1,Dial(SIP/8001,20)
exten => 8001,2,Ringing() exten => 8001,3,Answer()
exten => 8001,4,Hangup()

In this Case i didn’t hear “ring sound” for sender, this will play from asterisk.
And RTP establish after receiver accepting call or other action. other than this all working fine.,
Is this right way ?

#5

This is far from a standard call flow and makes no sense at all.

The Asterisk DIal application does call supervision, not just dialling, and will not exit until the call has completed or failed. If the calling side is SIP, ringback tone will be generated locally within the calling device, not by Asterisk

If the calling side allows early media, and the called side uses early media, you can precede the DIal by Progress(). In geeneral service providers do not allow early media, as it can be used to create unbilled information services. In that case, you can precede Dial by Answer, however, that will result in the toll callers being charged for even failed calls.

Putting Ringing immediately after DIal is pointless, as dial will already have done whatever the calling technology requires to produce ringback tone. Putting Answer immediately after Ringing, means there is no time for the caller to hear ringback tone. Putting Answer immediately before Hangup (or the end of the dialplan) means that any billing will be started on the caller but the call will immediately end. Hangup, with no parameter, at the very last line of a dialplan adds nothing to the default action when the dialplan ends.

#6

Hope your not clear on my issue, please go through the below details

My extensions.conf has a standard simple call flow configured.
exten => 100,1,Answer()
exten => 100,n,Dial(SIP/100,60)
exten => 100,n,Playback(vm-nobodyavail)
exten => 100,n,VoiceMail(100@main)
exten => 100,n,Hangup()

  1. can able hear ring sound from asterisk for call sender
  2. sender will get all response status like Trying, Ringing and Answered before accepting call receiver.
  3. After accepting call sip didn’t receive any response.

"scenario 2 "
BY changing extension.conf like below
exten => 100,1,Dial(SIP/100,60)
exten => 100,n,Playback(vm-nobodyavail)
exten => 100,n,VoiceMail(100@main)

  1. can’t able hear ring sound from asterisk for call sender
  2. RTP didn’t establish till end user accept the call
  3. I can able to get Call response after end user accept call.
    other then all working file.
    My question is why RTP didn’t establish (or Call not establish) on second scenario
    – And Scenario 2 why my RTP - media stream got field initially.
    – And I need Call status like Ringing and Answered in proper way.
#7

The proper way of handling call statuses in SIP is that SIP responses are sent and the calling device generates the tone. Asterisk supports this as long as you do not answer the call before dialling. When it supports it, it will not send ringback tone as media, as the phone is expected to generate it for itself.

Some providers use early media instead. Some may simply answer the call and send normal media for the call progress signals (this is what you achieved in your first example, if you put your Asterisk system in the place of the provider).

I believe that Asterisk will not forward early media unless you invoke the Progress() application before dialling. I think this will then cause Asterisk to use early media itself, for ringback tone.

It is not clear from your, apparent, machine translation, whether your complaint is that you want early media, in-band, call progress, or that you are getting early media from the provider, but Asterisk isn’t forwarding it. In the latter case, note that Asterisk will not decode early media, so you cannot get back to standard SIP signalling once the B sides starts sending call progress as early media.

Note that early media call progress is only possible where the the caller uses early offer SDP. Cisco’s use late offer SDP unless you configure them to use MTPs. With late offer SDP, the caller doesn’t identify acceptable codecs until after the call is answered.

If this doesn’t help, could I suggest that you repeat your question in your first language, in case nay other users of that language are reading.

#8

Hi david
because of am using SDP this will raised.

thanks,

#9

All SIP dialogues with media use SDP! The question is is it early or late offer SDP (is the UAC or the UAS first to send SDP)?

#10

It’s early offer SDP,
First UAC send SDP.

#11

Hey @Yasir1!
I am also trying to implement same architecture as yours, but getting a hangup cause of 34.
Can you give me some work around for the issue or explain me how did you achieve it?