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/ >> > > > > _______________________________________________ > sipx-users mailing [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > >
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
