[ previous ] [ next ] [ threads ]
 To :  Paul Chitescu <paulc@v...>
 From :  andrzej.ciupek@a...
 Subject :  Re: [yate] sip cancel close all the session
 Date :  Mon, 25 Jun 2012 14:30:12 +0200
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
>