[ previous ] [ next ] [ threads ]
 To :  andrzej.ciupek@a...
 From :  andrzej.ciupek@a...
 Subject :  Re: [yate] sip cancel close all the session
 Date :  Wed, 27 Jun 2012 15:33:05 +0200
Hello

Our b2bua send CANCEL with CSeq: 369, but it looks like Yate close SIP  
session based only on Call-ID without CSeq? Is it possible ?
Incommig call from PSTN site has CSeq 541300, Our b2bua send CANCEL  
with CSeq: 369, that belong to INVVITE to callee from followme,after  
that incommig session is terminated too.

As I see CANCEL looks like:

if (t->getMethod() ==
YSTRING("CANCEL")) {
YateSIPConnection* conn =
plugin.findCall(t->getCallID(),true);
if (conn) {
conn->doCancel(t);

conn->deref();
}

so does getCallID() contain CSeq ?

Greetings
Andrzej

> Hello
>
> Yes it is configuration with b2bua that send Invite. So in real it is:
>
> Yate -> SipProxy(5060) -> b2bua(5061)
>
> Call ID is Call-ID: 1232579982@1...
>
> Yate send INVITE to SIP Proxy (CSeq: 541300 INVITE)
> SIP Proxy send 100 Trying to Yate (CSeq: 541300 INVITE)
> SIP Proxy send that INVITE to b2bua (CSeq: 541300 INVITE)
> b2bua send  100 Trying to SIP Proxy (CSeq: 541300 INVITE)
>
> Here start RTP Proxy
>
> b2bua send INVITE to Yate (CSeq: 369 INVITE)
> Yate response 100 Trying to b2bua (CSeq: 369 INVITE)
> Yate response 183 Session Progress to b2bua (CSeq: 369 INVITE)
> b2bua send 183 Session Progress to SIP Proxy (CSeq: 541300 INVITE)
> SIP Proxy send 183 Session Progress to Yate (CSeq: 541300 INVITE)
> Yate send 180 Ringing to b2bua (CSeq: 369 INVITE)
> b2bua send 180 Ringing to SIP Proxy (CSeq: 541300 INVITE)
> SIP Proxy send 180 Ringing to Yate (CSeq: 541300 INVITE)
> b2bua send CANCEL to Yate (CSeq: 369 CANCEL)
>
> After that Incomming call from PSTN to Yate to Our SIP is
> disconnected,so it looks like CANCEL disconnect Call-ID, not Call-ID
> with CSeq: 369.
>
> Greetings
> Andrzej
>
>
>> Hi!
>>
>> A forked request would differ only in the topmost Via header(s) and  
>>   each early
>> dialog will have a diffrent tag= in the To header.
>>
>> Since the CSeq is different what you have is not a proxy but a B2BUA or
>> stateful topology hiding proxy. It must have a different bottommost  
>>   Via header
>> and as such a different SIP/2.0 unique transaction id tag.
>>
>> Please investigate what happens inside you equipment. Does it send anything
>> back to Yate on the first call leg?
>>
>> Regards,
>>
>> Paul
>>
>>
>> On Monday 25 June 2012 02:46:43 pm andrzej.ciupek@a... wrote:
>>> Hello
>>>
>>> It is all made by INVITE:
>>>
>>> We receive Invite from Yate:
>>> CSeq: 540030 INVITE
>>>
>>> SIP Proxy Receive it and send back INVITE to dst PSTN number:
>>> CSeq: 695 INVITE
>>>
>>> SIP Proxy receive Trying, Session Progress, Ringing, and after timeout
>>> of 15sec (this is set by Us, to limit time of follow-me, after 15sec
>>> it start to send next INVITE CSeq: 784 INVITE) SIP Proxy send:
>>>
>>> CSeq: 695 CANCEL
>>>
>>> It cause that Incomming INVITE CSeq: 540030 INVITE is disconnected.
>>>
>>> Greetings
>>> Andrzej
>>>
>>>> Hi!
>>>>
>>>> You need a capture to analyze what really happens.
>>>>
>>>> Does the SIP proxy fork the INVITE? Note that SIP forking is for
>>>> simultaneous calls, not sequential. A sequential fork would need some
>>>> clever SIP tricks to make sure at least one early dialog remains alive at
>>>> all times. Unless both UAC and UAS support reliable 1xx provisional even
>>>> this would be unreliable.
>>>>
>>>> Paul
>>>>
>>>> On Monday 25 June 2012 01:56:28 pm andrzej.ciupek@a... wrote:
>>>>> Hello
>>>>>
>>>>> I have, a scenario:
>>>>>
>>>>> Incomming call from PSTN goes to Yate, that send Invite to My SIP Proxy,
>>>>> SIP Proxy create follow-me to 3 PSTN numbers One by One. That calls
>>>>> goes Out to PSTN by the same Yate. After first no answered call (1st
>>>>> from follow-me list), but according to the RFC 3261 the Sip Proxy sent
>>>>> the 'CANCEL' message in order to disconnect the first callee's leg
>>>>> correctly before starting to send the 'INVITE' messages to the second
>>>>> callee (second PSTN number form follow-me list). After that Yate
>>>>> closes all the sessions after the 'CANCEL' message to the first callee
>>>>> (1st from the follow-me list).
>>>>>
>>>>> 1. --->Caller--->PSTN(Cisco)---->Yate-->SIP Proxy
>>>>> 2. Sip Proxy get list of numbers from follow-me
>>>>> 3. SIP proxy make call to PSTN number 1st from list
>>>>> 4. ->SIP Proxy-> get callee number ---> Yate ---> PSTN(cisco)--->
>>>>> 5. the callee is noanswered, so SIP Proxy send CANCEL after timeout of
>>>>> first follow-me to Yate, to disconnect the first callee's leg,
>>>>> 6. ->SIP Proxy-> get 2nd callee number ---> Yate ---> PSTN(cisco)--->
>>>>>
>>>>> But in point number 5, Yate Disconnect Caller session too.
>>>>> Is there a way to solve this trouble ?
>>>>>
>>>>> The configuration at Yate is Cisco SLT + MGCP.
>>>>>
>>>>> Greetings
>>>>> Andrzej
>>