1 Apr
2004
1 Apr
'04
12:33 p.m.
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(a)sip.com and user 7000(a)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
1 Apr
1 Apr
12:44 p.m.
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(a)sip.com and user 7000(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
2 p.m.
New subject: [Serdev] Re: [Serusers] Forking Proxy
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.
2:16 p.m.
New subject: [Serdev] Re: [Serusers] Forking Proxy
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
7332
days inactive
7332
days old
3 comments
3 participants
participants (3)
-
Jason Penton -
Juha Heinanen -
Klaus Darilion