Thank you, Paul, I have 2 tickets open - one with our carrier and one with the destination carrier. Our carrier confirmed that they don't change anything. Waiting for a reply from the destination carrier.
The extra "P-Asserted-Identity" header is inserted in the network and I assume the NE inserting it is the culprit. >From P-Asserted-Identity: <sip:+14153436545@8.13.234.114:5060> I determined >that : - the inserted number owned by MCI (not our carrier, not the destination carrier) - the inserted IP is owned by the destination carrier. I'm with you and it's frustrating. Unfortunately I cannot count on the kindness of carriers, there must be something I can do to guarantee my unique ID delivery. A.C. -----Original Message----- From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu] Sent: Wednesday, January 29, 2014 1:57 PM To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Sending proprietary information in SIP INVITE Adelia, The problem is that carriers and other intermediaries have decided that they are free to change anything they want in sip signaling, regardless of SIP spec rules that they not do so. So you will have to take it up with them. It appears to me that the general attitude is: we will allow what we must to make the specific features we care about work - breaking any usage we don't explicitly embrace is a feature rather than a bug. Thanks, Paul On 1/29/14 4:48 PM, Adelia Chetreanu wrote: > I need to send a 10 digit unique ID over the network. > I've been doing it for years by replacing the INVITE FROM header with the 10 > digit value. > Looks like a phone number. > > Lately, I'm facing an on/off problem, the ANI gets replaced with Anonymous > every 70-80 calls or so. Randomly, no pattern. > I believe it to be related to a particular carrier we traverse and I have no > control over it. > It breaks one of our major features. > > This is an example: > > Sending: > INVITE sip:1415xxxyyy@10.10.10.10:5060 SIP/2.0 > Via: SIP/2.0/UDP > 10.10.10.2:5060;received=10.10.10.2;branch=z9hG4bK-d87543-603a7a3e7269 > fb4d-1--d87543-;rport=5060 > Max-Forwards: 69 > Contact: <sip:5180943774@10.10.10.2:5060;transport=udp> > To: <sip:1415xxxyyyy@10.10.10.1:5060;transport=udp> > From: > <sip:5180943774@10.10.10.2:5060;transport=udp;isup-oli=00>;tag=2b5d315 > 7 > Call-ID: MzQ3NzFjNGQ1NjY1MDBmNjMxMDAyOTA0NWVhNjVmNzc. > CSeq: 1 INVITE > Content-Type: application/sdp > Content-Length: 186 > > Receiving: > > > > > Request URI: sip:+1415xxxyyyy@66.66.66.66:5060 > From: "Anonymous" > <sip:Anonymous@Anonymous.invalid;isup-oli=0>;tag=gK0a240fff > To: <sip:+1415xxxyyy@64.213.98.152:5060> > Call-ID: > 218763914_18988818@8.13.234.114<mailto:218763914_18988818@8.13.234.114 > > > CSeq: 20798 INVITE > Contact: "Anonymous" <sip:Anonymous@8.13.234.114:5060> > P-Asserted-Identity: <sip:+14153436545@8.13.234.114:5060> > > > We extract 4153436545 instead of 5180943774 on the called party side, and our > feature bombs. > > While I follow up with our carrier, what other options do I have? > What could I use (header or parameter) to send my private info transparently > through the network? > Must be in INVITE. > > I have found post "Private Header" from 2009, that suggests: > - private header, add your own > - MIME data > - userinfo parameter in Request URI > > Each one has its challenges for my app - do I have other options? > Thank you! > A.C. > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
