On Tue, Apr 29, 2008 at 12:56 AM, Tilghman Lesher <<a href="mailto:tilghman@mail.jeffandtilghman.com">tilghman@mail.jeffandtilghman.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c"><br>
> May be I'm missing something basic and someone can help clarify it for me.<br>
> I've dealt with this with Cisco Call Manager 6.X and Cisco 7960 phones that<br>
> support KPML (KeyPad Markup Language; a dialplan language expressed in XML)<br>
> that support this feature. The part that escapes me is that why do we need<br>
> Asterisk dial-plan to be stateful across INVITE/484 pairs if both the SIP<br>
> phone and the SIP trunk understand the 484 semantics.<br>
><br>
> Why can't we treat 484 received on the SIP trunk as a failed call and<br>
> propagate that specific response code to the phone and eliminate that state<br>
> from the Asterisk dial-plan? Remember that the phone sends the previous<br>
> digits in the new INVITEs after receiving 484s so that the To: or R-URI<br>
> eventually satisfies the SIP trunk provider's routing plan.<br>
><br>
> But like I said, I may be missing something basic. What would that be?<br>
<br>
</div></div>You're missing that Asterisk is not a SIP proxy. That would be the expected<br>
behavior of a SIP proxy, but Asterisk is a Back-To-Back-User-Agent, which<br>
means that Asterisk needs to actually understand the code passed back and<br>
needs to be able to deal with that code in a protocol agnostic way.<br>
<div><div></div><div class="Wj3C7c"></div></div></blockquote><div><br>My question is whether this should be done in a stateless or stateful manner through Asterisk. Proxy vs. B2BUA or protocol agnostic handling are irrelevant from that perspective. <br>
<br>There are a couple of modes in which Asterisk could potentially participate in overlap dialing:<br><br>1. Overlap to en-bloc gateway (as described in RFC 3578)<br>2. End-to-end overlap <br><br>End-to-end overlap mode (the subject of this email thread) is where the phone and trunk both support overlap signaling. This is a scenario where Asterisk isn't aware of the numbering plan and thus relies on an upstream entity to decide how many digits should be dialed. A common deployment scenario for this PBX-PBX trunking using Q.SIG. Since SIP doesn't exactly support overlap signaling, we rely on the 484 message to signal to the UAC that more digits need to be sent. <br>
<br>Now the question is should Asterisk call processing (dial-plan) do something (e.g. remember the state) when it receives an address incomplete message on the trunk (SIP, ISDN or whatever). The thing about SIP 484 is that it is a final response code and the INVITE transaction is over as soon as the 484 is received. The next INVITE will contain a completely different transaction id and call id, so you can't correlate the INVITE's anyway. That is why I was thinking that 484 should be treated simply as call failure such as 404. All we should have to do is tell the phone to send more digits if our trunk provider tells us that.<br>
</div></div>-- <br>Raj Jain<br><br><br>