I thing about this session 17.1.2.2 is not a INVITE is a REGISTER<br><br><div class="gmail_quote">On Thu, Jun 18, 2009 at 1:17 PM, Kristian Kielhofner <span dir="ltr"><<a href="mailto:kristian.kielhofner@gmail.com">kristian.kielhofner@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Thu, Jun 18, 2009 at 12:03 PM, Mark Michelson <<a href="mailto:mmichelson@digium.com">mmichelson@digium.com</a>> wrote:<br>
><br>
> David Hansen wrote:<br>
> > Are your PBX and phone on same subnet? Is the phone SIP capable and listening on port 5060? You mention T1, but this has no relationship to SIP convos.<br>
> ><br>
> > David Hansen<br>
><br>
> In SIP, there is a timer called T1 used as a base for calculating retransmission<br>
> times.<br>
><br>
> In answer to the originally-posted question, the SIP T1 timer defaults to 500<br>
> ms. Looking at the code in sip_reliable_xmit, we set a value called siptimer_a<br>
> to be 2 * pkt->timer_t1. This value is what is passed to the scheduler for the<br>
> retransmission time.<br>
><br>
> Reading RFC 3261, section <a href="http://17.1.1.2" target="_blank">17.1.1.2</a>:<br>
><br>
> "If an unreliable transport is being<br>
> used, the client transaction MUST start timer A with a value of T1.<br>
> If a reliable transport is being used, the client transaction SHOULD<br>
> NOT start timer A (Timer A controls request retransmissions). For<br>
> any transport, the client transaction MUST start timer B with a value<br>
> of 64*T1 seconds (Timer B controls transaction timeouts).<br>
><br>
> When timer A fires, the client transaction MUST retransmit the<br>
> request by passing it to the transport layer, and MUST reset the<br>
> timer with a value of 2*T1."<br>
><br>
> So it appears that this may be an instance where we are doing things a bit<br>
> out-of-spec here. I wonder if there was some sort of justification for this when<br>
> it was written...<br>
><br>
> Mark Michelson<br>
><br>
<br>
</div>IIRC the T1 value is calculated based off of whatever qualify returns<br>
(if enabled). I don't remember what happens if you have qualify<br>
disabled...<br>
<br>
This may have changed in recent versions but I remember it being<br>
correct at some point in time.<br>
<font color="#888888"><br>
--<br>
Kristian Kielhofner<br>
<a href="http://www.astlinux.org" target="_blank">http://www.astlinux.org</a><br>
<a href="http://blog.krisk.org" target="_blank">http://blog.krisk.org</a><br>
<a href="http://www.star2star.com" target="_blank">http://www.star2star.com</a><br>
<a href="http://www.submityoursip.com" target="_blank">http://www.submityoursip.com</a><br>
<a href="http://www.voalte.com" target="_blank">http://www.voalte.com</a><br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--" target="_blank">http://www.api-digital.com--</a><br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Eduardo Nunes Pereira<br>Consultor de Informática e Internet<br>cel.: (48) 9989-2997<br>email: <a href="mailto:eduardonunesp@gmail.com">eduardonunesp@gmail.com</a><br>