[VoiceOps] SIP phone without using local dial plan

[Stephen Sprunk]

On 23-Sep-11 09:08, Mark R Lindsey wrote:
> Normally, the SIP endpoint that device that collects digits is
> responsible for knowing when a correct and complete number pattern has
> been dialed. The same is true for MGCP devices when configured to
>  match a digitmap; they only send off the NTFY when a pattern of
> digits has been dialed, or else a timeout has occurred.
>
> I'm almost certain that there is no way in the Cisco 7940/7960 SIP
> firmware to override this norm. You probably need to configure the
> digit map in the phone to match the digit map from your /switch/.

That's the normal expectation.  However, if the client and server
correctly implement the 484 (Address Incomplete) error code, that is not
required.  Here's how it /should/ work:

1. User dials "9"
2. Client sends INVITE for sip:9 at server (or tel:9)
3. Server responds with 484
4. Client waits for more digits
5. User dials "1"
6. Client sends INVITE for sip:91 at server (or tel:91)
7. Server responds with 484
8. Client waits for more digits
9. User dials "1"
10. Client sends INVITE for sip:911 at server (or tel:911)
11. Server completes call normally

I have no idea whether the Cisco 79xx code does this, but it should be
relatively easy to test if your server is known to support it: just give
the phone a digit map that accepts any single digit and see what happens.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20110923/6f040c47/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20110923/6f040c47/attachment.bin>