FusionPBX Simple Call Flow | Technology

Details: Category: Technology; Created: 28 March 2018; Last Updated: 28 March 2018

User Rating: 5 / 5

As explained in my last post showing the FusionPBX architecture, I am currently doing a training with some friends and before going to the wild command line, I am trying to explain information flows. In this article, I am trying to document a simple call flow. Please note that this diagram could vary if you compare with reality as dial-plans always vary from user to user. I have also taken out some SIP answers (in case a SIP purist read it)

The Call Flow

When a call starts, regardless if it is an incoming call, outgoing call or internal call, it always follows the same basic processing. Leg A is who has started the call, Leg B is the target; not all the calls have two legs, calling to an IVR is an example of one-leg call. So, let us start with the call flow analysis.

The source sends an INVITE signal to the FreeSWITCH daemon, the first attempt usually is like this:
INVITE sip:This email address is being protected from spambots. You need JavaScript enabled to view it.;user=phone SIP/2.0 v: SIP/2.0/UDP 192.168.7.230:3073;branch=z9hG4bK-syuwuao4azwr;rport f: "LDLQ" <sip:This email address is being protected from spambots. You need JavaScript enabled to view it.;transport=tcp>;tag=ng04c3f006 t: <sip:This email address is being protected from spambots. You need JavaScript enabled to view it.;user=phone> i: 9bbdbb5a1923-b8xknstp41e3 CSeq: 1 INVITE Max-Forwards: 70 m: <sip:This email address is being protected from spambots. You need JavaScript enabled to view it.:3073;line=mvyrdokj>;reg-id=1 X-Serialnumber: 000413414375 P-Key-Flags: resolution="31x13", keys="4" User-Agent: snom870/8.7.3.25 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: 100rel, replaces, from-change c: application/sdp l: 293 v=0 o=root 1261059876 1261059876 IN IP4 192.168.7.230 s=call c=IN IP4 192.168.7.230 t=0 0 m=audio 56460 RTP/AVP 18 0 8 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv
What it is important in this payload is that there are no authentication headers.
The FreeSWITCH daemon gets the same payload.
The FreeSWITCH daemon starts the ACL processing. FreeSWITCH has some ACL's where you could deny any SIP signalling or bypass authorization. In this case, the ACL works to see if unauthenticated SIP payload is enough.
The FreeSWITCH daemon takes a decision after parsing the ACLs.
If the Leg A (source) IP is not excepted of authentication, the FreeSWITCH daemon generates a 407 error code and seends it to the source. The payload looks like this:
SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 192.168.7.230:3073;branch=z9hG4bK-syuwuao4azwr;rport=3073;received=65.110.221.7 From: "LDLQ" <sip:This email address is being protected from spambots. You need JavaScript enabled to view it.;transport=tcp>;tag=ng04c3f006 To: <sip:This email address is being protected from spambots. You need JavaScript enabled to view it.;user=phone>;tag=7HacvmgjZ6Zpc Call-ID: 9bbdbb5a1923-b8xknstp41e3 CSeq: 1 INVITE User-Agent: FreeSWITCH Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLIC, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Proxy-Authenticate: Digest realm="pbx.to-call.me", nonce="94604a51-f4eb-45f1-ba0a-4e116d84c8a9" algorithm=MD5, qop="auth" Content-Length: 0
The FreeSWITCH daemon sends important information about the authentication, like the nonce. SIP protocol uses MD5 authentication challenge which it is good as the only way to break it is a brute force attack.
The Leg A (source) get the payload.
The Leg A (source) then resends the INVITE signal with the proper authentication headers. Like this:
INVITE sip:This email address is being protected from spambots. You need JavaScript enabled to view it.;user=phone SIP/2.0 v: SIP/2.0/UDP 192.168.7.230:3073;branch=z9hG4bK-6b1qnxauwmq2;rport f: "LDLQ" <sip:This email address is being protected from spambots. You need JavaScript enabled to view it.;transport=tcp>;tag=ng04c3f006 t: <sip:This email address is being protected from spambots. You need JavaScript enabled to view it.;user=phone> i: 9bbdbb5a1923-b8xknstp41e3 CSeq: 2 INVITE Max-Forwards: 70 m: <sip:This email address is being protected from spambots. You need JavaScript enabled to view it.:3073;line=mvyrdokj>;reg-id=1 X-Serialnumber: 000413414375 P-Key-Flags: resolution="31x13", keys="4" User-Agent: snom870/8.7.3.25 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: 100rel, replaces, from-change Proxy-Authorization: Digest username="daniel.lucio",realm="pbx.to-call.me",nonce="94604a51-f4eb-45f1-ba0a-4e116d84c8a9",uri="sip:This email address is being protected from spambots. You need JavaScript enabled to view it.;user=phone",qop=auth,nc=00000001,cnone="7936b0b1",response="1be4eba1bc250a0b69986bf634dbdcfe",algorithm=MD5 c: application/sdp l: 293 v=0 o=root 1261059876 1261059876 IN IP4 192.168.7.230 s=call c=IN IP4 192.168.7.230 t=0 0 m=audio 56460 RTP/AVP 18 0 8 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv
The FreeSWITCH daemon gets the payload.
At this point, the FreeSWITCH has the required information. It then sends a request to the XML Handler asking for the directory information. Remember that FreeSWITCH supports external XML Handlers; FusionPBX provides one coded in Lua.
The XML Handler gets the question.
The XML Handler reviews if the Memcached has the directory XML payload already there.
If it does not, it will build it. The XML Handler will deal with external data sources such as a database. It will build an XML answer and try to store it in the Memcached for future requests.
The XML Handler sends the directory XML answer.
The FreeSWITCH daemon gets the directory XML answer.
Assuming the authentication is correct (because the endpoint is already registered), the FreeSWITCH daemon will set up the Leg A channel. Setting up a channel involves several tasks such as recording in a database the status of the new channel, choosing the codec that will be used and others.
The FreeSWITCH daemon asks the XML Handler for the dial plan concerning the current context.
The XML Handler gets the request.
The XML Handler verifies if the XML payload lives in the Memcached.
If it does not, the XML Handler will deal with external data sources such a database. It will build an XML answer and try to store it in the Memcached for future requests.
The XML Handler sends the dial plan XML answer.
The FreeSWITCH daemon gets the dial plan payload.
The FreeSWITCH daemon starts parsing all the dial plans. If the dial plans have inline tags, the actions are executed at this stage. This usually does not happen.
The FreeSWITCH checks if there is at least one dial plan that hits.
If it does, it starts executing it. The dial plan processing is a complex process that it is not shown in this diagram.
Depending on the dial plan, the FreeSWITCH checks if this is a two-leg call. A two-leg call is the one that finishes with a bridge statement. The bridge statement may link to a local extension or to an external SIP server.
The FreeSWITCH sets up the Leg B channel. Setting up a channel involves several tasks such as recording in a database the status of the channel, choosing a compatible codec and others. Depending if the FreeSWITCH SIP Profiles have the late codec negotiation enabled or not, the final codec decision could be here or in the first channel set up.
The FreeSWITCH daemon sends the INVITE signal to the Leg B (destination).
The Leg B gets the INVITE signal.
The Leg B sends the answer. In this diagram, we are assuming it went well. Depending on who is the Leg B, the FreeSWITCH daemon could do the same SIP authentication handshake as the Leg A did.
The FreeSWITCH daemon gets the INVITE answer. We assume the call flow will go for good.
The FreeSWITCH daemon checks if it is a 1xx answer. 1xx answers are important, when the FreeSWITCH gets this (unless early answering is set up in a dial plan) it marks a checkpoint when the ring-back tone should start to flow.
The FreeSWITCH daemon forwards the 1xx to the Leg A (source).
The Leg A (source) gets the 1xx answer and it starts ringing.
At some point, the call will get answered. The Leg B (destination) sends then another INVITE answer. Usually, this could be a 183 or 200 code which it means session in progress. In other words, the call has been answered.
The FreeSWITCH daemon gets the signal.
The FreeSWITCh daemon checks if the answer is a 200. Which it means all goes okay.
If it is not, depending on the error from Leg B (destination) or from an internal error, the FreeSWITCH daemon generates a 4xx or 5xx answer.
If the call is a one-leg call, the FreeSWITCH will execute the dial plans and it will generate the final SIP answer. This could be an IVR, a music on hold queue or any other local endpoint.
The FreeSWITCH forwards the SIP payload, like this:
SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.7.230:3073;branch=z9hG4bK-6b1qnxauwmq2;rport=3073;received=65.110.221.7 From: "LDLQ" <sip:This email address is being protected from spambots. You need JavaScript enabled to view it.;transport=tcp>;tag=ng04c3f006 To: <sip:This email address is being protected from spambots. You need JavaScript enabled to view it.;user=phone>;tag=93vXZajSSrcvK Call-ID: 9bbdbb5a1923-b8xknstp41e3 CSeq: 2 INVITE Contact: <sip:This email address is being protected from spambots. You need JavaScript enabled to view it.:5060;transport=udp> User-Agent: FreeSWITCH Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLI, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Session-Expires: 120;refresher=uas Content-Type: application/sdp Content-Disposition: session Content-Length: 247 Remote-Party-ID: "16137371111" <sip:This email address is being protected from spambots. You need JavaScript enabled to view it.>;party=calling;privacy=off;scree=on v=0 o=FreeSWITCH 1522221044 1522221045 IN IP4 198.23.164.220 s=FreeSWITCH c=IN IP4 198.23.164.220 t=0 0 m=audio 32180 RTP/AVP 18 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20
Note that this payload has the final decision about what codec and RTP ports the Leg A will interact with the FreeSWITCH daemon.
The Leg A (source) gets the Payload and the RTP start flowing.

blog comments powered by Disqus