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