Forking
single SIP call is forwarded by a proxy server to multiple endpoints
Parallel forking
INVITE is forked by the server at two multiple endpoints at a time. 180 Ringing is generated by both the devices and a 200 OK is generated by the one who receives the call. A session with receiving endpoint is established when the response reaches the caller , at same time CANCEL is triggered for other endpoints. In Case both the responses are received simultaneously, then on the basis of the q-value, the response is forwarded.
Serial forking
proxy server will fork the INVITE to one endpoint. If that is unavailable or busy at that time, then the proxy will fork it to another endpoint.
Methods
t_load_contacts()
removes all branches from the current destination set and stores them into the XAVP , contacts_avp.
If the destination set contains only one branch, the function does nothing. If the current destination set contains more than one branch, the function sorts them according to increasing value of the q parameter and then stores the branches in reverse order into the XAVP.
The q parameter of a branch contains a value from range 0-1.0 and it expresses relative preference of the branch among all branches in the destination set , to be tried when serial forking takes place.
After calling t_load_contacts(), function t_next_contacts() and possibly also t_next_contact_flow() need to be called one or more times in order to retrieve the branches based on their q value.
t_next_contacts()
implement serial/parallel forking based on the q value of the individual branches in a destination set. adds to request a new destination set that includes the highest priority contacts in contacts_avp Upon each call, Request URI is rewritten with the first contact and the remaining contacts (if any) are added as branches. Then all highest priority contacts are removed from contacts_avp.
t_next_contact_flow()
adds a new branch to the request that includes the first contact from contact_flows_avp that matches the +sip.instance value of the flow that has failed. Upon each call, Request URI is rewritten with the contact. The used contact is removed from contact_flows_avp.
Debugging
Issue1 ERROR: dialog [dlg_handlers.c:503]: dlg_onreply(): missing TAG param in TO hdr :-/ solution After inspection of 200 message we can see that it misses the tag ahead of To header
SIP/2.0 200 OK. Via: SIP/2.0/UDP y.y.y.y:5060;branch=z9hG4bK32b3.18f1ec7de2b150859efcf052bef016bd.1. From: <sip:2222222222@x.x.x.x>;tag=6bc95850. To: <sip:18552702852@y.y.y.y:5077>. Call-ID: 99140NWIyNGJlMTFhYTJhNGI4NjJiZmQyY2ZlODViNTM5MDQ. CSeq: 1 INVITE. Contact: <sip:127.0.1.1:5077;transport=UDP>. Content-Length: 0.
A correct SIP 200 ok would be
U y.y.y.y:5077 -> y.y.y.y:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP y.y.y.y:5060;branch=z9hG4bKcd78.edfd5d41eed4ad1a9983b6085c930464.1. From: <sip:2222222222@x.x.x.x>;tag=e84b2c42. To: <sip:18552702852@y.y.y.y:5077>;tag=7568SIPpTag011. Call-ID: 99140NjJkODE4MmYyMjA2ODRkZDlkZDBmZGQ3NDEyZjI1MjQ. CSeq: 1 INVITE. Contact: <sip:127.0.1.1:5077;transport=UDP>. Content-Type: application/sdp. Content-Length: 129.
Also show in SIPP uas 200 ok construction
<send>
<![CDATA[
SIP/2.0 200 OK
[last_Via:]
[last_From:]
[last_To:];tag=[call_number]
[last_Call-ID:]
[last_CSeq:]
[last_Record-route:]
Contact: <sip:[local_ip]:[local_port];transport=[transport]>
Content-Type: application/sdp
Content-Length: 0
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 0
a=rtpmap:0 PCMU/8000
]]>
</send>