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]
<mailto:[email protected]>> wrote:
Hi Tony,
Am I right whether VOIP.MS <http://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
<http://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]
<mailto:[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
<mailto:[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] <mailto:[email protected]>> wrote:
On Fri, Oct 14, 2011 at 8:19 AM, Tony Graziano
<[email protected]
<mailto:[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/
