Thanks Tony for the update..I think Douglas would provide some insights regarding this.
Kumaran T On 10/20/2011 6:30 PM, Tony Graziano wrote: > Like I said, I think the thing to do is make sure the IVR knows "+" is > valid but to ignore it and be aware the call is from the outide. If > your ITSP sends you calls with "+", it's a valid format. The IVR > should say its an outside caller. The portal should show "+", so the > click to call function should be able to send it to the proxy > "unchanged" because the proxy/dial plan should be configured to accept > "+", whether it strips it on outbound calls or not, is up to your > dialplan and your outbound routing. I'm not really clear on what the > JIRA is about anymore though :>) > > On Thu, Oct 20, 2011 at 8:57 AM, Kumaran T > <[email protected]> wrote: >> So + is ignored by the server while depositing VM.Its a valid behavior? >> But incoming call will land with +(valid) >> >> Kumaran T >> >> On 10/20/2011 6:21 PM, Tony Graziano wrote: >>> 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? >> > > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
