It's not a silly idea, I've been doing some sniffing and debugging with my limited knowledge of the whole process. I found this in the debug stream after having dialed "965").
Notice this line: SIP/2.0 484 Address Incomplete. Is this what I was suspecting, that it knows it could match a pattern (_9XXXXX) with a few more digits and so waiting for those digits from the user? How can I disable this or turn it off? The Polycom 501 "supports 484 responses", but how can I either: 1) Disable it in the phone 2) Disable it in Asterisk Mike Using INVITE request as basis request - [EMAIL PROTECTED] Sending to 192.168.1.200 : 5060 (NAT) Found user '000f42056d58-1' Found RTP audio format 0 Found RTP audio format 8 Found RTP audio format 18 Found RTP audio format 101 Peer audio RTP is at port 192.168.1.200:2228 Found description format PCMU Found description format PCMA Found description format G729 Found description format telephone-event Capabilities: us - 0x106 (gsm|ulaw|g729), peer - audio=0x10c (ulaw|alaw|g729)/video=0x0 (nothing), combined - 0x104 (ulaw|g729) Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event) Looking for 965 in context_a (domain test.test.ca) Reliably Transmitting (NAT) to 45.67.312.45:5060: SIP/2.0 484 Address Incomplete Via: SIP/2.0/UDP 192.168.1.200;branch=z9hG4bK93732511F5970F9E;received=45.67.312.45 From: "CAP" <sip:[EMAIL PROTECTED]>;tag=DAD6C20C-68263D4F To: <sip:[EMAIL PROTECTED];user=phone>;tag=as4db2b55c Call-ID: [EMAIL PROTECTED] CSeq: 2 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:[EMAIL PROTECTED]> Content-Length: 0 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rushowr Sent: September 8, 2006 4:21 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] What don't I get about SIP? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike wrote: > Thanks Tim. > > I've been trying to find out what's happening. Basically, somehow, it > seems that my Polycom 501 knows what extensions are valid and which > aren't in my dialplan. Obviously, the 501 doesn't really know that, > but Asterisk seems to return it this info (sort of :"valid", "invalid" > or "could be valid, need more digits to know") when I press send. > > I know it sounds mad, and I would love nothing more than being told I > am an idiot because or x and y. Why do I feel that this info is > passed from Asterisk to the 501? > > Well, take the following (very simple) dialplan > > [context_a] > Exten => 1234,1,Noop(foo) > > Exten => _9XXXX,1,Noop(bar) > > Exten => i,1,Noop(invalid) > > > What happens when I dial out is the following: > > 1) 1234: Noop(foo) ; good > > 2) 444444444: A congestion tone is heard from the phone (but > Asterisk's CLI doesn't show anything...no "sent into invalid extension > '444444444' in context 'context_a', but no invalid handler > > 3) 934 : It's invalid, but it could match the pattern is I added some > digits. I expect an invalid extension message, but what actually > happens is the phone tries the send something (I can see an icon > moving on the phone) but the phone stays quiet (no stuttering tone or > whatever). It waits, I can input more digits on the phone. > > Let's just take 1) and 2). Why is Asterisk not going into the i > extension like it should? > > Mike > > > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tim St. > Pierre > Sent: September 8, 2006 2:54 PM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] What don't I get about SIP? > > With SIP, asterisk processes the digits it receives in the invite from > the Polycom. > > There is no communication of dialplan information in SIP. The polycom > should send the digits as soon as you press dial. You can program the > polycom with a dialplan that will tell it when to send the digits, but > that only works if you dial off-hook. I like on hook dialling, since > it sends what i tell it, when I tell it. This should never happen > when you press dial - it should try right away. My 301 does this, > maybe they changed something in the newer firmware? > > -Tim > > On September 8, 2006 14:33, Mike wrote: >> I've been running into an issue with my Polycom 501 and Asterisk. >> >> I realized, after much mucking around, that when I dial a number (and >> press the send key) that is invalid , but could still match an >> Asterisk pattern >> (example: I dial 567, which is not a valid extension, but my diaplan >> accepts _567XXXX as a pattern) instead of sending the call as is and >> ultimately failing, the phone is "intelligent enough" to sit and wait >> for extra digits in case I meant to dial 567111. >> >> Now thats a problem for me. How can I make Asterisk (or the 501) >> treat the attempted extension 567 as a valid try and let Asterisk >> handle the error ?(instead of the phone trying to do what it think is >> best and handling the error on it's own). >> >> Is there an Asterisk setting for that? >> Failing that, is there a Polycom setting to disable this "intelligent" >> error handling? >> >> >> Mike > > -- > Tim St. Pierre > > IP telephony specialist > sip://[EMAIL PROTECTED] > Toronto: 647 722 6930 > Toll-Free 1 888 488 6940 > [EMAIL PROTECTED] > > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > Silly idea, why don't you sniff the packets being sent over port 5060? You'll be able to verify the conversation taking place. - -- S McGowan VoIP Consultant [EMAIL PROTECTED] - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.5 (MingW32) - WinPT 0.12.3 mQGiBETxLJERBACrFvzk3Hd8AO9aGCSSgoabp8GGS7jYhR1UP9zqYeJIHeH+/r/D sCL0mPUGX1+FnVlh5UAO0Q3hueCdtgbAhdqMJMDhjQ2Tm10kBWu2DjWrLVnGx0QD Id1XAiQ1WIJkE2VqphKD0WVMsyxj08w+o+DwjD+mu3GCgitRTVOB9OnzpwCg3Ynx BHlbNUzLTp+3oUuudndpaiEEAIlBCJoIg+zCTg4/kFjsWfSYo3kTwNoQPqqMINMe GM15CkRvXgUdMgJMPeEqXNmfnUUHNf/6KD2WpP5kJcBZdNWHicvS+A+P1Sjuybio 5XlJgMDW5tzCX0V45n+RgZQjHMg1wpcv0eVOMhmaSL4eC7MyUnZBHzuBYmgNMpiM EF2wA/4y+hhoZ2SYUzTWk4QUPL8yaHTNS/4/aH8AB5cyRNljqT5//AXzYF3AxMZX bslWy4MtzX9CI9Zg8hxIzcaYp/oeFSVrv6Or/8ZRQk2T+eB7ymPY6T+SOcKfTgR2 f9kzlxtPjRK/nXDovjaaOGl0U0NaPemB0w8fEuNkF4LxKdAea7QgUyBNY0dvd2Fu IDxydXNob3dyQHBocmVha2VyLm5ldD6IYAQTEQIAIAUCRPEskQIbAwYLCQgHAwIE FQIIAwQWAgMBAh4BAheAAAoJEJX0LL+xQYafrbQAoKFzcLsRIkXWL1wzldi2iG4l FHD/AKCguGXH7GtZKpQfFct6vQUOnJuUB7kCDQRE8SygEAgAlOYMwiFKPALEpi/X Cb3kTzpDqi9yvlijssnyxY2IxTYJHheE2dkITtdmgFlfud0lCLiSVhf8i9Y2YCar I+Djz7/LTlX4lhcDBeAaSHfDUtr5jTn3caK5A3inCAxoI7Um9Sy3fSyW9DMww2Mj t+ysQ2XuXpRZ984/3X79kNttae7L3FqASHjfflUFhBukxpSAn5evmkAnmZDhjy5a Z9Ut+DGDQOG2qvDTZM/RFDyodLIRoW9AK2O3A7CtVjZVOTSjDdhdOsHzsuBioh51 ngfUo4B3hDy+tv5qtzD5UjVj8g+oFqDpjo7mj7EwhD/AqHxg6yKqOtVLTmeEdZzW RMMGkwADBQgAjutKcj73K0GqhlKP3D3plXXBLOeAnoUBMoxbd7u7HigTXkTeq7gX c+zC6pu3atL1piRBOTYPiflf36hkph+EC9Zu7fBmaIdKRqltV9m+XB5l6Kw/C4go hTeLFI5A61GmiyQ5NPRpaeERGba+EoWswYIUxkCmr7I02DL8R72oLu6bb+bevCz5 d1AKrY2Vg3M8IXhGHPrYoFup6EYC6Thp2wRG4vBtpQStFbdYjXNBYmwWNERPzOzb k3pU8y96X7mqLHbv6gi5wapJyPidasc3VtU7RrwSEsYDoc2nf+6KzZMTT3rnB9RL gns2mcXM/4utmBWzSL7tnil5mlI9dynHQYhJBBgRAgAJBQJE8SygAhsMAAoJEJX0 LL+xQYafclwAnAmrmJpITi7ngFNR/obx/l6tNPRqAJ477VYqaBg58lc+TlGK1DoA HeMrow== =GJrg - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) iD8DBQFFAdDClfQsv7FBhp8RAosrAJ9ap7lveBcfvT7357QpIciU6Jb1WACeNCZX U9CGHhehPmVYbbn23duKq4k= =pbcm -----END PGP SIGNATURE----- _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
