Connect incoming SIP message to current dialog or create new dialog structure

Note:: Called by handle_request, sipsock_read

Dialog matching

SIP can be forked, so we need to separate dialogs from each other in a good way.

1. Calling out, getting the same call back: An OUTBOUND INVITE can be sent to a SiP proxy and come back twice. We separate the two different calls by branch tag in the topmost via header. Asterisk1 ----> INVITE ---> PROXY PROXY --> INVITE branch 1 ---> Asterisk1 PROXY --> INVITE branch 2 ---> Asterisk1 PROXY --> INVITE branch 3 ---> UA3 (not Asterisk) We have to treat the two calls as separate calls. But how do we handle this situation, where we actually can take the media internally somehow? If the proxy does not add Record-Route, we can just tear down the SIP signalling and shortcut the call internally. If the proxy Record-Route the call, we need to keep the SIP signalling or just fake a tear down with a fake BYE and handle it internally, which wouuld be bad if the proxy logs are important.

2. Getting the same INCOMING call multiple times: UAC ----> INVITE ---> PROXY PROXY --> INVITE branch 1 ---> Asterisk1 PROXY --> INVITE branch 2 ---> Asterisk1 PROXY --> INVITE branch 3 ---> UA3 (not Asterisk)

3. Sending INVITE, getting many replies

An OUTBOUND INVITE may be forked to two or more separate UA's. If there's a stateless SIP proxy between us and the UA's, we get multiple replies. In a worst case scenario, we get multiple 200 OK at the same time. Since we don't know about the fork, we won't send CANCEL. INVITE --> <--- 100 trying from UA1 <--- 100 trying from UA2 <--- 200 OK from UA1 <--- 200 OK from UA2 in this case

If it's a secondary 200 OK to a current INVITE, we're in interesting waters. In this case, we have to copy the current dialog, create a new and send ACK, then immediately BYE since there's no call to bridge it with. of course, there's a usability issue here. how do you tell the person that answers the forked call that someone else answered already? Too late to cancel the call...

Scenarios: INVITE 100 from first device 100 from second device 183 from first device 183 from second device

provisional responses, don't create new dialog, just ignore the secondary answers and be happy --- 2. Double 200 OKs 200 OK from first device 200 OK from second
Creates new branch --- 3. Error and 200 OK from different devices 200 OK from first device response 603 Declined from secondary device response
Sorry, just ACK the 603 and close

603 declined from first response 200 OK from second response

In this case, the call failed. We can't wait for the possibility that we get a 200 OK from a device we don't know about.
But we might be clever, if we get two 100 trying then we know that something's going on.
Without trickery, the second 200 OK will have to get an ACK, then a BYE

4. How do we handle this in Asterisk chan_sip3 ???

Todo:: Add text here!

Asterisk is a trademark for Digium, inc.. | Edvina.net | Asterisk.org | This documentation was generated with Doxygen

Asterisk developer's documentation :: Codename Pineapple

chan_sip3:: Dialog matching and scenarios