15556667777 On Thu, Oct 20, 2011 at 8:50 AM, Kumaran T <[email protected]> wrote: > > Thanks for testing Tony,One last thing can you please check in user portal > of UserZ "From" field in VM Tab either its display as "+15556667777" or > "15556667777" > > Regards, > Kumaran T > > On 10/20/2011 6:08 PM, Tony Graziano wrote: >> >> After waiting for two days for bandwidth.com to re-provision the test >> number, I gave up on them. I was able to test as follows: >> >> System 1: UserA has outbound callerid manually defined as +15556667777 >> System 2: UserZ has voicemail >> >> UserA calls UserZ via ITSP, sends callerid +15556667777. UserZ does >> not pickup the call and it goes to sipx voicemail. UserZ calls and >> checks voicemail. Listens to message and hots "1" for more >> information, hears "from outside caller". >> >> sipx version 4.4 dated October 12 build date. >> >> On Tue, Oct 18, 2011 at 9:58 AM, Tony Graziano >> <[email protected]> wrote: >>> >>> I will try to test later today. >>> >>> On Tue, Oct 18, 2011 at 9:44 AM, Kumaran >>> T<[email protected]> >>> wrote: >>>> >>>> Hi Tony, >>>> Did you had time or ITSP configuration(which sends with +) to check >>>> this issue.Please let me know the update.. >>>> >>>> Regards, >>>> Kumaran T >>>> >>>> On 10/17/2011 6:49 PM, Kumaran T wrote: >>>> >>>> Tony,Can you please check by depositing VM from outside caller through >>>> ITSP which sends with "+" - "digit"(If you have any other ITSP).And let >>>> me >>>> know whether in user portal from number is reflected with "+" or without >>>> "+".. >>>> >>>> Regards, >>>> Kumaran T >>>> >>>> On 10/17/2011 6:04 PM, Tony Graziano wrote: >>>> >>>> yes. they send xxxyyyzzzz (10 digits) and expect you to send them >>>> 1xxxyyyzzzz (11 digits). >>>> >>>> On Oct 17, 2011 8:32 AM, "Kumaran T"<[email protected]> >>>> wrote: >>>>> >>>>> Hi Tony, >>>>> Am I right whether VOIP.MS is not expecting and sending in e.164 >>>>> format? >>>>> >>>>> Regards, >>>>> Kumaran T >>>>> >>>>> >>>>> On 10/17/2011 11:41 AM, Kumaran T wrote: >>>>> >>>>> Hi Tony, >>>>> I apologize,its a mistake from my end. VOIP.MS is not expecting and >>>>> sending in e.164 format.I just the call flow of it.It will just send >>>>> ISD >>>>> code(91)and followed by number without the leading + >>>>> >>>>> >>>>> "2011-10-17T06:00:11.136144Z:44203:INCOMING:INFO:sipx-test.ttplservices.com:SipClientTcp-116:b6076b90:SipXProxy:Read >>>>> SIP message: >>>>> ----Local Host:176.25.3.201---- Port: 5060---- >>>>> ----Remote Host:176.25.3.201---- Port: 36139---- >>>>> INVITE sip:[email protected] SIP/2.0 >>>>> Call-ID: [email protected] >>>>> CSeq: 102 INVITE >>>>> From: \"919342506214\"<sip:[email protected]>;tag=1016627570 >>>>> To:<sip:[email protected]> >>>>> Via: SIP/2.0/TCP >>>>> >>>>> 176.25.3.201:5090;branch=z9hG4bKd98e4e1f29463db591aabf238e73d752323732;sipxecs-id=20482b0b >>>>> Max-Forwards: 69 >>>>> User-Agent: sipXecs/xxxx.yyyy sipXecs/sipxbridge (Linux) >>>>> References: >>>>> >>>>> [email protected];rel=chain;sipxecs-tag=request-invite-z9hg4bk24b2eceb >>>>> Contact:<sip:[email protected]:5090> >>>>> Content-Type: application/sdp >>>>> Allow: INVITE,BYE,ACK,CANCEL,REFER,OPTIONS,PRACK >>>>> Supported: replaces,100rel >>>>> Content-Length: 255" >>>>> >>>>> Regards, >>>>> Kumaran T >>>>> >>>>> >>>>> >>>>> On 10/14/2011 9:37 PM, Tony Graziano wrote: >>>>> >>>>> I think this is a >>>>> Kumaran question. In his use case it was a click-to-call use case. In >>>>> all >>>>> cases it should still pass the full callerid. >>>>> If the + is not being handled by the click to call portal, that's more >>>>> likely a click-to-call issue, but I thought that had been fixed a long >>>>> time >>>>> ago. >>>>> On Fri, Oct 14, 2011 at 11:58 AM, Douglas Hubler<[email protected]> >>>>> wrote: >>>>>> >>>>>> On Fri, Oct 14, 2011 at 8:19 AM, Tony Graziano >>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> I am going to suggest that: >>>>>>> http://track.sipfoundry.org/browse/XX-5120 >>>>>>> Should be rolled back. If the callerid is +(whatever), it's a valid >>>>>>> e.164 >>>>>>> format and should be dial-able. It should not be removed. It is >>>>>>> correct the >>>>>>> caller is an outside caller. I think the JIRA case needs to be >>>>>>> revisitied. >>>>>> >>>>>> That issue was supposed to ignore chars only when reading back number >>>>>> to user. Can you prove otherwise? >>>> >>> >>> >>> -- >>> ====================== >>> Tony Graziano, Manager >>> Telephone: 434.984.8430 >>> sip: [email protected] >>> Fax: 434.465.6833 >>> >>> Email: [email protected] >>> >>> LAN/Telephony/Security and Control Systems Helpdesk: >>> Telephone: 434.984.8426 >>> sip: [email protected] >>> >>> Helpdesk Contract Customers: >>> http://support.myitdepartment.net >>> Blog: >>> http://blog.myitdepartment.net >>> >>> Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >>> Ask about our Internet Fax services! >>> >> >> > >
-- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.465.6833 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Contract Customers: http://support.myitdepartment.net Blog: http://blog.myitdepartment.net Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet Fax services! _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
