[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    RE: [Sip-implementors] draft-ietf-sipping-call-flows-01-regd
From:       Alan Johnston <alan.johnston () wcom ! com>
Date:       2002-08-28 13:46:07
Message-ID: 5.1.1.6.0.20020828084048.0268ce78 () pop ! mcit ! com
[Download RAW message or body]

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:alan@siptest.wcom.com

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: sip-implementors-admin@cs.columbia.edu
>[mailto:sip-implementors-admin@cs.columbia.edu]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
>Sip-implementors@cs.columbia.edu
>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
>_______________________________________________
>Sip-implementors mailing list
>Sip-implementors@cs.columbia.edu
>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


[prev in list] [next in list] [prev in thread] [next in thread]