profile question (SIP)

[tnot]

Hello,

after doing some tests on a newly installed freeswitch, I find the behaviour on internal calls a little strange.

When calling from A to B, freeswitch responds to A with "Trying" and then an immediate "200 OK", before passing the INVITE to B. Is this the default behaviour or is there something wrong with my configuration? Anyway, this causes problems when issuing multiple calls from one device as the second call is terminated because the device thinks the call was already picked up.

If I try to call oubound using the external profile, all works as I expect where the INVITE is sent from A to freeswitch then to B and the "200 OK" is not sent to A before B actually pics up and send its "200 OK" to freeswitch.

I have tried to tune some of the profile settings but nothing so far has changed the behaviour.

Any ideas? Thanks

 

[Adrian Fretwell]

No, what you describe is not normal behavior, FS will wait for 200 OK from B leg before sending 200 OK to A leg.

Are you sure B is correctly registered and call is not going to voicemail or some other "Unavailable" destination.

 

[tnot]

Hello, Adrian.

B is registered OK. I am not so familiar with the FS log yet, can you help check what happens in the attached log file?

 

[Adrian Fretwell]

Hi,
I don't have time to look at it closely this morning but it does appear that the call goes to voicemail:

34314519-5ed8-4ac2-8380-a0a8930355ac Dialplan: sofia/internal/1234@my.fs.domain:5060 Action set(fail_on_single_reject=true)
34314519-5ed8-4ac2-8380-a0a8930355ac Dialplan: sofia/internal/1234@my.fs.domain:5060 Action set(api_hangup_hook=lua app.lua hangup)
34314519-5ed8-4ac2-8380-a0a8930355ac Dialplan: sofia/internal/1234@my.fs.domain:5060 Action export(domain_name=${domain_name})
34314519-5ed8-4ac2-8380-a0a8930355ac Dialplan: sofia/internal/1234@my.fs.domain:5060 Action answer()
34314519-5ed8-4ac2-8380-a0a8930355ac Dialplan: sofia/internal/1234@my.fs.domain:5060 Action bridge(user/${destination_number}@${domain_name})
34314519-5ed8-4ac2-8380-a0a8930355ac Dialplan: sofia/internal/1234@my.fs.domain:5060 Action lua(app.lua failure_handler)
34314519-5ed8-4ac2-8380-a0a8930355ac Dialplan: sofia/internal/1234@my.fs.domain:5060 parsing [my.fs.domain->voicemail] continue=false
34314519-5ed8-4ac2-8380-a0a8930355ac Dialplan: sofia/internal/1234@my.fs.domain:5060 Regex (PASS) [voicemail] ${user_exists}(true) =~ /true/ break=on-false
34314519-5ed8-4ac2-8380-a0a8930355ac Dialplan: sofia/internal/1234@my.fs.domain:5060 Action set(record_append=false) INLINE
34314519-5ed8-4ac2-8380-a0a8930355ac EXECUTE [depth=0] sofia/internal/1234@my.fs.domain:5060 set(record_append=false)
34314519-5ed8-4ac2-8380-a0a8930355ac 2023-03-21 08:18:58.220424 0.00% [DEBUG] mod_dptools.c:1685 SET sofia/internal/1234@my.fs.domain:5060 [record_append]=[false]
34314519-5ed8-4ac2-8380-a0a8930355ac Dialplan: sofia/internal/1234@my.fs.domain:5060 Action set(voicemail_action=save) INLINE

Then possibly some further action by the failure handler, but the:

sofia/internal/1234@my.fs.domain:5060 answer()

Is the reason the 200 OK is coming back so quickly.

 

[tnot]

Hi, sorry the late reply. Thanks for your input

But voicemail is disabled on extension B ("Voicemail enabled" is set to False). And these calls actually work, does not go to voicemail. It starts ringing on B and when B pickes up, we have two-way audio and video from A to B (though in the example log only ringing, call was not picked up).

Below the sip from a call canceled before picked up. y.y.y.y is freeswitch. both sip clients are behind x.x.x.x so its a bit confusing. But FS answers immediately and seem to play the ringing tone in the established call (I can hear the tone on A). 180 ringing is only sendt from B to FS. Same kind of behaviour when the call is hanged up by A. FS answers A's BYE first, then it send CANCEL to B.

4290 74.583277135 x.x.x.x → y.y.y.y SIP/SDP 1021 Request: INVITE sip:1234@myfs.domain |
4291 74.584311650 y.y.y.y → x.x.x.x SIP 847 Status: 407 Proxy Authentication Required |
4292 74.633134862 x.x.x.x → y.y.y.y SIP 367 Request: ACK sip:1234@myfs.domain |
4293 74.633380007 x.x.x.x → y.y.y.y SIP/SDP 1272 Request: INVITE sip:1234@myfs.domain |
4294 74.652001062 y.y.y.y → x.x.x.x SIP 349 Status: 100 Trying |
4295 74.751069054 y.y.y.y → x.x.x.x SIP/SDP 1126 Status: 200 OK |
4297 74.758281195 y.y.y.y → x.x.x.x SIP/SDP 223 Request: INVITE sip:1234@x.x.x.x:65476;line=749250cd58ed201 |
4298 74.792948307 x.x.x.x → y.y.y.y SIP 823 Request: ACK sip:1234@y.y.y.y:5060;transport=udp |
4299 74.802687231 x.x.x.x → y.y.y.y SIP 376 Status: 100 Trying |
4300 74.827677574 x.x.x.x → y.y.y.y SIP 431 Status: 180 Ringing |
4493 76.823147367 x.x.x.x → y.y.y.y SIP 431 Status: 180 Ringing |
4697 78.817518740 x.x.x.x → y.y.y.y SIP 431 Status: 180 Ringing |
4905 80.812375403 x.x.x.x → y.y.y.y SIP 431 Status: 180 Ringing |
5109 82.817293568 x.x.x.x → y.y.y.y SIP 431 Status: 180 Ringing |
5312 84.809249642 x.x.x.x → y.y.y.y SIP 431 Status: 180 Ringing |
5521 86.812417031 x.x.x.x → y.y.y.y SIP 431 Status: 180 Ringing |
5717 88.763474192 x.x.x.x → y.y.y.y SIP 579 Request: BYE sip:1234@y.y.y.y:5060;transport=udp |
5718 88.768646714 y.y.y.y → x.x.x.x SIP 496 Status: 200 OK |
5719 88.774268812 y.y.y.y → x.x.x.x SIP 504 Request: CANCEL sip:1234@x.x.x.x:65476;line=749250cd58ed201 |
5720 88.818510129 x.x.x.x → y.y.y.y SIP 431 Status: 180 Ringing |
5721 88.842334849 x.x.x.x → y.y.y.y SIP 386 Status: 200 OK |
5722 88.852474113 x.x.x.x → y.y.y.y SIP 402 Status: 487 Request Terminated |
5723 88.852627170 y.y.y.y → x.x.x.x SIP 464 Request: ACK sip:1234@x.x.x.x:65476;line=749250cd58ed201 |

Wonder if I have managed to enable (and forget) some kind of setting that forces this behaviour. Any idea on how to proceed to find the problem?