[OpenSER-Users] The Via Header of CANCEL Message

[Bogdan-Andrei Iancu]

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 
>>>
>>>      ^^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 at 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
>