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/
