[ previous ] [ next ] [ threads ]
 To :  Stephane <stephane@s...>
 From :  andrzej.ciupek@a...
 Subject :  Re: [yate] sip cancel close all the session
 Date :  Tue, 03 Jul 2012 08:14:43 +0200

Our B2BUA uses two values: 'Cseq' and 'branch' from the top 'via'  
header in order to cancel the transaction (but not the whole dialog).

In order to disconnect the first callee and forward the call to the  
second callee (in case of Follow-Me) only the transaction (the INVITE  
to the first callee) should be canceled.

It seems, that Yate can only cancel the whole dialog once the 'CANCEL'  
message is received. This behavior does not allow to configure the  
call scenarios with forwarding when the call comes from the vendor and  
then goes to the same vendor.

But there is also a point in RFC:

The chapter 17 of the RFC3261 http://www.ietf.org/rfc/rfc3261.txt is  
useful there:

17.1.3 Matching Responses to Client Transactions
When the transport layer in the client receives a response, it has to
    determine which client transaction will handle the response, so that
    the processing of Sections 17.1.1 and 17.1.2 can take place.  The
    branch parameter in the top Via header field is used for this
    purpose.  A response matches a client transaction under two

       1.  If the response has the same value of the branch parameter in
           the top Via header field as the branch parameter in the top
           Via header field of the request that created the transaction.

       2.  If the method parameter in the CSeq header field matches the
           method of the request that created the transaction.  The
           method is needed since a CANCEL request constitutes a
           different transaction, but shares the same value of the branch


> Hello,
>> Is there a way that You change code in some future releases that every
>> call leg will be identified by Call ID and CSeq ?
> I don't think that's the proper way to identify calls. RFC3261 says
> (section 12, "Dialogs"):
>    A dialog is identified at each UA with a dialog ID, which consists of
>    a Call-ID value, a local tag and a remote tag.
>    [...]
>    A dialog ID is also associated with all responses and with any
>    request that contains a tag in the To field.
> and then goes on how to compute the dialog ID for different scenarios.
> I'm tempted to ask whether, in Andrzej's application, the different
> calls are properly identified with different Dialog ID's (not just
> Call-IDs)?
> If you re-use a given Call-ID with the same To-tag then effectively you
> only have one call ("dialog") and Yate would be right to terminate
> anything related to that call at once.
> HTH,
> S.