Hi,
Branch is defined by the branch id, not the to-tag, which defines
the dialog. The CANCEL will be identical to the INVITE the
proxy sent out on the client transaction. This CANCEL may in turn
get forked by other proxies which forwarded the original INVITE.
In all these forwarded requests, you will see branch id's set same to the
INVITE forwarded by the proxies. The To-tag doesnt mean much here.
----- Original Message -----
From: "Hai-dang Pham" <[EMAIL PROTECTED]>
To: "'Christer Holmberg'" <[EMAIL PROTECTED]>
Cc: "'Medhavi Bhatia'" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, August 26, 2002 2:37 PM
Subject: RE: [Sip-implementors] RE: Why no To-Tag for Cancel Request?
First of, thank you for all your answers. I am still unsure about the role
of CANCEL for a proxy:
RFC3261 Section 16.7 states:
10. Generate CANCELs
If the forwarded response was a final response, the proxy MUST
generate a CANCEL request for all pending client transactions
associated with this response context.
So doesn't this imply that a Proxy is using CANCEL for specific branch and
must use the received To-Tag if it was received?
E.g.
Proxy 1 being a parallel proxy tries 3 destinations (D1, D2, and D3), D2
returns a 200 OK, while D1 and D3 establish early dialogs (1XX with To-Tag),
shouldn't Proxy 1 issue CANCEL to D1 and D3 with the respective To-Tag that
was received for those branches?
Thank you,
Hai-Dang
-----Original Message-----
From: Christer Holmberg [mailto:[EMAIL PROTECTED]]
Sent: Saturday, August 24, 2002 4:11 AM
To: Hai-dang Pham
Cc: 'Medhavi Bhatia'; [EMAIL PROTECTED]
Subject: Re: [Sip-implementors] RE: Why no To-Tag for Cancel Request?
Hi,
> Isn't CANCEL also used to terminate specific pending branches in a forking
> proxy?
Nope.
> Wouldn't the use of a To-tag help distinguish from the "a dialog
> creating" branch with those that are being cancelled?
It probably would, but if you want to terminate a specific dialog you use
BYE
- with a To tag. That's the rules :)
Regards,
Christer Holmberg
Ericsson Finland
>
>
> -----Original Message-----
> From: Medhavi Bhatia [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 23, 2002 6:10 PM
> To: Hai-dang Pham; [EMAIL PROTECTED]
> Subject: Re: [Sip-implementors] RE: Why no To-Tag for Cancel Request?
>
> That's because CANCEL is supposed to cancel all dialogs associated
> with a request. It gets forked just like the INVITE. The behavior you
> are referring to is attributed to BYE, which cancels a particular dialog
> only.
>
> ----- Original Message -----
> From: "Hai-dang Pham" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, August 23, 2002 2:15 PM
> Subject: [Sip-implementors] RE: Why no To-Tag for Cancel Request?
>
> 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:[EMAIL PROTECTED]>;tag=9fxced76sl
> To: LittleGuy <sip:[EMAIL PROTECTED]>;tag=314159
> Call-ID: [EMAIL PROTECTED]
> CSeq: 1 INVITE
> Contact: <sip:[EMAIL PROTECTED]>
> Content-Length: 0
>
> F9 CANCEL A -> Proxy 1
>
> CANCEL sip:[EMAIL PROTECTED] SIP/2.0
> Via: SIP/2.0/UDP here.com:5060;branch=z9hG4bK74bf9
> Max-Forwards: 70
> From: BigGuy <sip:[EMAIL PROTECTED]>;tag=9fxced76sl
> To: LittleGuy <sip:[EMAIL PROTECTED]>
> Call-ID: [EMAIL PROTECTED]
> 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
> [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
