Thread: [OpenSIPStack] OpenSBC SIP Trunking - Null Session in CallSessionManager.cxx
Brought to you by:
joegenbaclor
Menu
▾
▴
opensipstack-devel
|
From: Gaurav K. <gkh...@is...> - 2007-11-06 08:18:52
|
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) 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 look forward to hearing from you regarding these issues. Please let me know if you need any other information regarding the same. Regards, Gaurav |
|
From: <jo...@op...> - 2007-11-12 02:29:51
|
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 > |
|
From: <jo...@op...> - 2007-11-12 02:39:30
|
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 >> > > |
|
From: Gaurav K. <gkh...@is...> - 2007-11-12 08:04:54
|
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 |
|
From: <jo...@op...> - 2007-11-12 09:38:57
|
Gaurav Kheterpal wrote: > 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. > Yeah, no argument about that. It's a valid URI. However, if Gafachi will follow the 3261 specs for constructing requests destined to a registered UA, it would have used the To-URI sent in the REGISTER, and set the startline-uri to point to the Contact address. This is very important for SIP trunking since OpenSBC can support multiple trunks and the only way to distinguish which trunk is involved in a call is via the to-uri > 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? > > I guess this would be safe. It allows you to use basic B2BUA routing to handle the call. I'll take a deeper look when i get the chance. > 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 >> > > > ------------------------------------------------------------------------- > 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 > > > > |
|
From: Gaurav K. <gkh...@is...> - 2007-11-16 05:59:12
|
Hi Joegen, We were able to get trunking working for inbound calls with OpenSBC. For the outbound trunking issue, you mentioned:- " 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" I subsequently tried that and found that sbc crashes in SBCSIPTrunkReg::GetEgressAuthInfo function at the start of For loop. *Configuration* OpenSBC 192.168.96.123 Xlite 192.168.96.36 Public LAN IP 59.95.152.178 voipvoip.com 69.90.209.57 *B2BAUA Route* [sip:*@192.168.96.123] sip:sip3.voipvoip.com:5060;sip-trunk=true *Trunking* <root> <siptrunk trunk-name="SIP" route-set="sip3.voipvoip.com" sip-domain="59.95.152.178" expires="3600"> <trunk-accounts> <account user-name="phonenumber" auth-user-name="phonenumber" auth-password="password" inbound-route="sip:102@192.168.96.123:5060" expires="3600"/> </trunk-accounts> </siptrunk> </root> The pcap file is attached for your reference. As always, thanks in advance for your help! Regards, Gaurav |
|
From: <jo...@op...> - 2007-11-16 08:08:02
|
Hi Gaurav, While I'm finding the time to see what's causing the crash, can you try setting inbound-route="sip:102@192.168.96.123:5060" to inbound-route="sip:102@192.168.96.123" -> (without the port) I am suspecting a string comparison failure. Thanks for the information. Joegen Gaurav Kheterpal wrote: > Hi Joegen, > > We were able to get trunking working for inbound calls with OpenSBC. For the > outbound trunking issue, you mentioned:- > > " 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" > > I subsequently tried that and found that sbc crashes in > SBCSIPTrunkReg::GetEgressAuthInfo function at the start of For loop. > > *Configuration* > > OpenSBC 192.168.96.123 > Xlite 192.168.96.36 > Public LAN IP 59.95.152.178 > voipvoip.com 69.90.209.57 > > *B2BAUA Route* > > [sip:*@192.168.96.123] sip:sip3.voipvoip.com:5060;sip-trunk=true > > *Trunking* > > <root> > <siptrunk trunk-name="SIP" > route-set="sip3.voipvoip.com" > sip-domain="59.95.152.178" > expires="3600"> > > <trunk-accounts> > <account user-name="phonenumber" > auth-user-name="phonenumber" > auth-password="password" > inbound-route="sip:102@192.168.96.123:5060" > expires="3600"/> > </trunk-accounts> > </siptrunk> > </root> > > The pcap file is attached for your reference. > > As always, thanks in advance for your help! > > Regards, > Gaurav > > > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.503 / Virus Database: 269.15.33/1133 - Release Date: 11/15/2007 8:57 PM > |
|
From: <sa...@ER...> - 2007-12-08 23:37:18
|
Hi Gaurav Have you solved this problem. You sent in a pcap but it was removed by the list can you it to me so i can may track a problem i am having? Warren Kreckler ----- Original Message ----- From: "jo...@op..." <joe...@gm...> To: "Gaurav Kheterpal" <gkh...@is...> Cc: <ope...@li...>; <joe...@gm...>; <din...@gm...>; <ope...@li...> Sent: Friday, November 16, 2007 2:07 AM Subject: Re: [OpenSIPStack] OpenSBC SIP Trunking - NullSessionin CallSessionManager.cxx > Hi Gaurav, > > While I'm finding the time to see what's causing the crash, can you try > setting > > inbound-route="sip:102@192.168.96.123:5060" > > to > > inbound-route="sip:102@192.168.96.123" -> (without the port) > > I am suspecting a string comparison failure. Thanks for the information. > > Joegen > > > > Gaurav Kheterpal wrote: > > Hi Joegen, > > > > We were able to get trunking working for inbound calls with OpenSBC. For the > > outbound trunking issue, you mentioned:- > > > > " 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" > > > > I subsequently tried that and found that sbc crashes in > > SBCSIPTrunkReg::GetEgressAuthInfo function at the start of For loop. > > > > *Configuration* > > > > OpenSBC 192.168.96.123 > > Xlite 192.168.96.36 > > Public LAN IP 59.95.152.178 > > voipvoip.com 69.90.209.57 > > > > *B2BAUA Route* > > > > [sip:*@192.168.96.123] sip:sip3.voipvoip.com:5060;sip-trunk=true > > > > *Trunking* > > > > <root> > > <siptrunk trunk-name="SIP" > > route-set="sip3.voipvoip.com" > > sip-domain="59.95.152.178" > > expires="3600"> > > > > <trunk-accounts> > > <account user-name="phonenumber" > > auth-user-name="phonenumber" > > auth-password="password" > > inbound-route="sip:102@192.168.96.123:5060" > > expires="3600"/> > > </trunk-accounts> > > </siptrunk> > > </root> > > > > The pcap file is attached for your reference. > > > > As always, thanks in advance for your help! > > > > Regards, > > Gaurav > > > > > > > > ------------------------------------------------------------------------ > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.503 / Virus Database: 269.15.33/1133 - Release Date: 11/15/2007 8:57 PM > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X