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

List:       sip-implementors
Subject:    Re: [Sip-implementors] Why no To-Tag for Cancel Request?
From:       Christer Holmberg <christer.holmberg () lmf ! ericsson ! se>
Date:       2002-08-24 7:51:32
Message-ID: 3D673B04.7E9705D9 () lmf ! ericsson ! se
[Download RAW message or body]

Hi,

Assume your INVITE is forked to two servers, UAS_1 and UAS_2. Now, UAS_1 sends
180, and includes a To-tag, establishing an early dialog between you and UAS_1.

Now, when you send your CANCEL you want to termination the WHOLE call setup, not
only the specific dialog between you and UAS_1 (for that you would use BYE, and
then you WOULD include the To tag). The forking proxy will then route/fork the
CANCEL to both UAS_1 and UAS_2. If you would include the To tag UAS_2 would
receive a To tag it has never seen before (since UAS_1 is the node who created
it).

Don't know if this is the best explanation from a theoretical point of view, but
at least from a functional I think :)

Regards,

Christer Holmberg
Ericsson Finland






Hai-dang Pham wrote:

> Hi all,
>
>         I am wondering why CANCEL request (F9) don't use the To-Tag received
> in the 180 response (F8)?  This call flow is from
> draft-ietf-sipping-call-flows-00.txt section 3.2.1 Unsuccessful SIP to SIP
> no answer.
>
>    User A          Proxy 1          Proxy 2          User B
>      |                |                |                |
>      |   INVITE F1    |                |                |
>      |--------------->|   INVITE F2    |                |
>      |    (100) F3    |--------------->|   INVITE F4    |
>      |<---------------|    (100) F5    |--------------->|
>      |                |<---------------|                |
>      |                |                |      180 F6    |
>      |                |     180 F7     |<---------------|
>      |     180 F8     |<---------------|                |
>      |<---------------|                |                |
>      |                |                |                |
>      |   CANCEL F9    |                |                |
>      |--------------->|                |                |
>      |     200 F10    |                |                |
>      |<---------------|   CANCEL F11   |                |
>      |                |--------------->|                |
>      |                |     200 F12    |                |
>      |                |<---------------|                |
>      |                |                |   CANCEL F13   |
>      |                |                |--------------->|
>
>
>
>    F8 180 Ringing Proxy 1 -> A
>
>    SIP/2.0 180 Ringing
>    Via: SIP/2.0/UDP here.com:5060;branch=z9hG4bK74bf9
>     ;received=100.101.102.103
>    Record-Route: <sip:ss2.wcom.com;lr>, <sip:ss1.wcom.com;lr>
>    From: BigGuy <sip:UserA@here.com>;tag=9fxced76sl
>    To: LittleGuy <sip:UserB@there.com>;tag=314159
>    Call-ID: 12345600@here.com
>    CSeq: 1 INVITE
>    Contact: <sip:UserB@110.111.112.113>
>    Content-Length: 0
>
>    F9 CANCEL A -> Proxy 1
>
>    CANCEL sip:UserB@there.com SIP/2.0
>    Via: SIP/2.0/UDP here.com:5060;branch=z9hG4bK74bf9
>    Max-Forwards: 70
>    From: BigGuy <sip:UserA@here.com>;tag=9fxced76sl
>    To: LittleGuy <sip:UserB@there.com>
>    Call-ID: 12345600@here.com
>    CSeq: 1 CANCEL
>    Content-Length: 0
>
>
>
> Can somebody direct me to the section(s) in RFC3261 that explains this?
>
> Thanks you,
>
> Hai-Dang
>
> _______________________________________________
> 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]