In 3.8, the CANCEL and the ACK are hop-by-hop
because this is how it is described in RFC 3261, section 16.10
While a CANCEL request is handled in a stateful proxy by its own
server transaction, a new response context is not created for it.
Instead, the proxy layer searches its existing response contexts for
the server transaction handling the request associated with this
CANCEL. If a matching response context is found, the element MUST
immediately return a 200 (OK) response to the CANCEL request. In
this case, the element is acting as a user agent server as defined in
Section 8.2. Furthermore, the element MUST generate CANCEL requests
for all pending client transactions in the context as described in
Section 16.7 step 10.
If a response context is not found, the element does not have any
knowledge of the request to apply the CANCEL to. It MUST statelessly
forward the CANCEL request (it may have statelessly forwarded the
associated request previously).
So, if it's a stateful proxy, it must respond with 200 OK if a matching response
context has been found. So it can be hop-by-hop.
Regards,
Attila
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Fri 15/12/2006 08:29
To: Attila Sipos; [email protected]
Cc:
Subject: RE: [Sip-implementors] Doubt in rfc 3665.
In 3.8, I do believe that reason for hop-by-hop message transfer is
proxies being stateful. But then why in 3.2 200Ok and ACK are not
hop-by-hop. Here when 200Ok reaches Alice phone through proxy 1 and 2
then ACK is sent and new Via is added by each proxy. Why in 3.2, like
3.8, 200Ok and ACK are not exchanged from bob-proxy2, proxy2-proxy 1 and
proxy1-Alice.
Vivek
-----Original Message-----
From: Attila Sipos [mailto:[EMAIL PROTECTED]
Sent: Friday, December 15, 2006 12:30 PM
To: Vivek Srivastava (WT01 - IP-Multimedia Carrier & Ent Networks);
Vivek Srivastava (WT01 - IP-Multimedia Carrier & Ent Networks);
[email protected]
Subject: RE: [Sip-implementors] Doubt in rfc 3665.
Yes, I think you're right here.
What I don't understand is why does the 487/ACK happen hop-by-hop?
And why is the CANCEL/200 hop-by-hop?
Those proxies must be stateful too.
Regards,
Attila
-----Original Message-----
From: [EMAIL PROTECTED] on behalf of
[EMAIL PROTECTED]
Sent: Fri 15/12/2006 05:51
To: [EMAIL PROTECTED]; [email protected]
Cc:
Subject: Re: [Sip-implementors] Doubt in rfc 3665.
Hi All,
Adding to my previous mail the Via header should be
Via: SIP/2.0/UDP
ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
which is added by proxy1 in F2.
Correct me if I m wrong.
Cheers,
Vivek
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, December 14, 2006 8:12 PM
To: [email protected]
Subject: [Sip-implementors] Doubt in rfc 3665.
Hi All,
I was going through rfc 3665. In call flow for Unsuccessful no
answer
(3.8), why F16 and F18 has same Via?
Cheers,
Vivek
The information contained in this electronic message and any
attachments
to this message are intended for the exclusive use of the
addressee(s)
and may contain proprietary, confidential or privileged
information. If
you are not the intended recipient, you should not disseminate,
distribute or copy this e-mail. Please notify the sender
immediately and
destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The
recipient
should check this email and any attachments for the presence of
viruses.
The company accepts no liability for any damage caused by any
virus
transmitted by this email.
www.wipro.com
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
addressee(s) and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The
recipient should check this email and any attachments for the presence
of viruses. The company accepts no liability for any damage caused by
any virus transmitted by this email.
www.wipro.com
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
addressee(s) and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses. The
company accepts no liability for any damage caused by any virus transmitted by
this email.
www.wipro.com
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
