Hi Klaus: RFC 3665 page 54 line 4: A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled.
and RFC 3665 at page 53: CANCEL is referred to as a "hop-by-hop" request, since it is responded to at each stateful proxy hop.
and RFC 3665 at page 21: Client: A client is any network element that sends SIP requests and receives SIP responses. Clients may or may not interact directly with a human user. User agent clients and proxies are clients.
So, for my opinion, the role of proxy in this case of RFC 3665 section 3.8 is a client when it sends CANCEL message to Bob.
If I misunderstand any RFC meanings, please correct me. Thank you very much.
Best Regards, Fangyu Ling
fancy wrote:
According to RFC 3665 section 3.8 and RFC 3261 section 9, there is only one via header in CANCEL message (message F11, F13 at page 72 of RFC 3665).
Hi!
I could find it in RFC 3665, but not in 3261. Where exactly in RFC 3261 is mentioned that the CANCEL has only 1 Via header?
Further, the example has only one Via header - but I could not find any definition if this is a MUST or not.
How can I remove the 2nd via header?
You would have to modify tm module and change the code which generates the CANCEL message.
regards klaus
Looks like it is defined clearly and openser is not 100% standard conform.
regards klaus
fancy wrote:
Hi Klaus: RFC 3665 page 54 line 4: A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled.
and RFC 3665 at page 53: CANCEL is referred to as a "hop-by-hop" request, since it is responded to at each stateful proxy hop.
and RFC 3665 at page 21: Client: A client is any network element that sends SIP requests and receives SIP responses. Clients may or may not interact directly with a human user. User agent clients and proxies are clients.
So, for my opinion, the role of proxy in this case of RFC 3665 section 3.8 is a client when it sends CANCEL message to Bob.
If I misunderstand any RFC meanings, please correct me. Thank you very much.
Best Regards, Fangyu Ling
fancy wrote:
According to RFC 3665 section 3.8 and RFC 3261 section 9, there is only one via header in CANCEL message (message F11, F13 at page 72 of RFC 3665).
Hi!
I could find it in RFC 3665, but not in 3261. Where exactly in RFC 3261 is mentioned that the CANCEL has only 1 Via header?
Further, the example has only one Via header - but I could not find any definition if this is a MUST or not.
How can I remove the 2nd via header?
You would have to modify tm module and change the code which generates the CANCEL message.
regards klaus
Klaus,
CANCEL is hop-by-hop only in stateful processing and in this case, yes, it has only on VIA. But if you have stateless processing, CANCEL is end-2-end and it will have multiple VIAs...
Does 3665 obsoletes stateless SIP or it is just not covering it???
regards, bogdan
Klaus Darilion wrote:
Looks like it is defined clearly and openser is not 100% standard conform.
regards klaus
fancy wrote:
Hi Klaus: RFC 3665 page 54 line 4: A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled.
and RFC 3665 at page 53: CANCEL is referred to as a "hop-by-hop" request, since it is responded to at each stateful proxy hop.
and RFC 3665 at page 21: Client: A client is any network element that sends SIP requests and receives SIP responses. Clients may or may not interact directly with a human user. User agent clients and proxies are clients.
So, for my opinion, the role of proxy in this case of RFC 3665 section 3.8 is a client when it sends CANCEL message to Bob.
If I misunderstand any RFC meanings, please correct me. Thank you very much.
Best Regards, Fangyu Ling
fancy wrote:
According to RFC 3665 section 3.8 and RFC 3261 section 9, there is only one via header in CANCEL message (message F11, F13 at page 72 of RFC 3665).
Hi!
I could find it in RFC 3665, but not in 3261. Where exactly in RFC 3261 is mentioned that the CANCEL has only 1 Via header?
Further, the example has only one Via header - but I could not find any definition if this is a MUST or not.
How can I remove the 2nd via header?
You would have to modify tm module and change the code which generates the CANCEL message.
regards klaus
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu wrote:
Klaus,
CANCEL is hop-by-hop only in stateful processing and in this case, yes, it has only on VIA. But if you have stateless processing, CANCEL is
^^should
but in fact, also when using tm the CANCEL has 2 Via headers:
U 88.198.53.113:6060 -> 83.136.32.160:5060 CANCEL sip:klaus.darilion@nic.at43.at SIP/2.0. Max-Forwards: 10. Record-Route: sip:88.198.53.113:6060;lr=on;ftag=d421fe7e. Via: SIP/2.0/UDP 88.198.53.113:6060;branch=z9hG4bKdd22.f7f861b6.0. Via: SIP/2.0/UDP 10.10.0.50:13946;received=83.136.33.3;branch=z9hG4bK-d87543-2e40397a3e383c6b-1--d87543-;rport=13946. To: ... ...
regards klaus
end-2-end and it will have multiple VIAs...
Does 3665 obsoletes stateless SIP or it is just not covering it???
regards, bogdan
Klaus Darilion wrote:
Looks like it is defined clearly and openser is not 100% standard conform.
regards klaus
fancy wrote:
Hi Klaus: RFC 3665 page 54 line 4: A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled.
and RFC 3665 at page 53: CANCEL is referred to as a "hop-by-hop" request, since it is responded to at each stateful proxy hop.
and RFC 3665 at page 21: Client: A client is any network element that sends SIP requests and receives SIP responses. Clients may or may not interact directly with a human user. User agent clients and proxies are clients.
So, for my opinion, the role of proxy in this case of RFC 3665 section 3.8 is a client when it sends CANCEL message to Bob.
If I misunderstand any RFC meanings, please correct me. Thank you very much.
Best Regards, Fangyu Ling
fancy wrote:
According to RFC 3665 section 3.8 and RFC 3261 section 9, there is only one via header in CANCEL message (message F11, F13 at page 72 of RFC 3665).
Hi!
I could find it in RFC 3665, but not in 3261. Where exactly in RFC 3261 is mentioned that the CANCEL has only 1 Via header?
Further, the example has only one Via header - but I could not find any definition if this is a MUST or not.
How can I remove the 2nd via header?
You would have to modify tm module and change the code which generates the CANCEL message.
regards klaus
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Klaus,
you are right! in stateful mode, the CANCEL is routed hop by hop but not constructed (at least not by openser) - that is something I have on the todo list and really want to have in 1.3
regards, bogdan
Klaus Darilion wrote:
Bogdan-Andrei Iancu wrote:
Klaus,
CANCEL is hop-by-hop only in stateful processing and in this case, yes, it has only on VIA. But if you have stateless processing, CANCEL is
^^shouldbut in fact, also when using tm the CANCEL has 2 Via headers:
U 88.198.53.113:6060 -> 83.136.32.160:5060 CANCEL sip:klaus.darilion@nic.at43.at SIP/2.0. Max-Forwards: 10. Record-Route: sip:88.198.53.113:6060;lr=on;ftag=d421fe7e. Via: SIP/2.0/UDP 88.198.53.113:6060;branch=z9hG4bKdd22.f7f861b6.0. Via: SIP/2.0/UDP 10.10.0.50:13946;received=83.136.33.3;branch=z9hG4bK-d87543-2e40397a3e383c6b-1--d87543-;rport=13946.
To: ... ...
regards klaus
end-2-end and it will have multiple VIAs...
Does 3665 obsoletes stateless SIP or it is just not covering it???
regards, bogdan
Klaus Darilion wrote:
Looks like it is defined clearly and openser is not 100% standard conform.
regards klaus
fancy wrote:
Hi Klaus: RFC 3665 page 54 line 4: A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled.
and RFC 3665 at page 53: CANCEL is referred to as a "hop-by-hop" request, since it is responded to at each stateful proxy hop.
and RFC 3665 at page 21: Client: A client is any network element that sends SIP requests and receives SIP responses. Clients may or may not interact directly with a human user. User agent clients and proxies are clients.
So, for my opinion, the role of proxy in this case of RFC 3665 section 3.8 is a client when it sends CANCEL message to Bob.
If I misunderstand any RFC meanings, please correct me. Thank you very much.
Best Regards, Fangyu Ling
fancy wrote:
According to RFC 3665 section 3.8 and RFC 3261 section 9, there is only one via header in CANCEL message (message F11, F13 at page 72 of RFC 3665).
Hi!
I could find it in RFC 3665, but not in 3261. Where exactly in RFC 3261 is mentioned that the CANCEL has only 1 Via header?
Further, the example has only one Via header - but I could not find any definition if this is a MUST or not.
How can I remove the 2nd via header?
You would have to modify tm module and change the code which generates the CANCEL message.
regards klaus
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu wrote:
Klaus,
you are right! in stateful mode, the CANCEL is routed hop by hop but not constructed (at least not by openser) - that is something I have on the todo list and really want to have in 1.3
if you add this maybe it should be configurable to activate the old behavior - in case of clients having problems.
regards klaus
regards, bogdan
Klaus Darilion wrote:
Bogdan-Andrei Iancu wrote:
Klaus,
CANCEL is hop-by-hop only in stateful processing and in this case, yes, it has only on VIA. But if you have stateless processing, CANCEL is
^^shouldbut in fact, also when using tm the CANCEL has 2 Via headers:
U 88.198.53.113:6060 -> 83.136.32.160:5060 CANCEL sip:klaus.darilion@nic.at43.at SIP/2.0. Max-Forwards: 10. Record-Route: sip:88.198.53.113:6060;lr=on;ftag=d421fe7e. Via: SIP/2.0/UDP 88.198.53.113:6060;branch=z9hG4bKdd22.f7f861b6.0. Via: SIP/2.0/UDP 10.10.0.50:13946;received=83.136.33.3;branch=z9hG4bK-d87543-2e40397a3e383c6b-1--d87543-;rport=13946.
To: ... ...
regards klaus
end-2-end and it will have multiple VIAs...
Does 3665 obsoletes stateless SIP or it is just not covering it???
regards, bogdan
Klaus Darilion wrote:
Looks like it is defined clearly and openser is not 100% standard conform.
regards klaus
fancy wrote:
Hi Klaus: RFC 3665 page 54 line 4: A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled.
and RFC 3665 at page 53: CANCEL is referred to as a "hop-by-hop" request, since it is responded to at each stateful proxy hop.
and RFC 3665 at page 21: Client: A client is any network element that sends SIP requests and receives SIP responses. Clients may or may not interact directly with a human user. User agent clients and proxies are clients.
So, for my opinion, the role of proxy in this case of RFC 3665 section 3.8 is a client when it sends CANCEL message to Bob.
If I misunderstand any RFC meanings, please correct me. Thank you very much.
Best Regards, Fangyu Ling
fancy wrote:
> According to RFC 3665 section 3.8 and RFC 3261 section 9, > there is only one via header in CANCEL message > (message F11, F13 at page 72 of RFC 3665). > Hi!
I could find it in RFC 3665, but not in 3261. Where exactly in RFC 3261 is mentioned that the CANCEL has only 1 Via header?
Further, the example has only one Via header - but I could not find any definition if this is a MUST or not.
> How can I remove the 2nd via header? > You would have to modify tm module and change the code which generates the CANCEL message.
regards klaus
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
do you think there might be UAS cracking if they get one VIA CANCEL? anyhow, this perfect possible even now if the CANCEL is really generated by the previous hope.
regards, bogdan
Klaus Darilion wrote:
Bogdan-Andrei Iancu wrote:
Klaus,
you are right! in stateful mode, the CANCEL is routed hop by hop but not constructed (at least not by openser) - that is something I have on the todo list and really want to have in 1.3
if you add this maybe it should be configurable to activate the old behavior - in case of clients having problems.
regards klaus
regards, bogdan
Klaus Darilion wrote:
Bogdan-Andrei Iancu wrote:
Klaus,
CANCEL is hop-by-hop only in stateful processing and in this case, yes, it has only on VIA. But if you have stateless processing, CANCEL is
^^shouldbut in fact, also when using tm the CANCEL has 2 Via headers:
U 88.198.53.113:6060 -> 83.136.32.160:5060 CANCEL sip:klaus.darilion@nic.at43.at SIP/2.0. Max-Forwards: 10. Record-Route: sip:88.198.53.113:6060;lr=on;ftag=d421fe7e. Via: SIP/2.0/UDP 88.198.53.113:6060;branch=z9hG4bKdd22.f7f861b6.0. Via: SIP/2.0/UDP 10.10.0.50:13946;received=83.136.33.3;branch=z9hG4bK-d87543-2e40397a3e383c6b-1--d87543-;rport=13946.
To: ... ...
regards klaus
end-2-end and it will have multiple VIAs...
Does 3665 obsoletes stateless SIP or it is just not covering it???
regards, bogdan
Klaus Darilion wrote:
Looks like it is defined clearly and openser is not 100% standard conform.
regards klaus
fancy wrote:
Hi Klaus: RFC 3665 page 54 line 4: A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled.
and RFC 3665 at page 53: CANCEL is referred to as a "hop-by-hop" request, since it is responded to at each stateful proxy hop.
and RFC 3665 at page 21: Client: A client is any network element that sends SIP requests and receives SIP responses. Clients may or may not interact directly with a human user. User agent clients and proxies are clients.
So, for my opinion, the role of proxy in this case of RFC 3665 section 3.8 is a client when it sends CANCEL message to Bob.
If I misunderstand any RFC meanings, please correct me. Thank you very much.
Best Regards, Fangyu Ling
> fancy wrote: > >> According to RFC 3665 section 3.8 and RFC 3261 section 9, >> there is only one via header in CANCEL message >> (message F11, F13 at page 72 of RFC 3665). >> > Hi! > > I could find it in RFC 3665, but not in 3261. Where exactly in > RFC 3261 > is mentioned that the CANCEL has only 1 Via header? > > Further, the example has only one Via header - but I could not > find any > definition if this is a MUST or not. > > >> How can I remove the 2nd via header? >> > You would have to modify tm module and change the code which > generates > the CANCEL message. > > regards > klaus
-
Bogdan-Andrei Iancu -
fancy -
Klaus Darilion