Re: [OpenSIPStack] OpenSBC SIP Trunking - Null Sessionin CallSessionManager.cxx

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hello Joegen,

Thanks for your reply. I hope SIPIt 21 went well for you and Ilian.

Ref: Issue regarding incoming call

1) The TO URI is an IP Address rather than a domain
2) Port is 31265

Both these are specific to Gafachi's behavior though I believe 1) is
perfectly valid as per RFC 3261.

Anyway, we resolved the issue by commenting out the following check in
opensbc/SBCSIPTrunkEndPoint.cxx -OnCreateB2BUA()

//if( trunkReg == NULL ) 
//  return NULL;

Lines 99-100 commented out.

After making the above change, trunking works fine in case of incoming
calls. I'm not sure what impact this change will have on the rest of the
code. Comments?

Regarding the outgoing call issue, I'll try out your suggestion and let you
know if it works.

Regards,
Gaurav

> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...] On Behalf Of
> jo...@op...
> Sent: Monday, November 12, 2007 8:09 AM
> To: jo...@op...
> Cc: ope...@li...; joe...@gm...;
> din...@gm...; ope...@li...
> Subject: Re: [OpenSIPStack] OpenSBC SIP Trunking - Null Sessionin
> CallSessionManager.cxx
> 
> Hi Gaurav,
> 
> I just found out that you CC'ed my gmail account and the attachments
> made it.   For your inbound call, attached is the INVITE
> 
> INVITE sip:16462781042@192.168.96.115:5066;transport=udp SIP/2.0
> From: "unknown"
> <sip:416...@si...>;tag=gss4a7f914ce003e05a02fa166fc6c27f14
> To:  <sip:16462781042@59.95.152.178:31265>
> Via: SIP/2.0/UDP 64.192.112.13:5060;branch=z9hG4bKd21aa1af
> CSeq: 102 INVITE
> Call-ID: d82a729522b3f145f0798b363d25b6a1@64.192.112.13
> Contact: <sip:4169074204@64.192.112.13>
> Date: Tue, 06 Nov 2007 06:21:48 GMT
> User-Agent: Gafachi UAC v110.05
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
> Content-Type: application/sdp
> Content-Length: 240
> 
> 
> There are two things that are not in proper place in this INVITE from
> gafachi.   First, The to-uri host is an ip address and not a domain.
> This call will not be properly identified by the SBC as a trunk call.
> Another strange thing is that it has a port (31265) which definitely is
> not an OSBC listener port.   Can you give more information as to why
> gafachi will be sending this to-uri?
> 
> For your outbound call, indeed the call was not properly identified as a
> trunk call.... see my previous response.
> 
> 
> 
> jo...@op... wrote:
> > Hi Gaurav,
> >
> > I apologize for the late response.  We just arrived from SIPIT 21.
> > My  answers inline.
> >
> >
> > Gaurav Kheterpal wrote:
> >> Hello Joegen,
> >>
> >>
> >>
> >> I grabbed the latest source code from CVS and configured OpenSBC for
> SIP
> >> trunking. While it may not be prime time, it works quiet well except
> >> for a
> >> couple of issues:-
> >>
> >>
> >>
> >> 1) Upon initialization, OpenSBC is able to register successfully with
> >> various service providers. I configured a couple of Xlite softphones to
> >> register with OpenSBC and used them for testing inbound/ outbound
> >> calls with
> >> various service providers.
> >>
> >>
> >>
> >> *    Placing an outbound call from one of the Xlite softphones to an
> >> external service provider (Gafachi) works fine (attached log -
> >> outgoing.log)
> >> *    Placing an inbound call from an external service provider to
> >> opensbc
> >> results in the following error in the log (attached log - incoming.log)
> >>
> >>
> >>
> >
> >
> > Many things could go wrong in a SIP trunk configuration.  Routing rely
> > solely on the correct formating of the To URI.   You need to let me
> > know about the specifics of your configuration like the domain of the
> > SIP provider and the kind of INVITE the provider is sending to reach
> > your trunk.    BTW, your attachment did not make it.   You can send it
> > to me directly and i'll see what I can figure out.   An ethereal
> > capture would also be nice just in case we are investigating low level
> > interop issues aside from configuration issues.
> >
> >
> >> 4:43:39.304   DTL: [CID=0x0af8] Event: ---> Inbound - INVITE
> >> sip:16462781042@192.168.96.115:5066;transport=udp SIP/2.0
> >>
> >> 4:43:39.306   DBG: [CID=0x0af8] Session CREATED
> >>
> >> 4:43:39.306   INF: [CID=0x0af8] *** CREATED (UAS) CALL ***
> >> d82a729522b3f145f0798b363d25b6a1@64.192.112.13
> >>
> >> 4:43:39.306   INF: [CID=0x0af8] *** DESTROYED CALL ***
> >> d82a729522b3f145f0798b363d25b6a1@64.192.112.13
> >>
> >> 4:43:39.307   DBG: [CID=0x0af8] CALL: (inbound) : Session DESTROYED
> >>
> >> 4:43:39.308   ERR: [CID=0x0000] GC: .\src\CallSessionManager.cxx:528
> >> CallSessionManager::OnCreateServerSession::CallSession Attempt to
> >> CreateReference() a NULL Pointer or none descendant of PObject!!!
> >>
> >> 4:43:39.308   DBG: [CID=0x06cb] *** MESSAGE ARRIVAL *** No Session
> >> available
> >> to handle INVITE sip:16462781042@192.168.96.115:5066;transport=udp
> >> SIP/2.0
> >>
> >> 4:43:39.312   PWL: [CID=0x0000] Using Iface: 192.168.96.115 to send
> >> to Dest:
> >> 64.192.112.13
> >>
> >>
> >>
> >> Can you confirm if it's a bug/ configuration issue? The log file is
> >> attached
> >> for reference
> >>
> >>
> >>
> >> 2) While exploring various service providers, I found an issue with
> >> authentication in SIP trunking mode. While placing an outbound call
> >> to an
> >> external service provider from one of the UAs registered to SBC, if the
> >> external service provider requests authentication and returns a 407,
> >> the 407
> >> is relayed back by OpenSBC to the UA. This should not happen as all the
> >> credentials for service provider (trunk-account information) is
> >> present with
> >> the SBC itself. Any comments?
> >>
> >>
> >>
> >
> > I guessing OpenSBC was not able to identify the call as a trunk call
> > properly.   You are correct that the trunk should have handled the
> > authentication instead of relaying the 407.  If you are using the Main
> > trunk to route your calls to the SIP Trunk, you may try to use
> > "sip-trunk" parameter in our b2bua route
> >
> > Example:  [sip:1212*] sip:mytrunkprovider.com;sip-trunk=true
> >
> >
> > This would automatically tell the b2bua to route all calls bound to
> > New York to be routed to the SIP Trunk.
> >
> >
> >> I look forward to hearing from you regarding these issues. Please let
> me
> >> know if you need any other information regarding the same.
> >>
> >>
> >>
> >> Regards,
> >>
> >> Gaurav
> >>
> >>
> >> -----------------------------------------------------------------------
> -
> >>
> >> -----------------------------------------------------------------------
> --
> >>
> >> This SF.net email is sponsored by: Splunk Inc.
> >> Still grepping through log files to find problems?  Stop.
> >> Now Search log events and configuration files using AJAX and a browser.
> >> Download your FREE copy of Splunk now >> http://get.splunk.com/
> >> -----------------------------------------------------------------------
> -
> >>
> >> _______________________________________________
> >> opensipstack-devel mailing list
> >> ope...@li...
> >> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
> >>
> >> -----------------------------------------------------------------------
> -
> >>
> >> No virus found in this incoming message.
> >> Checked by AVG Free Edition. Version: 7.5.503 / Virus Database:
> >> 269.15.20/1107 - Release Date: 11/3/2007 11:22 AM
> >>
> >
> >
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> opensipstack-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel