[asterisk-users] Dial timeout with SIP - how to set timeout for INVITE ACK

[Julien Chavanton]

"You want to know if the remote address/proxy is up and running before you
bother trying to wait on it for very long. Is this right?" , yes this would be a good start ?
 
- But the IP could be up and the SIP service down, we need a signaling timeout, I beleive a good way in term of responsability would be :
 If I do not receive a response to the SIP INVITE in timeout duration then I would cancel the call and try with another route.
 
- With AGI can we control and react to the signaling events, I guess not ?

Thank you
 
________________________________

From: asterisk-users-bounces at lists.digium.com on behalf of SIP
Sent: Thu 18/12/2008 6:13 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Dial timeout with SIP - how to set timeout for INVITE ACK




>
> ------------------------------------------------------------------------
> *From:* asterisk-users-bounces at lists.digium.com on behalf of Philipp
> Kempgen
> *Sent:* Thu 18/12/2008 4:17 PM
> *To:* Asterisk Users
> *Subject:* Re: [asterisk-users] Dial timeout with SIP - how to set
> timeout for INVITE ACK
>
> Julien Chavanton schrieb:
> > I have a concern with Dial command, I want to enable a secondary
> route with a remote partner, if the first route fails then we use the
> second one :
>
> > Solution1: it will try both (there will be 2 simultanious actives
> calls ringing) this is not clean when calling an endusers
> >
> >  exten => _X.,1,Dial(SIP/${EXTEN}@remote-sip1,5
> <SIP/${EXTEN}@remote-sip1,5 <mailto:SIP/$%7BEXTEN%7D at remote-sip1,5>> )
> >  exten => _X.,1,Dial(SIP/${EXTEN}@remote-sip2,5
> <SIP/${EXTEN}@remote-sip2,5 <mailto:SIP/$%7BEXTEN%7D at remote-sip2,5>> )
>
> You can't have the same "priority" (1) more than once per
> extension (_X.).
>
> > Solution2: it will wait until 5 seconds of timeout (on answer) and
> then try the second alternative "n"
> >
> >  exten => _X.,1,Dial(SIP/${EXTEN}@remote-sip1,5
> <SIP/${EXTEN}@remote-sip1,5 <mailto:SIP/$%7BEXTEN%7D at remote-sip1,5>> )
> >  exten => _X.,n,Dial(SIP/${EXTEN}@remote-sip2,5
> <SIP/${EXTEN}@remote-sip2,5 <mailto:SIP/$%7BEXTEN%7D at remote-sip2,5>> )
> >
> > the problem is we can not select what timeout represents, timeout on
> ACK from INVITE would be perfect I think (1 second for example),
> timeout for answer ? this is to hard to predict, some mobile phone can
> ring for 30 seconds, etc.
>
> So why not use 30 and let Asterisk take care of the SIP details/
> timeouts?
>
> And just to be sure: Don't put those "mailto" things in
> extensions.conf.  :-)
>
>
>    Philipp Kempgen
>
Julien Chavanton wrote:
> >So why not use 30 and let Asterisk take care of the SIP details/
> >timeouts?
> 
> Asterisk will wait the until it receive "answer" or timeout
> 
> I need to timeout a SIP call on SIP INVITE ACK, in ISDN for exmaple
> this is translated to PROCEEDING
> Meaning "I have received the call, now I will look what to do with it"
> 
> The result with the suggested timeout is not good enought, you may
> wait for the whole timeout even if the other side as not sent
> anything, this will be the case for all your calls, depending on the
> timeout this would be killing the traffic.
> 
> 

It sounds as though you want the result of the SIP INVITE (looking for,
say, a provisional 1XX response) and want the timeout to be set for
whether or not you receive the provisional response in time?  i.e. You
want to know if the remote address/proxy is up and running before you
bother trying to wait on it for very long. Is this right? Or am I
missing the point of the question?

N.

_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com <http://www.api-digital.com/>  --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20081218/da70f9b1/attachment.htm