2 Replies Last post: Nov 12, 2007 4:38 AM by Guest  
Guest

Feb 12, 2008 4:15 AM

Re: [OpenSIPStack] OpenSBC SIP Trunking - Null Session in 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"
;tag=gss4a7f914ce003e05a02fa166fc6c27f14
To:
Via: SIP/2.0/UDP 64.192.112.13:5060;branch=z9hG4bKd21aa1af
CSeq: 102 INVITE
Call-ID: d82a729522b3f145f0798b363d25b6a1@64.192.112.13
Contact:
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.


joegen@opensipstack.org 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
opensipstack-devel@lists.sourceforge.net
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
opensipstack-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
Guest
1. Nov 12, 2007 3:04 AM in response to: Guest
Re: [OpenSBC] [OpenSIPStack] OpenSBC SIP Trunking - Null Sessionin CallSessionManager.cxx
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: opensipstack-devel-bounces@lists.sourceforge.net
opensipstack-devel-bounces@lists.sourceforge.net On Behalf Of
joegen@opensipstack.org
Sent: Monday, November 12, 2007 8:09 AM
To: joegen@opensipstack.org
Cc: opensipstack-osbcdevel@lists.sourceforge.net; joegen.baclor@gmail.com;
dinesh.pinkcity@gmail.com; opensipstack-devel@lists.sourceforge.net
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"
;tag=gss4a7f914ce003e05a02fa166fc6c27f14
To:
Via: SIP/2.0/UDP 64.192.112.13:5060;branch=z9hG4bKd21aa1af
CSeq: 102 INVITE
Call-ID: d82a729522b3f145f0798b363d25b6a1@64.192.112.13
Contact:
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.


joegen@opensipstack.org 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
opensipstack-devel@lists.sourceforge.net
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
opensipstack-devel@lists.sourceforge.net
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-osbcdevel mailing list
Opensipstack-osbcdevel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensipstack-osbcdevel
Guest
2. Nov 12, 2007 4:38 AM in response to: Guest
Re: [OpenSIPStack] OpenSBC SIP Trunking - Null Sessionin CallSessionManager.cxx
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: opensipstack-devel-bounces@lists.sourceforge.net
opensipstack-devel-bounces@lists.sourceforge.net On Behalf Of
joegen@opensipstack.org
Sent: Monday, November 12, 2007 8:09 AM
To: joegen@opensipstack.org
Cc: opensipstack-osbcdevel@lists.sourceforge.net; joegen.baclor@gmail.com;
dinesh.pinkcity@gmail.com; opensipstack-devel@lists.sourceforge.net
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"
;tag=gss4a7f914ce003e05a02fa166fc6c27f14
To:
Via: SIP/2.0/UDP 64.192.112.13:5060;branch=z9hG4bKd21aa1af
CSeq: 102 INVITE
Call-ID: d82a729522b3f145f0798b363d25b6a1@64.192.112.13
Contact:
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.


joegen@opensipstack.org 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
opensipstack-devel@lists.sourceforge.net
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
opensipstack-devel@lists.sourceforge.net
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
opensipstack-devel@lists.sourceforge.net
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
opensipstack-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensipstack-devel