[SIPForum-discussion] Cancelling SIP CALL in Proceeding State

[Binan AL Halabi]

Hi Banda, 


This depends on the network paths the calls go in due to pre-defined rules. More information about your topology will be appreciated.

// Binan

Thanks.


________________________________
 Från: "Banda, Srinivas (Srinivas)" <sribanda at avaya.com>
Till: Binan AL Halabi <binanalhalabi at yahoo.com> 
Skickat: onsdag, 21 augusti 2013 12:42
Ämne: RE: [SIPForum-discussion] ICE - Connectivity check Algorithm
 


 
Hi Binan,
 
If there is a timer which triggers this CANCE in proceeding state, then none of the calls should successfully completed in their environment.
The name of the thread “ICE- Connectivity Check Algorithm” doesn’t have any relation to the problem which Anand is facing.
 
Regards
Srinivas
 
From:Binan AL Halabi [mailto:binanalhalabi at yahoo.com] 
Sent: Wednesday, August 21, 2013 4:05 PM
To: Banda, Srinivas (Srinivas)
Cc: anandkumar4n at gmail.com; discussion at sipforum.org
Subject: SV: [SIPForum-discussion] ICE - Connectivity check Algorithm
 
Hi Bande,

First: Maybe there is a timer which triggers the CANCEL. Doing this in proceeding state "when receiving a provisional response" not in the initial state "calling"  would be an implementation issue.

Second: Have a look on the name of this thread: "ICE - Connectivity check Algorithm" 
 
 
Thanks.

________________________________
 
Från:"Banda, Srinivas (Srinivas)" <sribanda at avaya.com>
Till: anand kumar Vijayan <anandkumar4n at gmail.com>; "discussion at sipforum.org" <discussion at sipforum.org> 
Skickat: måndag, 19 augusti 2013 12:32
Ämne: Re: [SIPForum-discussion] ICE - Connectivity check Algorithm
 
 
If you see above call flow, once the PRACK gets 200 OK response, immediately 173.230.226.246 is sending the CANCEL Message? Is there any reason why the originating end is sending the CANCEL message.
 
 
From:discussion-bounces at sipforum.org [mailto:discussion-bounces at sipforum.org] On Behalf Of anand kumar Vijayan
Sent: Wednesday, August 07, 2013 9:50 AM
To: discussion at sipforum.org
Subject: Re: [SIPForum-discussion] ICE - Connectivity check Algorithm
 
HI All, 
 I have one call scenario, our customer not getting 200 OK with SDP from your side after PRACK which is resulting in call failure. 
 Many calls are  getting abandoned due to the reason i explained above, signal trace attached for your reference.
 Kindly confirm due above scenario any call failure happen or not, if call failure happen then how to resolve the issue. 
 
Please help us
 
Regards 
Anand Kumar V
919650930689
 
 
On Tue, Jul 30, 2013 at 11:02 AM, rahul sankanur <rahul.sankanur at gmail.com> wrote:
Hi , 
In ICE rfc 5245, it is mentioned that connectivity checks will start for the first media stream(as mentioned in SDP) . 
There is also a mention that each media stream will have independent timers which decides the interval between connectivity checks and RTO for those candidates,
 
I have a doubt here.
 
Connectivity checks will begin at the same time for all media stream 
                                              OR
connectivity checks will begin for the second media stream only after first media stream's connectivity checks are over.

Regards,
Rahul Sankanur
 

_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org
 

_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20130821/69750367/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 23482 bytes
Desc: image001.png
URL: <http://sipforum.org/pipermail/discussion/attachments/20130821/69750367/attachment-0002.png>