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?
>>>>>>
>
>



-- 
======================
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/

Reply via email to