[ previous ] [ next ] [ threads ]
 To :  Paul Chitescu <paulc@v...>
 From :  andrzej.ciupek@a...
 Subject :  Re: [yate] sip cancel close all the session
 Date :  Wed, 27 Jun 2012 20:53:11 +0200
Hello

Our system base on Call ID, and all session for one incomming  
connection is identified by Call ID. Every followme that works as  
calling callee one by one, after declared timeout has different CSeq.  
So If we receive call from PSTN, and Our b2bua send INVITE to make  
followme to PSTN number by the same Gateway, CSeq is only difference  
for that session.

Is there a way that You change code in some future releases that every  
call leg will be identified by Call ID and CSeq ?

Greetings
Andrzej



> Hi!
>
> What you found is the problem, the code assumes the Call ID identifies the
> call leg.
>
> Paul
>
>
> On Wednesday 27 June 2012 04:33:05 pm andrzej.ciupek@a... wrote:
>> 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
>