Hi,
Thanks for your comments on the document.
As an editing shorthand, the document does reuse branch IDs, tags,
Call-IDs, nonces, etc. which obviously would be uniquely generated in real
call flows. There is a note at the start of the document stating that.
The use of Call-IDs, CSeq, etc within each call flow is correct, so I'm not
sure what your quotes of RFC 3261 relate to.
BTW, there is a newer version of the call flows, which has now been split
into three documents:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-basic-call-flows-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-sipping-pstn-call-flows-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-sipping-torture-tests-00.txt
Thanks,
Alan Johnston
sip:[EMAIL PROTECTED]
At 11:39 AM 8/27/2002 +0530, Sp.Raja wrote:
>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
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
