RFC 3261 reads
"The ACK for a 2xx response to an INVITE request is a separate transaction."
Sec 5
" In all of the above cases, the request is retried by creating a new
request with the appropriate modifications. This new request
~~~~~~~~~~~~~~~~
constitutes a new transaction and SHOULD have the same value of the
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Call-ID, To, and From of the previous request, but the CSeq should
contain a new sequence number that is one higher than the previous. "
Sec 8.1.3.5
So I guess the examples in call flow are written wrong ??
- Sp.Raja
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Sp.Raja
Sent: Monday, 26 August 2002 8:08 PM
To: Sip-Implementors
Subject: [Sip-implementors] draft-ietf-sipping-call-flows-01-regd
Hi,
In draft-ietf-sipping-call-flows-01, I have the following doubts
1).
User A Proxy 1 Proxy 2 User B
| | | |
| INVITE F1 | | |
|--------------->| | |
| 407 F2 | | |
|<---------------| | |
| ACK F3 | | |
|--------------->| | |
| INVITE F4 | | |
|--------------->| INVITE F5 | |
F1 INVITE A -> Proxy 1
...
Via: SIP/2.0/UDP client.atlanta.com:5060;branch=z9hG4bK74bf9
...
CSeq: 1 INVITE
...
F4 INVITE A -> Proxy 1
...
Via: SIP/2.0/UDP client.atlanta.com:5060;branch=z9hG4bK74bf9
...
CSeq: 2 INVITE
When Proxy1 receives the message F4, it would recognize F4 has
retransmission of F1 and not an new INVITE since they use the same branchid
. Since the original INVITE server transaction in proxy 1 would be deleted
only after Timer I timeout. Should not branch-Id of F4 be different from
that of F1 ?? Or is that proxy need to process CSeq to capture it??
2). ACK for 2xx responses bear the same branch-Id how??
User A Proxy 1 Proxy 2 User B
|--------------->| | |
| INVITE F4 | | |
|--------------->| INVITE F5 | |
| |--------------->| INVITE F7 |
| | |--------------->|
..............
| ACK F15 | | |
|--------------->| ACK F16 | |
| |--------------->| ACK F17 |
| | |--------------->|
F7 Via :
Via: SIP/2.0/UDP ss2.biloxi.com:5060;branch=z9hG4bK721e418c4.1
Via: SIP/2.0/UDP ss1.atlanta.com:5060;branch=z9hG4bK2d4790.1
;received=192.168.255.111
Via: SIP/2.0/UDP client.atlanta.com:5060;branch=z9hG4bK74bf9
;received=192.168.100.101
F17 Via :
Via: SIP/2.0/UDP ss2.biloxi.com:5060;branch=z9hG4bK721e418c4.1
Via: SIP/2.0/UDP ss1.atlanta.com:5060;branch=z9hG4bK2d4790.1
;received=192.168.255.111
Via: SIP/2.0/UDP client.atlanta.com:5060;branch=z9hG4bK74bf9
;received=192.168.100.101
In the above example, the issues are
1. UAC should have used some other branch-Id other than the one used in
INVITE for ACK(For 200).
2. Proxies in the line could not have placed the same branch-Id, since
they would have forgotten it by the time, since receiving 200 transaction
deletes the INVITE transaction.
UAS should not use branch-Id for matching ACK for 200 and should simply use
Call-Id, To-Tag, From-Tag and CSeq for it. right ??
- Sp.Raja
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
