[OpenSIPS-Devel] [B2B_ENTITIES] Difference between sending CANCEL and BYE

[Anca Vamanu]

Hi Olivier,

First, please do not send email to me privately ( use reply all).
You are saying that the CANCEL send by b2b_entities does not have the 
exact ruri as INVITE?

Can you catch an INVITE and the corresponding CANCEL (send by 
b2b_entities) and send them in an e-mail?

Regards,

-- 
Anca Vamanu
www.voice-system.ro



Olivier Détour wrote:
> On Thu, Jan 28, 2010 at 1:05 PM, Anca Vamanu <anca at opensips.org> wrote:
>   
>> Hi Olivier,
>>
>> Olivier Détour wrote:
>>     
>>> 2010/1/22 Olivier Détour <chino540off+kamailio at gmail.com>:
>>>
>>>       
>>>> Hi,
>>>>
>>>> I understand the problem, but I would like to explain you my topology:
>>>>
>>>>                     Broker1             Broker2
>>>>                         |                       |
>>>> Tel(10) ---------- B2BUA1 ---------- B2BUA2 ---------- Tel(20)
>>>>
>>>> My problem is when 10 calls 20, 20 is ringing (so B2BUAs create their
>>>> UAS and UAC).
>>>> I want to be able to brake the current SIP session at this moment.
>>>> So I send the CANCEL to UAC side on B2BUA1. But B2BUA2 doesn't want to
>>>> receive it,
>>>> because It is not send to sip:sa at 1.1.12.3. So message could not be
>>>> transmit to B2BUA2 ...
>>>>
>>>> Maybe, I don't understand something here, but b2b_entities API could
>>>> be able to manage
>>>> this situation ?
>>>>
>>>> Regards,
>>>>
>>>>
>>>>         
>>> Hi,
>>>
>>> I went through the source code of B2B_entities, and I don't understand
>>> when you search the dlg in int b2b_prescript_f(struct sip_msg *msg,
>>> void *uparam) in dlg.c:
>>>
>>>  357           while(dlg)
>>>  358           {
>>>  359                   if(ruri.len == dlg->ruri.len && strncmp(ruri.s,
>>> dlg->ruri.s,
>>> ruri.len)== 0
>>>  360                                   && dlg->callid.len == callid.len &&
>>>  361                                   strncmp(dlg->callid.s, callid.s,
>>> callid.len)== 0 &&
>>>  362                                   dlg->tag[CALLER_LEG].len ==
>>> from_tag.len &&
>>>  363                                   strncmp(dlg->tag[CALLER_LEG].s,
>>> from_tag.s, from_tag.len)== 0)
>>>
>>> You check CALLID, FROM_TAG and the REQUEST_URI. If you create the UAS
>>> with B2BUA_entities,
>>> Requests send by caller will change Request URI to speaks directly with
>>> UAS.
>>>
>>> Why is the RURI in your search?
>>>
>>> When I remove the RURI check, it works as my understanding of the RFC.
>>>
>>> Regards,
>>>
>>>
>>>       
>> The RURI check was added exactly because the RFC says that the RURI in
>> CANCEL must be exactly the same as the RURI in INVITE:
>>
>> The following procedures are used to construct a CANCEL request.  The
>>  Request-URI, Call-ID, To, the numeric part of CSeq, and From header
>>  fields in the CANCEL request MUST be identical to those in the
>>  request being cancelled, including tags.
>>
>>
>> Regards,
>>
>>     
>
> I understand the RFC, but I think B2B_Entities is not able to send a
> CANCEL to another
> B2B_Entities and receive it.
>
> So There is a problem, I try to make the architecture with 2 B2B, and
> CANCEL is my last problem.
> I would like to understand how to send and receive CANCEL from and to B2B.
>
> Regards,
>
>