[cisco-voip] SIP trunk dropping calls

[Mark Holloway]

Prior to Broadworks Release 14, Service Pack 9, Broadworks required the From number in the SIP invite towards the ITSP to contain one of the DID's that is assigned to the Trunk Group.  The bad thing about this (just one example) is PSTN calls toward the IP PBX, call-forward back to the PSTN to someone's cell phone, but the cell phone will have to display caller-id of the desk phone doing the forwarding, not the originating PSTN caller's number.  There are several scenarios where this became a severe limitation but as of R14.SP9 this is no longer a problem.

On Dec 7, 2009, at 10:28 PM, Jason Aarons (US) wrote:

> To clarify if VZB's SIP Trunk doesn't show a calling party number (or external mask) that matches a billing telephone number (BTN), the packets are just discarded...which can make troubleshooting and sending the call to next device in Route Group difficult..
> 
> -----Original Message-----
> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of ccieid1ot
> Sent: Monday, December 07, 2009 5:06 PM
> To: Mark Holloway
> Cc: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] SIP trunk dropping calls
> 
> I work for VZB that supports customers with IP Trunking.  We have
> customers that gets their calls dropped without the correct ANI.
> 
> On Mon, Dec 7, 2009 at 3:51 PM, Mark Holloway <mh at markholloway.com> wrote:
>> They use Broadworks too.
>> 
>> On Dec 7, 2009, at 2:25 PM, ccieid1ot wrote:
>> 
>>> I'm speaking on Verizon's IP trunk.
>>> 
>>> On Mon, Dec 7, 2009 at 3:22 PM, Mark Holloway <mh at markholloway.com> wrote:
>>>> Not all providers reject calls with no From number on the SIP trunk.  We use Broadworks and for customers who want to send anything other than one of their DID's we enable Unscreened Calling.  It requires a Trunk Group Identifier to be set in Broadworks and CUBE must be used to inject the TGI into the registration and invite messages.
>>>> 
>>>> 
>>>> On Dec 7, 2009, at 12:24 PM, ccieid1ot wrote:
>>>> 
>>>>> I do know that the SIP provider will drop the call if there's no ANI.
>>>>> 
>>>>> On Fri, Dec 4, 2009 at 6:22 PM, Nick Matthews <matthnick at gmail.com> wrote:
>>>>>> As well - csim is not a great testing tool for VOIP protocols.  I
>>>>>> would not depend on it.
>>>>>> 
>>>>>> -nick
>>>>>> 
>>>>>> On Fri, Dec 4, 2009 at 7:21 PM, Nick Matthews <matthnick at gmail.com> wrote:
>>>>>>> You need to explain the call flow more.  All I see here is that you
>>>>>>> have two cisco gateways, one makes a call, gets ringback, does media
>>>>>>> negotiation, and then hangs up 20 seconds after the ringback comes in.
>>>>>>>  Why does the user not answer within 20 seconds?  What's on the other
>>>>>>> sides of both of these sip connections?
>>>>>>> 
>>>>>>> 
>>>>>>> -nick
>>>>>>> 
>>>>>>> On Fri, Dec 4, 2009 at 5:45 PM, Ali El Moussaoui <mousawi.ali at gmail.com> wrote:
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> We installed an IPIP gateway and am trying one of the SIP legs using CSIM
>>>>>>>> but i am not able to figure out why calls are failing although all sip
>>>>>>>> messages seems correct.
>>>>>>>> 
>>>>>>>> The full trace is attacehd i appreciate any help.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Ali
>>>>>>>> _______________________________________________
>>>>>>>> cisco-voip mailing list
>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> _______________________________________________
>>>>>> cisco-voip mailing list
>>>>>> cisco-voip at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>> 
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>> 
>>>> 
>> 
>> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
> -----------------------------------------
> Disclaimer:
> 
> This e-mail communication and any attachments may contain
> confidential and privileged information and is for use by the
> designated addressee(s) named above only.  If you are not the
> intended addressee, you are hereby notified that you have received
> this communication in error and that any use or reproduction of
> this email or its contents is strictly prohibited and may be
> unlawful.  If you have received this communication in error, please
> notify us immediately by replying to this message and deleting it
> from your computer. Thank you.