Broadworks: Preserve sip call-ID
Hi guys, We are running r17 at the moment and currently testing a monitoring platform for both signalling and media. They use sip callID to identify call legs to merge and i would like to have all call legs on one call (from the originating access side to where we send the traffic to for PSTN). Since Broadworks act as a B2BUA it rewrites the originating callID to BW-xxxxx. I've made changes on the SBC to preserve the callID but now need Broadworks to preserve it. Is it possible on Broadworks to transparent proxy the callID from the access side to the terminating side ? Thanks Rakesh
Never had to try, but I've never seen anything in BW that is even close to this. I know that you can't get them to take the "BW" out of the call-ID (sigh....). You're asking for something that is pretty brittle. If you ever fork, you can't preserve the inbound call-ID on the multiple outbound legs, because call-IDs must be globally unique (RFC3261:8.1.1.4). David From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Rakesh Unni Sent: Thursday, March 15, 2012 08:47 To: VoiceOps at voiceops.org Subject: [VoiceOps] Broadworks: Preserve sip call-ID Hi guys, We are running r17 at the moment and currently testing a monitoring platform for both signalling and media. They use sip callID to identify call legs to merge and i would like to have all call legs on one call (from the originating access side to where we send the traffic to for PSTN). Since Broadworks act as a B2BUA it rewrites the originating callID to BW-xxxxx. I've made changes on the SBC to preserve the callID but now need Broadworks to preserve it. Is it possible on Broadworks to transparent proxy the callID from the access side to the terminating side ? Thanks Rakesh This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
It's Palladion we are trying. Not sure why they worry about call-ID manipulation, guess it has some reference to the licensing validation for transactions. Thanks Rakesh On 15 March 2012 16:19, Hiers, David <David.Hiers at adp.com> wrote:
Never had to try, but I've never seen anything in BW that is even close to this. I know that you can't get them to take the "BW" out of the call-ID (sigh....). ****
** **
You're asking for something that is pretty brittle. If you ever fork, you can't preserve the inbound call-ID on the multiple outbound legs, because call-IDs must be globally unique (RFC3261:8.1.1.4).****
** **
** **
** **
David****
** **
** **
*From:* voiceops-bounces at voiceops.org [mailto: voiceops-bounces at voiceops.org] *On Behalf Of *Rakesh Unni *Sent:* Thursday, March 15, 2012 08:47
*To:* VoiceOps at voiceops.org *Subject:* [VoiceOps] Broadworks: Preserve sip call-ID****
** **
Hi guys,****
We are running r17 at the moment and currently testing a monitoring platform for both signalling and media. They use sip callID to identify call legs to merge and i would like to have all call legs on one call (from the originating access side to where we send the traffic to for PSTN). Since Broadworks act as a B2BUA it rewrites the originating callID to BW-xxxxx. I've made changes on the SBC to preserve the callID but now need Broadworks to preserve it. ****
Is it possible on Broadworks to transparent proxy the callID from the access side to the terminating side ? ****
Thanks Rakesh ****
------------------------------ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
-- Rakesh +44 2033931856 sip:unni at getonsip.com
Palladion has options other than Call-ID that will allow correlation of call legs including SDP. On Mar 15, 2012, at 12:42 PM, Rakesh Unni wrote: It's Palladion we are trying. Not sure why they worry about call-ID manipulation, guess it has some reference to the licensing validation for transactions. Thanks Rakesh On 15 March 2012 16:19, Hiers, David <David.Hiers at adp.com<mailto:David.Hiers at adp.com>> wrote: Never had to try, but I've never seen anything in BW that is even close to this. I know that you can't get them to take the "BW" out of the call-ID (sigh....). You're asking for something that is pretty brittle. If you ever fork, you can't preserve the inbound call-ID on the multiple outbound legs, because call-IDs must be globally unique (RFC3261:8.1.1.4). David From: voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org> [mailto:voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>] On Behalf Of Rakesh Unni Sent: Thursday, March 15, 2012 08:47 To: VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> Subject: [VoiceOps] Broadworks: Preserve sip call-ID Hi guys, We are running r17 at the moment and currently testing a monitoring platform for both signalling and media. They use sip callID to identify call legs to merge and i would like to have all call legs on one call (from the originating access side to where we send the traffic to for PSTN). Since Broadworks act as a B2BUA it rewrites the originating callID to BW-xxxxx. I've made changes on the SBC to preserve the callID but now need Broadworks to preserve it. Is it possible on Broadworks to transparent proxy the callID from the access side to the terminating side ? Thanks Rakesh ________________________________ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- Rakesh +44 2033931856 sip:unni at getonsip.com<mailto:sip%3Aunni at getonsip.com>
Any tips on the setup mate? Much appreciated, Rakesh Sent from my iPad On 15 Mar 2012, at 16:53, Michael Lunsford <Michael.Lunsford at cbeyond.net> wrote:
Palladion has options other than Call-ID that will allow correlation of call legs including SDP.
On Mar 15, 2012, at 12:42 PM, Rakesh Unni wrote:
It's Palladion we are trying. Not sure why they worry about call-ID manipulation, guess it has some reference to the licensing validation for transactions.
Thanks Rakesh
On 15 March 2012 16:19, Hiers, David <David.Hiers at adp.com<mailto:David.Hiers at adp.com>> wrote: Never had to try, but I've never seen anything in BW that is even close to this. I know that you can't get them to take the "BW" out of the call-ID (sigh....).
You're asking for something that is pretty brittle. If you ever fork, you can't preserve the inbound call-ID on the multiple outbound legs, because call-IDs must be globally unique (RFC3261:8.1.1.4).
David
From: voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org> [mailto:voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>] On Behalf Of Rakesh Unni Sent: Thursday, March 15, 2012 08:47
To: VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> Subject: [VoiceOps] Broadworks: Preserve sip call-ID
Hi guys,
We are running r17 at the moment and currently testing a monitoring platform for both signalling and media. They use sip callID to identify call legs to merge and i would like to have all call legs on one call (from the originating access side to where we send the traffic to for PSTN). Since Broadworks act as a B2BUA it rewrites the originating callID to BW-xxxxx. I've made changes on the SBC to preserve the callID but now need Broadworks to preserve it.
Is it possible on Broadworks to transparent proxy the callID from the access side to the terminating side ?
Thanks Rakesh
________________________________ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
-- Rakesh
+44 2033931856 sip:unni at getonsip.com<mailto:sip%3Aunni at getonsip.com>
Unfortunately, I don't have my fingers on one any longer. Have you requested vendor support? On Mar 15, 2012, at 2:35 PM, Rakesh Unni wrote: Any tips on the setup mate? Much appreciated, Rakesh Sent from my iPad On 15 Mar 2012, at 16:53, Michael Lunsford <Michael.Lunsford at cbeyond.net> wrote:
Palladion has options other than Call-ID that will allow correlation of call legs including SDP.
On Mar 15, 2012, at 12:42 PM, Rakesh Unni wrote:
It's Palladion we are trying. Not sure why they worry about call-ID manipulation, guess it has some reference to the licensing validation for transactions.
Thanks Rakesh
On 15 March 2012 16:19, Hiers, David <David.Hiers at adp.com<mailto:David.Hiers at adp.com>> wrote: Never had to try, but I've never seen anything in BW that is even close to this. I know that you can't get them to take the "BW" out of the call-ID (sigh....).
You're asking for something that is pretty brittle. If you ever fork, you can't preserve the inbound call-ID on the multiple outbound legs, because call-IDs must be globally unique (RFC3261:8.1.1.4).
David
From: voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org> [mailto:voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>] On Behalf Of Rakesh Unni Sent: Thursday, March 15, 2012 08:47
To: VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> Subject: [VoiceOps] Broadworks: Preserve sip call-ID
Hi guys,
We are running r17 at the moment and currently testing a monitoring platform for both signalling and media. They use sip callID to identify call legs to merge and i would like to have all call legs on one call (from the originating access side to where we send the traffic to for PSTN). Since Broadworks act as a B2BUA it rewrites the originating callID to BW-xxxxx. I've made changes on the SBC to preserve the callID but now need Broadworks to preserve it.
Is it possible on Broadworks to transparent proxy the callID from the access side to the terminating side ?
Thanks Rakesh
________________________________ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
-- Rakesh
+44 2033931856 sip:unni at getonsip.com<mailto:sip%3Aunni at getonsip.com>
I'm matching by multiple headers (to, from, pai, others) and these are nested within a specific block of time. It's basically a few modifications from the default call merging algorithm. I can't show my exact modifications, but that should lead you in the proper path. This works OK other than in one scenario. Imagine that 4801001234 at domain1 makes a call. Within this set time window 1234 at domain2 initiates a call as well. Even though I am set to match on the last 6 characters of the caller/callee, Palladion is merging the calls from 1234 at domain2 and 4801001234 at domain1. I'm still working with IPTEGO to get a few of these bugs worked out. If I knew how to (((write code in LISP)) it would be much easier accomplish.) Keith On Thu, Mar 15, 2012 at 11:56 AM, Michael Lunsford < Michael.Lunsford at cbeyond.net> wrote:
Unfortunately, I don't have my fingers on one any longer. Have you requested vendor support?
On Mar 15, 2012, at 2:35 PM, Rakesh Unni wrote:
Any tips on the setup mate?
Much appreciated, Rakesh
Sent from my iPad
On 15 Mar 2012, at 16:53, Michael Lunsford <Michael.Lunsford at cbeyond.net> wrote:
Palladion has options other than Call-ID that will allow correlation of call legs including SDP.
On Mar 15, 2012, at 12:42 PM, Rakesh Unni wrote:
It's Palladion we are trying. Not sure why they worry about call-ID manipulation, guess it has some reference to the licensing validation for transactions.
Thanks Rakesh
On 15 March 2012 16:19, Hiers, David <David.Hiers at adp.com<mailto: David.Hiers at adp.com>> wrote: Never had to try, but I've never seen anything in BW that is even close to this. I know that you can't get them to take the "BW" out of the call-ID (sigh....).
You're asking for something that is pretty brittle. If you ever fork, you can't preserve the inbound call-ID on the multiple outbound legs, because call-IDs must be globally unique (RFC3261:8.1.1.4).
David
From: voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org> [mailto:voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>] On Behalf Of Rakesh Unni Sent: Thursday, March 15, 2012 08:47
To: VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> Subject: [VoiceOps] Broadworks: Preserve sip call-ID
Hi guys,
We are running r17 at the moment and currently testing a monitoring platform for both signalling and media. They use sip callID to identify call legs to merge and i would like to have all call legs on one call (from the originating access side to where we send the traffic to for PSTN). Since Broadworks act as a B2BUA it rewrites the originating callID to BW-xxxxx. I've made changes on the SBC to preserve the callID but now need Broadworks to preserve it.
Is it possible on Broadworks to transparent proxy the callID from the access side to the terminating side ?
Thanks Rakesh
________________________________ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
-- Rakesh
+44 2033931856 sip:unni at getonsip.com<mailto:sip%3Aunni at getonsip.com>
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
They've been trying to push through a Session-id spec in the SIP Dispatch IETF working group for some time. This is a globally unique identifier that is carried across B2BUA's unmolested. Seems to always fade away, but if it were actually ever passed as an RFC, you could go to your vendor and ask them to implement it with some level of confidence they'd actually do it in a way that's compatible with all the other vendors. The last attempt was http://tools.ietf.org/html/draft-kaplan-sip-session-id-03, expired March 2011. Some talk lately in the IETF of reviving it or a slight permutation, though nothing specific that I'm aware of. Howard Hart On 03/15/2012 01:20 PM, Keith Croxford wrote:
I'm matching by multiple headers (to, from, pai, others) and these are nested within a specific block of time. It's basically a few modifications from the default call merging algorithm. I can't show my exact modifications, but that should lead you in the proper path.
This works OK other than in one scenario.
Imagine that 4801001234 at domain1 makes a call. Within this set time window 1234 at domain2 initiates a call as well. Even though I am set to match on the last 6 characters of the caller/callee, Palladion is merging the calls from 1234 at domain2 and 4801001234 at domain1.
I'm still working with IPTEGO to get a few of these bugs worked out. If I knew how to (((write code in LISP)) it would be much easier accomplish.)
Keith
On Thu, Mar 15, 2012 at 11:56 AM, Michael Lunsford <Michael.Lunsford at cbeyond.net <mailto:Michael.Lunsford at cbeyond.net>> wrote:
Unfortunately, I don't have my fingers on one any longer. Have you requested vendor support?
On Mar 15, 2012, at 2:35 PM, Rakesh Unni wrote:
Any tips on the setup mate?
Much appreciated, Rakesh
Sent from my iPad
On 15 Mar 2012, at 16:53, Michael Lunsford <Michael.Lunsford at cbeyond.net <mailto:Michael.Lunsford at cbeyond.net>> wrote:
> Palladion has options other than Call-ID that will allow correlation of call legs including SDP. > > > On Mar 15, 2012, at 12:42 PM, Rakesh Unni wrote: > > It's Palladion we are trying. Not sure why they worry about call-ID manipulation, guess it has some reference to the licensing validation for transactions. > > Thanks > Rakesh > > On 15 March 2012 16:19, Hiers, David <David.Hiers at adp.com <mailto:David.Hiers at adp.com><mailto:David.Hiers at adp.com <mailto:David.Hiers at adp.com>>> wrote: > Never had to try, but I've never seen anything in BW that is even close to this. I know that you can't get them to take the "BW" out of the call-ID (sigh....). > > You're asking for something that is pretty brittle. If you ever fork, you can't preserve the inbound call-ID on the multiple outbound legs, because call-IDs must be globally unique (RFC3261:8.1.1.4). > > > > David > > > From: voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org><mailto:voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org>> [mailto:voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org><mailto:voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org>>] On Behalf Of Rakesh Unni > Sent: Thursday, March 15, 2012 08:47 > > To: VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org><mailto:VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org>> > Subject: [VoiceOps] Broadworks: Preserve sip call-ID > > > > Hi guys, > > We are running r17 at the moment and currently testing a monitoring platform for both signalling and media. They use sip callID to identify call legs to merge and i would like to have all call legs on one call (from the originating access side to where we send the traffic to for PSTN). Since Broadworks act as a B2BUA it rewrites the originating callID to BW-xxxxx. I've made changes on the SBC to preserve the callID but now need Broadworks to preserve it. > > Is it possible on Broadworks to transparent proxy the callID from the access side to the terminating side ? > > Thanks > Rakesh > > ________________________________ > This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. > > > > > -- > Rakesh > > +44 2033931856 <tel:%2B44%202033931856> > sip:unni at getonsip.com <mailto:sip%3Aunni at getonsip.com><mailto:sip%3Aunni at getonsip.com <mailto:sip%253Aunni at getonsip.com>> > > >
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
There's good news on that front - We've finally got a new IETF Working Group created for just that purpose: the "INtermediary-safe SIP session ID" Working Group, a.k.a. INSIPID. It's first meeting is in just a few days: this Monday, March 26th, at the IETF meeting. The meeting's in France, but the IETF has free remote participation - you can listen to the audio broadcast and be in a jabber chat room for the working group meeting. And if you want to say something at the microphone, you just type what you want said into the jabber room and someone will say it for you in the physical room. All of that you can do remotely for free, without having to register, be a member, or sign up for anything. The current agenda is here: http://www.ietf.org/proceedings/83/agenda/agenda-83-insipid.txt The meeting's only an hour long, at 9:10-10:10am Eastern Daylight Time US. To join the audio and jabber session, go to the following page, search for "insipid", and click the little speaker icon for an audio stream, and the jabber lightbulb icon for a jabber URL. http://tools.ietf.org/agenda/83/ Note you do need a jabber client to use that, but you can get them for free on all platforms; go to http://www.ietf.org/jabber/ for info on that. I urge anyone who cares about the issue to please join the meeting. The more feedback we get, positive or negative, the faster we'll get somewhere. (well, I suppose if you say the whole idea is useless, then we won't get anywhere real fast :) Also, there's a new Working Group mailing list you can join, where the real action happens, here: https://www.ietf.org/mailman/listinfo/insipid Again, it's open to anyone who wants to join it. -hadriel On Mar 17, 2012, at 9:23 PM, Howard Hart wrote: They've been trying to push through a Session-id spec in the SIP Dispatch IETF working group for some time. This is a globally unique identifier that is carried across B2BUA's unmolested. Seems to always fade away, but if it were actually ever passed as an RFC, you could go to your vendor and ask them to implement it with some level of confidence they'd actually do it in a way that's compatible with all the other vendors. The last attempt was http://tools.ietf.org/html/draft-kaplan-sip-session-id-03, expired March 2011. Some talk lately in the IETF of reviving it or a slight permutation, though nothing specific that I'm aware of. Howard Hart On 03/15/2012 01:20 PM, Keith Croxford wrote: I'm matching by multiple headers (to, from, pai, others) and these are nested within a specific block of time. It's basically a few modifications from the default call merging algorithm. I can't show my exact modifications, but that should lead you in the proper path. This works OK other than in one scenario. Imagine that 4801001234 at domain1 makes a call. Within this set time window 1234 at domain2 initiates a call as well. Even though I am set to match on the last 6 characters of the caller/callee, Palladion is merging the calls from 1234 at domain2 and 4801001234 at domain1. I'm still working with IPTEGO to get a few of these bugs worked out. If I knew how to (((write code in LISP)) it would be much easier accomplish.) Keith
The caller ID, LRN, and called number are used to determine the CABS billing (minutes of use) in the PSTN world so that's why they don't want you to drop callerID. Many VOIP carriers were dropping callerID or spoofing it so they could push it down a local trunk group and claim they didn't have to pay anything for it (because local is free). The recent FCC ruling on ICC reform stated that all carriers (including VOIP) are responsible for paying for their intra and interLATA traffic and must pass the correct information along so the traffic is classified and billed correctly. Mary Lou Carey BackUP Telecom Consulting CLEC Consultant OFF: 615-791-9969 From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Rakesh Unni Sent: Thursday, March 15, 2012 11:43 AM To: Hiers, David Cc: VoiceOps at voiceops.org Subject: Re: [VoiceOps] Broadworks: Preserve sip call-ID It's Palladion we are trying. Not sure why they worry about call-ID manipulation, guess it has some reference to the licensing validation for transactions. Thanks Rakesh On 15 March 2012 16:19, Hiers, David <David.Hiers at adp.com> wrote: Never had to try, but I've never seen anything in BW that is even close to this. I know that you can't get them to take the "BW" out of the call-ID (sigh....). You're asking for something that is pretty brittle. If you ever fork, you can't preserve the inbound call-ID on the multiple outbound legs, because call-IDs must be globally unique (RFC3261:8.1.1.4). David From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Rakesh Unni Sent: Thursday, March 15, 2012 08:47 To: VoiceOps at voiceops.org Subject: [VoiceOps] Broadworks: Preserve sip call-ID Hi guys, We are running r17 at the moment and currently testing a monitoring platform for both signalling and media. They use sip callID to identify call legs to merge and i would like to have all call legs on one call (from the originating access side to where we send the traffic to for PSTN). Since Broadworks act as a B2BUA it rewrites the originating callID to BW-xxxxx. I've made changes on the SBC to preserve the callID but now need Broadworks to preserve it. Is it possible on Broadworks to transparent proxy the callID from the access side to the terminating side ? Thanks Rakesh _____ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- Rakesh +44 2033931856 sip:unni at getonsip.com <mailto:sip%3Aunni at getonsip.com>
The carriers we use expect Remote-Party-ID or P-Asserted-ID, and Diversion headers for billing. -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Mary Lou Carey Sent: Thursday, March 15, 2012 1:35 PM To: 'Rakesh Unni'; 'Hiers, David' Cc: VoiceOps at voiceops.org Subject: Re: [VoiceOps] Broadworks: Preserve sip call-ID The caller ID, LRN, and called number are used to determine the CABS billing (minutes of use) in the PSTN world so that's why they don't want you to drop callerID. Many VOIP carriers were dropping callerID or spoofing it so they could push it down a local trunk group and claim they didn't have to pay anything for it (because local is free). The recent FCC ruling on ICC reform stated that all carriers (including VOIP) are responsible for paying for their intra and interLATA traffic and must pass the correct information along so the traffic is classified and billed correctly. Mary Lou Carey BackUP Telecom Consulting CLEC Consultant OFF: 615-791-9969 From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Rakesh Unni Sent: Thursday, March 15, 2012 11:43 AM To: Hiers, David Cc: VoiceOps at voiceops.org Subject: Re: [VoiceOps] Broadworks: Preserve sip call-ID It's Palladion we are trying. Not sure why they worry about call-ID manipulation, guess it has some reference to the licensing validation for transactions. Thanks Rakesh On 15 March 2012 16:19, Hiers, David <David.Hiers at adp.com> wrote: Never had to try, but I've never seen anything in BW that is even close to this. I know that you can't get them to take the "BW" out of the call-ID (sigh....). You're asking for something that is pretty brittle. If you ever fork, you can't preserve the inbound call-ID on the multiple outbound legs, because call-IDs must be globally unique (RFC3261:8.1.1.4). David From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Rakesh Unni Sent: Thursday, March 15, 2012 08:47 To: VoiceOps at voiceops.org Subject: [VoiceOps] Broadworks: Preserve sip call-ID Hi guys, We are running r17 at the moment and currently testing a monitoring platform for both signalling and media. They use sip callID to identify call legs to merge and i would like to have all call legs on one call (from the originating access side to where we send the traffic to for PSTN). Since Broadworks act as a B2BUA it rewrites the originating callID to BW-xxxxx. I've made changes on the SBC to preserve the callID but now need Broadworks to preserve it. Is it possible on Broadworks to transparent proxy the callID from the access side to the terminating side ? Thanks Rakesh ________________________________ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- Rakesh +44 2033931856 sip:unni at getonsip.com <mailto:sip%3Aunni at getonsip.com>
On 3/15/12 10:34 AM, Mary Lou Carey wrote:
The caller ID, LRN, and called number are used to determine the CABS billing (minutes of use) in the PSTN world so that's why they don't want you to drop callerID. Many VOIP carriers were dropping callerID or spoofing it so they could push it down a local trunk group and claim they didn't have to pay anything for it (because local is free). The recent FCC ruling on ICC reform stated that all carriers (including VOIP) are responsible for paying for their intra and interLATA traffic and must pass the correct information along so the traffic is classified and billed correctly.
SIP call-ID != Caller-ID (CLID). And both != ANI. SIP call-ID is an random-ish alphanumeric string identifying a specific call. It is supposed to be different for every call and typically doesn't contain the calling or called number. Caller-ID (CLID) is a numeric string optionally passed to the receiving end user purporting to show the originating number. It is often manipulated, for example a PBX forwarding an inbound call out a trunk will often be configured to show the CLID of the inbound call as opposed to that of the PBX. ANI (Automatic Number Identification) is used for billing, and can be mapped to P-asserted-identity in the SIP world. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
CallID is different from CallerID. CallID identifies the Call. CallerID identifies the Caller. (very much simplified explanation). Regards, Marc From: Mary Lou Carey <marylou at backuptelecom.com<mailto:marylou at backuptelecom.com>> Date: Thu, 15 Mar 2012 12:34:45 -0500 To: 'Rakesh Unni' <rakeshunni at gmail.com<mailto:rakeshunni at gmail.com>>, "'Hiers, David'" <David.Hiers at adp.com<mailto:David.Hiers at adp.com>> Cc: <VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>> Subject: Re: [VoiceOps] Broadworks: Preserve sip call-ID The caller ID, LRN, and called number are used to determine the CABS billing (minutes of use) in the PSTN world so that's why they don't want you to drop callerID. Many VOIP carriers were dropping callerID or spoofing it so they could push it down a local trunk group and claim they didn't have to pay anything for it (because local is free). The recent FCC ruling on ICC reform stated that all carriers (including VOIP) are responsible for paying for their intra and interLATA traffic and must pass the correct information along so the traffic is classified and billed correctly. Mary Lou Carey BackUP Telecom Consulting CLEC Consultant OFF: 615-791-9969 From: voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org> [mailto:voiceops-bounces at voiceops.org] On Behalf Of Rakesh Unni Sent: Thursday, March 15, 2012 11:43 AM To: Hiers, David Cc: VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> Subject: Re: [VoiceOps] Broadworks: Preserve sip call-ID It's Palladion we are trying. Not sure why they worry about call-ID manipulation, guess it has some reference to the licensing validation for transactions. Thanks Rakesh On 15 March 2012 16:19, Hiers, David <David.Hiers at adp.com<mailto:David.Hiers at adp.com>> wrote: Never had to try, but I've never seen anything in BW that is even close to this. I know that you can't get them to take the "BW" out of the call-ID (sigh....). You're asking for something that is pretty brittle. If you ever fork, you can't preserve the inbound call-ID on the multiple outbound legs, because call-IDs must be globally unique (RFC3261:8.1.1.4). David From: voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org> [mailto:voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>] On Behalf Of Rakesh Unni Sent: Thursday, March 15, 2012 08:47 To: VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> Subject: [VoiceOps] Broadworks: Preserve sip call-ID Hi guys, We are running r17 at the moment and currently testing a monitoring platform for both signalling and media. They use sip callID to identify call legs to merge and i would like to have all call legs on one call (from the originating access side to where we send the traffic to for PSTN). Since Broadworks act as a B2BUA it rewrites the originating callID to BW-xxxxx. I've made changes on the SBC to preserve the callID but now need Broadworks to preserve it. Is it possible on Broadworks to transparent proxy the callID from the access side to the terminating side ? Thanks Rakesh ________________________________ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- Rakesh +44 2033931856 sip:unni at getonsip.com<mailto:sip%3Aunni at getonsip.com> _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
participants (10)
-
David.Hiers＠adp.com -
EWieling＠nyigc.com -
hch＠sipster.com -
HKaplan＠acmepacket.com -
jay＠west.net -
keith.croxford1＠gmail.com -
marylou＠backuptelecom.com -
Michael.Lunsford＠cbeyond.net -
mstorck＠voipgate.com -
rakeshunni＠gmail.com