Hi All
I have a question about the CORRECT operation of UA when making a call via a forking proxy:
Lets say UA1 calls 7000@sip.com and user 7000@sip.com is available at UA2 and UA3 i.e. the Proxy forks the request.
UA1 Forking UA2 UA3 Proxxy 1 |------INVITE---------->| | | 2 | |--------INVITE-------------->| | 3 | |---------------------------INVITE------------->| 4 | |<---RINGING(totag=1234)------| | 5 |<---RINGING(totag=1234)| | | 6 | |<------------------RINGING(totag=5768)---------| 7 |<---RINGING(totag=5678)| | | | | | | | | | | NOW UA3 WILL ANSWER
| |<----------------200 OK (totag=5678)-----------| 8 |<-200 OK (totag=5678)--| | | 9 |---ACK (totag=1234)--->| | | 10 | |------------------ACK (totag=1234)------------>| AT THIS STAGE UA 3 IGNORES THE ACK AS IT DOES NOT CORRESPOND TO ORIGINATING 200 OK AND THE CALL IS NOT SETUP
* UA1 is using the to-tag of the first 180 RINGING it received (frame 5) no matter what the to-tag in the 200 OK is * My question here is: who is in the wrong???? The proxy or UA1? * Should the proxy change the to-tag of the ACK before forewarding it to UA3???
Any help/guidance would be much appreciated Jason Penton Rhodes University Grahamstown South Africa
UA1 behaves wrong - per RFC 3261 the dialog will be established by the 200 OK message (not by 180), therefore the to-tag from the 200 OK must be used.
It makes no sense to deal with such wrong implementations in the SIP proxy.
Which client is UA1?
Klaus
Jason Penton wrote:
Hi All
I have a question about the CORRECT operation of UA when making a call via a forking proxy:
Lets say UA1 calls 7000@sip.com and user 7000@sip.com is available at UA2 and UA3 i.e. the Proxy forks the request.
UA1 Forking UA2 UA3 Proxxy 1 |------INVITE---------->| | | 2 | |--------INVITE-------------->| | 3 | |---------------------------INVITE------------->| 4 | |<---RINGING(totag=1234)------| | 5 |<---RINGING(totag=1234)| | | 6 | |<------------------RINGING(totag=5768)---------| 7 |<---RINGING(totag=5678)| | | | | | | | | | |
NOW UA3 WILL ANSWER| |<----------------200 OK (totag=5678)-----------| 8 |<-200 OK (totag=5678)--| | | 9 |---ACK (totag=1234)--->| | | 10 | |------------------ACK (totag=1234)------------>|
AT THIS STAGE UA 3 IGNORES THE ACK AS IT DOES NOT CORRESPOND TO ORIGINATING 200 OK AND THE CALL IS NOT SETUP
- UA1 is using the to-tag of the first 180 RINGING it received (frame 5) no
matter what the to-tag in the 200 OK is
- My question here is: who is in the wrong???? The proxy or UA1?
- Should the proxy change the to-tag of the ACK before forewarding it to
UA3???
Any help/guidance would be much appreciated Jason Penton Rhodes University Grahamstown South Africa
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Klaus Darilion writes:
UA1 behaves wrong - per RFC 3261 the dialog will be established by the 200 OK message (not by 180), therefore the to-tag from the 200 OK must be used.
it may be that to tag from 200 ok must be used, but you are wrong about the dialog part. as per rfc 3261 dialog is established already by 180 ringing.
-- juha
-----------------------------------------------------------------------
12.1 Creation of a Dialog
Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog.
12.1.2 UAC Behavior
When a UAC receives a response that establishes a dialog, it constructs the state of the dialog. This state MUST be maintained for the duration of the dialog.
The local tag component of the dialog ID MUST be set to the tag in the
From field in the request, and the remote tag component of the dialog ID
MUST be set to the tag in the To field of the response.
Klaus Darilion writes:
UA1 behaves wrong - per RFC 3261 the dialog will be established by the 200 OK message (not by 180), therefore the to-tag from the 200 OK must be used.
klaus,
can you point out the section/paragraph in rfc 3261 that tells that the to-tag from the 200 ok must be used. i scanned the document for a while i didn't find it. the closest i found is this:
13.2.2 Processing INVITE Responses
If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog MUST be transitioned to the confirmed state, and the route set for the dialog MUST be recomputed based on the 2xx response using the procedures of Section 12.2.1.
but it only mentions about recomputing the route set, not the rest of the dialog state.
-- juha
-
Jason Penton -
Juha Heinanen -
Klaus Darilion