opensipstack-devel Mailing List for OpenSIPStack (Page 33)
Brought to you by:
joegenbaclor
Menu
▾
▴
opensipstack-devel
You can subscribe to this list here.
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
(12) |
Jul
(4) |
Aug
(3) |
Sep
(24) |
Oct
(45) |
Nov
(41) |
Dec
(67) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(51) |
Feb
(93) |
Mar
(54) |
Apr
(76) |
May
(114) |
Jun
(133) |
Jul
(124) |
Aug
(180) |
Sep
(53) |
Oct
(41) |
Nov
(109) |
Dec
(92) |
| 2008 |
Jan
(52) |
Feb
(40) |
Mar
(29) |
Apr
(40) |
May
(83) |
Jun
(68) |
Jul
(30) |
Aug
(72) |
Sep
(50) |
Oct
(48) |
Nov
(25) |
Dec
(80) |
| 2009 |
Jan
(9) |
Feb
(2) |
Mar
(32) |
Apr
(67) |
May
|
Jun
(7) |
Jul
(7) |
Aug
(4) |
Sep
(3) |
Oct
|
Nov
(6) |
Dec
(2) |
| 2010 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
(10) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: jonathan a. <jau...@gm...> - 2007-12-21 01:58:20
|
Joegen, No, we have not installed OpenSBC yet. I have been in the process of convincing my boss that this is the best way for us to go right now. He has had some questions, some of which I could answer and some not. This was one I could not answer. We are installing OpenSBC and will start our testing. The reason this question came up was that we are discussing putting the SIP traffic on one VLAN and the RTP traffic on another. I appreciate your responses. It has been a big help. Jonathan On Dec 20, 2007 5:19 PM, Joegen E. Baclor <jb...@so...> wrote: > > > >> I see pending requests for routing based on NIC the packet > arrived on, but > >> is there any support for multiple NICs currently in OpenSBC? > Does it handle > >> multiple interfaces? If not, what would be the projected release > for such a > >> capability? > > > > > > OpenSBC binds to all NIC by default. It can act as a bridge for > multi-homed hosts. I am curious what made you ask the question, did you > initially had problems with multiple NICs? > > > > > > Joegen > > > > ------------------------------------------------------------------------- > 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 > |
|
From: Joegen E. B. <jb...@so...> - 2007-12-21 01:19:35
|
>> I see pending requests for routing based on NIC the packet arrived on, but
>> is there any support for multiple NICs currently in OpenSBC? Does it handle
>> multiple interfaces? If not, what would be the projected release for such a
>> capability?
OpenSBC binds to all NIC by default. It can act as a bridge for multi-homed hosts. I am curious what made you ask the question, did you initially had problems with multiple NICs?
Joegen
|
|
From: jonathan a. <jau...@gm...> - 2007-12-20 20:18:21
|
I see pending requests for routing based on NIC the packet arrived on, but is there any support for multiple NICs currently in OpenSBC? Does it handle multiple interfaces? If not, what would be the projected release for such a capability? Jonathan |
|
From: Joegen E. B. <joe...@gm...> - 2007-12-20 02:51:02
|
The CALEA Trunk in OpenSBC is intended for future implementation if a LEA collector in OpenSBC. The trunk allows for the SIP Packet and RTP Packets to be saved to file in lib pcap format. There are two approach for this. Either we use an external LEA Collector that sniffs the packet to and fro the CALEA port of OpenSBC or implement LEA collector in OpenSBC itself. Since this trunk implmements its own Connection object, it would give you much higher access to the low level behavior of the call. I would still advice you just override B2BCallInterface and attache it to the CALEA trunk with you own implmentation of OnOutgoingCall(). See my previous message Subject: How to modify From header Joegen sales@ER wrote: > Hi Joegen > > Please explain how you inserted CALEA Trunk into OSBC? I want to have the > Web Admin pick it up. > > I am going to custom the CALEA Trunk.cxx and call it SIP FromHeader Trunk.xx > just for our internal use and not for prime time. > > I want to intercept the From header and modify it to convert domain names to > ipaddr's and send it back into the stack > > Warren Kreckler > > > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > |
|
From: <sa...@ER...> - 2007-12-19 18:23:41
|
Hi Joegen Please explain how you inserted CALEA Trunk into OSBC? I want to have the Web Admin pick it up. I am going to custom the CALEA Trunk.cxx and call it SIP FromHeader Trunk.xx just for our internal use and not for prime time. I want to intercept the From header and modify it to convert domain names to ipaddr's and send it back into the stack Warren Kreckler |
|
From: <sa...@ER...> - 2007-12-18 18:58:24
|
Hi
I'm going in circles (482 Loop detected) with the correct syntax for B2Bua.
remote Sip Trunk Provider x.x.x.102
Local Network sipX x.x.x.222
openSBC x.x.x.115
IP Phone x.x.x.226
I want to reach STP from openSBC or from sipX or from the Phone. Could it
be the Replace and Insert Route flags are the problem. Any guidence Please.
Please fill in the blanks.
[sip:_._._.115:5060] sip._._._.102:5060;sip-trunk=true
[sip:_._._.222:5060] sip._._._.102:5060;sip-trunk=true
[sip:_._._.226:5060] sip._._._.102:5060;sip-trunk=true
Warren Kreckler
|
|
From: <sa...@ER...> - 2007-12-18 18:32:17
|
Hi We need to change the from: 777...@xr... to 7771113333@192.148.1.1 Thats a domain name into a ipaddr. Can someone please show where in the code to make this substitution? Warren Kreckler |
|
From: Chris V. <chr...@gm...> - 2007-12-17 23:24:41
|
Expanding on the From field modifications. Here are some additonals headers/parameters that I think are bleading through and should be modified to make a more stable B2BUA:
<font face="Arial">{size:2}<span style="font-family: Arial">{size:10pt}From
field{size}</span>{size}</font>
<font face="Arial">{size:2}<span style="font-family: Arial">{size:10pt}Call-ID{size}</span>{size}</font>
<font face="Arial">{size:2}<span style="font-family: Arial">{size:10pt}SDP o-line IPV4
address{size}</span>{size}</font>
<font face="Arial">{size:2}<span style="font-family: Arial">{size:10pt}Remote-Party ID(if received)
{size}</span>{size}</font>
Based upon our testing, we have seen private IPs and other information that I feel should be transformed prior to creation of the new INVITE. In general these are somewhat cosmetic and do not effect functionality. But for true topology hiding this information is leaking through.
|
|
From: Joegen E. B. <joe...@gm...> - 2007-12-17 23:14:36
|
A simple approach would be to search for the pattern "via:" until the last occurrence of CR/LF. If the search algo finds the string, then it's a SIP message. This is based on the assumption that all SIP messages will have a via header. If it's not a SIP message, you may get the version bit of the RTP packet from the first byte (((packet[0]>>6)&3) == 2) . If the version is 2, then it might be an RTP packet. You can then proceed in parsing the entire RTP header and see if it is indeed an RTP packet. A much better approach is to dig into the ethereal/wireshark code and see how it determines which protocol a packet belongs to. HTH Ashish Khare wrote: > Hi Joegen, > > I ahve one query. > By Looking at the UDP packet, how to find out if the packet is SIP or RTP. > We cannot use the destination port information as the there are no standard > fixed port for SIP/RTP. Although the Default port for SIP is 5060, but still > some servers may use different ports. > What information you use while parsing to identify if the packet is SIP or > RTP. > > Please reply. > > regards > Ashish > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > > > |
|
From: <jo...@op...> - 2007-12-17 22:59:06
|
Hi Jonathan, jonathan augenstine wrote: > I am looking at OpenSBC to evaluate is for a commercial, currently live SIP > installation. I have two questions that I have not been able to answer from > the documentation or email-list archives. First, what is the projected > schedule for TLS? I see that it looks like it is on the list but not when > it might be done. TLS support is already in the coding table. I am expecting to finish support for TLS by the end of January next year with the release of OpenSIPStack version 2.0. > Second, I cannot find any documentation on fault tolerant > support. Is a fault tolerant (hot standby) installation supported and where > can I find information on how to accomplish this task? > OpenSBC itself does not internally support hot stand-by. OpenVZ (http://openvz.org/) might work with OpenSBC because it claims to support Layer 4 stickiness. If you decide to get your hands dirty, please let the list know about your success or failure with OpenVZ. > Thank You, > Jonathan > jau...@gm... > 626.688.0158 > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > > > |
|
From: Ashish K. <ash...@gm...> - 2007-12-17 21:25:24
|
Hi Joegen, I ahve one query. By Looking at the UDP packet, how to find out if the packet is SIP or RTP. We cannot use the destination port information as the there are no standard fixed port for SIP/RTP. Although the Default port for SIP is 5060, but still some servers may use different ports. What information you use while parsing to identify if the packet is SIP or RTP. Please reply. regards Ashish |
|
From: jonathan a. <jau...@gm...> - 2007-12-17 17:49:38
|
I am looking at OpenSBC to evaluate is for a commercial, currently live SIP installation. I have two questions that I have not been able to answer from the documentation or email-list archives. First, what is the projected schedule for TLS? I see that it looks like it is on the list but not when it might be done. Second, I cannot find any documentation on fault tolerant support. Is a fault tolerant (hot standby) installation supported and where can I find information on how to accomplish this task? Thank You, Jonathan jau...@gm... 626.688.0158 |
|
From: Joegen E. B. <joe...@gm...> - 2007-12-15 02:22:33
|
Are you playing the DTMF tones locally as well (I mean do you play the tone in your local speaker as well)? Consider the possibility that Asterisk is detecting the tone you generate locally inband on top of the OOB DTMF you send via INFO or RFC 2833. Whit Thiele wrote: > I'm trying to play DTMF tones out of ATLSIP, into asterisk and out to the > PSTN via a SIP trunk. I know there are several dtmfmode configurations to > use such as info or inband but I'm getting some strange behavior. 9 times > out of 10 I'll get double tones when using SendINFOTone. Then, using > SendRFC2833Tone it sometimes doesn't even play anything at all to the called > party. I tried using an X-Lite Softphone to eliminate it being an asterisk > issue and it works fine so I wonder if there is something strange happening > here with ATLSIP. Any suggestions or is anyone else having these problems? > > Whit > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > > |
|
From: <sa...@ER...> - 2007-12-14 21:38:59
|
Hi ethernaez I was out of office all day and when i got back in your email was waiting. I thought this was a nice jester until i realize my boss sent the question from my work station. Sip Trunking has been on my mind the last couple of nights. Thank you very much. Warren Kreckler ----- Original Message ----- From: "ehernaez" <ope...@op...> To: <ope...@li...> Sent: Friday, December 14, 2007 10:20 AM Subject: Re: [OpenSIPStack] [OpenSBC] Sip Trunck Howto > Please see here: http://www.opensourcesip.org:8080/clearspacex/docs/DOC-1040 > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > |
|
From: Whit T. <de...@wh...> - 2007-12-14 18:30:32
|
I'm trying to play DTMF tones out of ATLSIP, into asterisk and out to the PSTN via a SIP trunk. I know there are several dtmfmode configurations to use such as info or inband but I'm getting some strange behavior. 9 times out of 10 I'll get double tones when using SendINFOTone. Then, using SendRFC2833Tone it sometimes doesn't even play anything at all to the called party. I tried using an X-Lite Softphone to eliminate it being an asterisk issue and it works fine so I wonder if there is something strange happening here with ATLSIP. Any suggestions or is anyone else having these problems? Whit |
|
From: ehernaez <ope...@op...> - 2007-12-14 16:20:58
|
Please see here: http://www.opensourcesip.org:8080/clearspacex/docs/DOC-1040 |
|
From: <sa...@ER...> - 2007-12-14 14:28:14
|
Hi ALL Is there a document that explains the rational/thinking as to openSBC concept of SiP Trunks operation? If not could someone please provide some quidence. When using a Sip Server, openSBC and ITSP what should be proper settings for B2BUA to allow traffic in both directions. Could someone show by examples using the three (3) antangonist above in their explanation/examples. r |
|
From: <sa...@ER...> - 2007-12-13 20:56:19
|
Hi Joegen Where is the SIPHeader header located? I'm putting the > SIPHeader myHeader( "Remote-Party-Id", "Whatever the value is" ); > invite.AddCustomHeader( myHeader ); code in SBCBackDoorTrunk.cxx. inside of the SBCBackDoorHandler::SBCBackDoorHandler method.. This should call the constructor first and execute the > SIPHeader myHeader( "Remote-Party-Id", "Whatever the value is" ); > invite.AddCustomHeader( myHeader ); Next. Unless you think it should go somewhere else Warren Kreckler ----- Original Message ----- From: "Joegen E. Baclor" <joe...@gm...> To: "sales@ER" <sa...@el...>; <ope...@li...>; "listaopenSBC" <ope...@li...> Sent: Wednesday, December 12, 2007 8:46 PM Subject: Re: [OpenSIPStack] B2BUA how to route > sales@ER wrote: > > Hi Joegen > > > > > >> I see what you mean. I am not really familiar with the use of the > >> Remote-Party-Id. We have implemented P-Asserted-Identity for this > >> instead. Can you point me to the RFC that discusses the use cases for > >> Remote-Party-Id? > >> > > > > Yes the P-Asserted-Identity replaced the Remote-Party-Id in the RFC but it > > is still in used in older SBC models and my ITSP has not updated the SBC i > > am accessing. I need to modifry the xml code to and and elseif to test for > > this possiblity. Please direct me to the xml that is managing this > > identity. > > > > For you be able to rewrite any header before it gets sent to the UAS you > need to override SBCBackDoorCallHandler::OnOutgoingCall(); > > Look for the declaration of class SBCBackDoorCallHandler in > SBCBackDoorTrunk.cxx. Add a new member function > > virtual void OnOutgoingCall( > B2BUAConnection & connection, > B2BUACall & call, > SIPMessage & invite > ); > > > This function will be called whenever there is a new INVITE that will be > sent out by the backdoor trunk. Implement this function right after > BOOL SBCBackDoorCallHandler::OnReceivedMergedInvite() methid in > SBCBackDoorTrunk.cxx > > > You may add special headers to invite using this code > > SIPHeader myHeader( "Remote-Party-Id", "Whatever the value is" ); > invite.AddCustomHeader( myHeader ); > > HTH > > Joegen > > Warren Kreckler > > > > > > ----- Original Message ----- > > From: "Joegen E. Baclor" <joe...@gm...> > > To: "sales@ER" <sa...@el...> > > Sent: Tuesday, December 11, 2007 8:32 PM > > Subject: Re: [OpenSIPStack] B2BUA how to route > > > > > > > >> sales@ER wrote: > >> > >>> Hi Joegen > >>> > >>> Thank you very much for your replies. > >>> > >>> 1. I'm using the lastest version. > >>> > >>> > >> Then your ITSP must be seeing just a single via. If you think the > >> contrary, send me a packet capture from sipx->OpenSBC and OpenSBC->ITSP > >> > >> > >> > >> > >>> 3. sipX does not re-write header as far as I know. Are you asking for > >>> sipX header(s) dealing with Caller-ID? > >>> > >>> Remote-Party-ID to determine the Calling ID. This is not an element > >>> created > >>> by Sipx. The SBC will need to extract the user part of the From URI > >>> > > and > > > >>> create a Remote-Party-ID. I did not see this capability with OpenSBC. > >>> Without this, the called party on the PSTN will either see "Private > >>> Caller"or "Anonymous" on their phone instead of the DID. > >>> > >>> > >>> > >> I see what you mean. I am not really familiar with the use of the > >> Remote-Party-Id. We have implemented P-Asserted-Identity for this > >> instead. Can you point me to the RFC that discusses the use cases for > >> Remote-Party-Id? > >> > >> > >> > >>> Warren Kreckler > >>> > >>> > >>> > >>> > >>> > >>> ----- Original Message ----- > >>> From: "Joegen E. Baclor" <joe...@gm...> > >>> To: "sales@ER" <sa...@el...> > >>> Cc: <ope...@li...> > >>> Sent: Sunday, December 09, 2007 7:21 PM > >>> Subject: Re: [OpenSIPStack] B2BUA how to route > >>> > >>> > >>> > >>> > >>>> inline... > >>>> > >>>> sales@ER wrote: > >>>> > >>>> > >>>>> Yes They call it peer to peer. By that they meam > >>>>> > >>>>> > >>>>> 1. Via Headers: ITSP has stated that they can accept only 1 Via > >>>>> statement in an INVITE. As background, each device will add a Via > >>>>> > >>>>> > >>> statement > >>> > >>> > >>>>> to the INVITE to if it has processed the INVITE. Only the last or top > >>>>> > >>>>> > >>> entry > >>> > >>> > >>>>> is really of interest to the party that next handles the INVITE. In > >>>>> > >>>>> > >>> order > >>> > >>> > >>>>> for ITSP to accept the INVITE of an outbound call, OpenSBC will > >>>>> need to strip off all previous Via statements from the INVITE and add > >>>>> > >>>>> > >>> its' > >>> > >>> > >>>>> own. I have not found any capability to remove the previously > >>>>> > > inserted > > > >>> Via > >>> > >>> > >>>>> statements. > >>>>> > >>>>> > >>>>> > >>>> What version are you using? There was a bug introduced when we got > >>>> back from sipIT 21 due to the changes made there that had the vias not > >>>> getting stripped. Please use the latest CVS. OpenSBC should be > >>>> stripping the via before the B2BUA sends the INVITE out to the UAS. > >>>> > >>>> > >>>> > >>>> > >>>>> 2. Lock IP Address and port to first sender: This option comes into > >>>>> > >>>>> > >>> play > >>> > >>> > >>>>> when a call has been answered either by a person or system component > >>>>> > >>>>> > >>> (i.e. > >>> > >>> > >>>>> Auto Attendant) and a transfer is attempted. When the transferred > >>>>> > > call > > > >>> is > >>> > >>> > >>>>> answered by a new phone or component, it will negotiate use of a new > >>>>> > > RTP > > > >>>>> port for the media stream. Some service providers, ITSP included, > >>>>> do not allow the RTP port to change once the initial call is > >>>>> > >>>>> > >>> established. > >>> > >>> > >>>>> They do this to protect against the "hijacking" of a call by Hackers. > >>>>> > >>>>> > >>> Since > >>> > >>> > >>>>> the media is flowing through a SBC, the SBC then needs to manage which > >>>>> > >>>>> > >>> ports > >>> > >>> > >>>>> are used to exchange media (voice). If the original port is not > >>>>> > >>>>> > >>> utilized > >>> > >>> > >>>>> for the media back to the carrier, the PSTN will not hear any audio > >>>>> > > once > > > >>> the > >>> > >>> > >>>>> call is transferred. I do not see this capability with OpenSBC. > >>>>> > >>>>> > >>>>> > >>>>> > >>>> In media proxy mode (Always Proxy Media = true), OpenSBC does not > >>>> > > change > > > >>>> the port of RTP even during reInvites. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> 3. Calling ID: SIPxchange utilizes the From: element to provide the > >>>>> Calling ID (DID). It normally inserts the userID in the user part of > >>>>> > >>>>> > >>> the > >>> > >>> > >>>>> >From URI. ITSP uses the INVITE element > >>>>> Remote-Party-ID to determine the Calling ID. This is not an element > >>>>> > >>>>> > >>> created > >>> > >>> > >>>>> by Sipx. The SBC will need to extract the user part of the From URI > >>>>> > > and > > > >>>>> create a Remote-Party-ID. I did not see this capability with OpenSBC. > >>>>> Without this, the called party on the PSTN will either see "Private > >>>>> Caller"or "Anonymous" on their phone instead of the DID. > >>>>> > >>>>> > >>>>> > >>>>> > >>>> Can you send a sample of this from header that is rewritten by sipX? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> Warren Kreckler > >>>>> > >>>>> ----- Original Message ----- > >>>>> From: "Joegen E. Baclor" <joe...@gm...> > >>>>> To: <ope...@li...> > >>>>> Cc: <jo...@op...> > >>>>> Sent: Friday, December 07, 2007 12:08 AM > >>>>> Subject: Re: [OpenSIPStack] B2BUA how to route > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> You need to use the SIP Trunking capability of OpenSBC for this. Do > >>>>>> you need to authenticate calls with your ITSP? > >>>>>> > >>>>>> > >>>>>> sales@ER wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Hi > >>>>>>> > >>>>>>> Almost have this puppy working. > >>>>>>> > >>>>>>> Sipx and opensbc generally well understood. > >>>>>>> > >>>>>>> Problem: > >>>>>>> > >>>>>>> When OSBC receives INVITE from sipX => ITSP, > >>>>>>> OSBC route the INVITE back to sipX. > >>>>>>> > >>>>>>> We have two rules in the B2Bua route > >>>>>>> [sip:202.100.2.23:5060] sip: 202.100.2.23 this goes to our ITSP > >>>>>>> [sip:sipx.sip.net:5060] sip:sipx.sip.net this point to > >>>>>>> > > our > > > >>>>>>> > >>>>> sipx > >>>>> > >>>>> > >>>>> > >>>>>>> the missing rule/route? > >>>>>>> > >>>>>>> Where do you put the rule and what should the rule say to route > >>>>>>> > > INVITE > > > >>>>>>> > >>>>> out > >>>>> > >>>>> > >>>>> > >>>>>>> to our ITSP? > >>>>>>> > >>>>>>> Warren Kreckler > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>> ----------------------------------------------------------------------- - > >>>> > > - > > > >>>>>>> SF.Net email is sponsored by: The Future of Linux Business White > >>>>>>> > > Paper > > > >>>>>>> from Novell. From the desktop to the data center, Linux is going > >>>>>>> mainstream. Let it simplify your IT future. > >>>>>>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > >>>>>>> _______________________________________________ > >>>>>>> opensipstack-devel mailing list > >>>>>>> ope...@li... > >>>>>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>> ----------------------------------------------------------------------- - > >>>> > > - > > > >>>>>> SF.Net email is sponsored by: > >>>>>> Check out the new SourceForge.net Marketplace. > >>>>>> It's the best place to buy or sell services for > >>>>>> just about anything Open Source. > >>>>>> http://sourceforge.net/services/buy/index.php > >>>>>> _______________________________________________ > >>>>>> opensipstack-devel mailing list > >>>>>> ope...@li... > >>>>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > >>> > >>> > >> > > > > > > > > > > > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > |
|
From: Joegen E. B. <joe...@gm...> - 2007-12-13 02:49:27
|
Dangi, Rajpal wrote: > What about the feature to host OpenSBC behind NAT/firewall? > I have tested OpenSBC in amazon EC2 cloud. OpenSBC is installed in a virtual machine with a private IP address and Amazon exposes it through a public interface with one to one port binding. I then set the static media address parameter of OpenSBC to point to the public interface. I was able to test this setup to be working. The assumption here is that all traffic going to OpenSBC is coming from the public side of the network. In this scenario, no feature request is needed to fulfill it. It's already there. The other scenario, which I think what you have in mind, is OpenSBC acting as a bridge between a private network and a public network while having itself bound by the same NAT firewall of the private network. Given that your NAT/Firewall is also a one to one setup, calls coming from the public space goinf to the public space would still work the way it worked in the amazon EC2 setup. However the problem will arise if the call is coming from the public side towards the private network. OpenSBC would then need to determine when to rewrite the SDP using the static media address and not. Given that we are able to do this, OpenSBC should be able to bridge the NAT properly. This is always a tricky setup because no two systems behave similarly in such cases. There are also a lot of system specific behavior that are needed to be addressed not to mention screwed up routing tables. Thus, this is into feature that would be solved with a snap of a finger. I am sorry this cannot make it to the final release of 1.1.5 or even promise that 1.1.6 will have this feature. If you have this kind of setup... then go for an NAT devices with a built-in ALG. Joegen > Rajpal > > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] On Behalf > Of Joegen E. Baclor > Sent: Tuesday, December 11, 2007 5:59 PM > To: ope...@li...; listaopenSBC > Subject: [OpenSBC] OpenSBC 1.1.6, Summary of Feature Requests and Bug > Reports > > Hi Everyone, > > I am intending to finalize 1.1.5 release before the year ends so we have > > a clean slate for 1.1.6. If you have feature requests or bug fixes > which you think should be part of this release, please document them and > > post them to the list ASAP. We are going to implement CVS branches > beginning 1.1.5 to allow bug fixes specific to a certain branch. There > > will be some major architectural changes that will be implemented in > version 1.1.6 which might not be anymore compatible with the 1.1.5 > branch. I will enumerate the pending feature requests I summarized > from previous post. Let me know if I missed smething > > Pending Feature Requests: > > 1. Support for redirect in relay Routes - sam...@ve... > 2. Creation of folders (logs, registry, calea etc ) in places where > user has permission - H.Kropf > 3. Rewriting of From URI - Warren Kreckler > 4. Routing based on Packet Source - chr...@gm... > 5. Routing based on recipient NIC - Warren Kreckler > > If I missed something feel free to reply inline. > > Planned Features for 1.1.6 > > 1. I have already announced the plan for a separate configuration > module on top of the current HTTP Admin. > 2. We are also going to implement a separate media proxy application > to allow HA/Load Balancing of streams on top of the internal media proxy > > implementation. This change would allow an SBC to use multiple > instances of external media proxies giving way to a higher volume > deployment. > 3. We are also going to extract the Media Server Trunk and promote it > as a fully featured VXML Media Server allowing PBX developers to create > PBX applications using the OpenSIPStack Framework. > 4. The plan to implement Diameter as the AAA implementation in OpenSBC. > 5. Finally, the long awaited resurrection of the TCP and TLS > transports. > > I have also Opened a new development effort in SourceForge called > Plugin++ ( http://sourceforge.net/projects/pluginpp ). This new > project will be the entry point of a planned Plugin Framework/API for > OpenSBC and other OpenSIPStack applications. > > We are aiming for June 2008 as the ETC for the 1.1.6 release of > OpenSBC. We will come up with milestone releases for each > functionality. > > > ------------------------------------------------------------------------ > - > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Opensipstack-osbcdevel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-osbcdevel > > > |
|
From: Joegen E. B. <joe...@gm...> - 2007-12-13 02:46:27
|
sales@ER wrote:
> Hi Joegen
>
>
>> I see what you mean. I am not really familiar with the use of the
>> Remote-Party-Id. We have implemented P-Asserted-Identity for this
>> instead. Can you point me to the RFC that discusses the use cases for
>> Remote-Party-Id?
>>
>
> Yes the P-Asserted-Identity replaced the Remote-Party-Id in the RFC but it
> is still in used in older SBC models and my ITSP has not updated the SBC i
> am accessing. I need to modifry the xml code to and and elseif to test for
> this possiblity. Please direct me to the xml that is managing this
> identity.
>
For you be able to rewrite any header before it gets sent to the UAS you
need to override SBCBackDoorCallHandler::OnOutgoingCall();
Look for the declaration of class SBCBackDoorCallHandler in
SBCBackDoorTrunk.cxx. Add a new member function
virtual void OnOutgoingCall(
B2BUAConnection & connection,
B2BUACall & call,
SIPMessage & invite
);
This function will be called whenever there is a new INVITE that will be
sent out by the backdoor trunk. Implement this function right after
BOOL SBCBackDoorCallHandler::OnReceivedMergedInvite() methid in
SBCBackDoorTrunk.cxx
You may add special headers to invite using this code
SIPHeader myHeader( "Remote-Party-Id", "Whatever the value is" );
invite.AddCustomHeader( myHeader );
HTH
Joegen
> Warren Kreckler
>
>
> ----- Original Message -----
> From: "Joegen E. Baclor" <joe...@gm...>
> To: "sales@ER" <sa...@el...>
> Sent: Tuesday, December 11, 2007 8:32 PM
> Subject: Re: [OpenSIPStack] B2BUA how to route
>
>
>
>> sales@ER wrote:
>>
>>> Hi Joegen
>>>
>>> Thank you very much for your replies.
>>>
>>> 1. I'm using the lastest version.
>>>
>>>
>> Then your ITSP must be seeing just a single via. If you think the
>> contrary, send me a packet capture from sipx->OpenSBC and OpenSBC->ITSP
>>
>>
>>
>>
>>> 3. sipX does not re-write header as far as I know. Are you asking for
>>> sipX header(s) dealing with Caller-ID?
>>>
>>> Remote-Party-ID to determine the Calling ID. This is not an element
>>> created
>>> by Sipx. The SBC will need to extract the user part of the From URI
>>>
> and
>
>>> create a Remote-Party-ID. I did not see this capability with OpenSBC.
>>> Without this, the called party on the PSTN will either see "Private
>>> Caller"or "Anonymous" on their phone instead of the DID.
>>>
>>>
>>>
>> I see what you mean. I am not really familiar with the use of the
>> Remote-Party-Id. We have implemented P-Asserted-Identity for this
>> instead. Can you point me to the RFC that discusses the use cases for
>> Remote-Party-Id?
>>
>>
>>
>>> Warren Kreckler
>>>
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: "Joegen E. Baclor" <joe...@gm...>
>>> To: "sales@ER" <sa...@el...>
>>> Cc: <ope...@li...>
>>> Sent: Sunday, December 09, 2007 7:21 PM
>>> Subject: Re: [OpenSIPStack] B2BUA how to route
>>>
>>>
>>>
>>>
>>>> inline...
>>>>
>>>> sales@ER wrote:
>>>>
>>>>
>>>>> Yes They call it peer to peer. By that they meam
>>>>>
>>>>>
>>>>> 1. Via Headers: ITSP has stated that they can accept only 1 Via
>>>>> statement in an INVITE. As background, each device will add a Via
>>>>>
>>>>>
>>> statement
>>>
>>>
>>>>> to the INVITE to if it has processed the INVITE. Only the last or top
>>>>>
>>>>>
>>> entry
>>>
>>>
>>>>> is really of interest to the party that next handles the INVITE. In
>>>>>
>>>>>
>>> order
>>>
>>>
>>>>> for ITSP to accept the INVITE of an outbound call, OpenSBC will
>>>>> need to strip off all previous Via statements from the INVITE and add
>>>>>
>>>>>
>>> its'
>>>
>>>
>>>>> own. I have not found any capability to remove the previously
>>>>>
> inserted
>
>>> Via
>>>
>>>
>>>>> statements.
>>>>>
>>>>>
>>>>>
>>>> What version are you using? There was a bug introduced when we got
>>>> back from sipIT 21 due to the changes made there that had the vias not
>>>> getting stripped. Please use the latest CVS. OpenSBC should be
>>>> stripping the via before the B2BUA sends the INVITE out to the UAS.
>>>>
>>>>
>>>>
>>>>
>>>>> 2. Lock IP Address and port to first sender: This option comes into
>>>>>
>>>>>
>>> play
>>>
>>>
>>>>> when a call has been answered either by a person or system component
>>>>>
>>>>>
>>> (i.e.
>>>
>>>
>>>>> Auto Attendant) and a transfer is attempted. When the transferred
>>>>>
> call
>
>>> is
>>>
>>>
>>>>> answered by a new phone or component, it will negotiate use of a new
>>>>>
> RTP
>
>>>>> port for the media stream. Some service providers, ITSP included,
>>>>> do not allow the RTP port to change once the initial call is
>>>>>
>>>>>
>>> established.
>>>
>>>
>>>>> They do this to protect against the "hijacking" of a call by Hackers.
>>>>>
>>>>>
>>> Since
>>>
>>>
>>>>> the media is flowing through a SBC, the SBC then needs to manage which
>>>>>
>>>>>
>>> ports
>>>
>>>
>>>>> are used to exchange media (voice). If the original port is not
>>>>>
>>>>>
>>> utilized
>>>
>>>
>>>>> for the media back to the carrier, the PSTN will not hear any audio
>>>>>
> once
>
>>> the
>>>
>>>
>>>>> call is transferred. I do not see this capability with OpenSBC.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> In media proxy mode (Always Proxy Media = true), OpenSBC does not
>>>>
> change
>
>>>> the port of RTP even during reInvites.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> 3. Calling ID: SIPxchange utilizes the From: element to provide the
>>>>> Calling ID (DID). It normally inserts the userID in the user part of
>>>>>
>>>>>
>>> the
>>>
>>>
>>>>> >From URI. ITSP uses the INVITE element
>>>>> Remote-Party-ID to determine the Calling ID. This is not an element
>>>>>
>>>>>
>>> created
>>>
>>>
>>>>> by Sipx. The SBC will need to extract the user part of the From URI
>>>>>
> and
>
>>>>> create a Remote-Party-ID. I did not see this capability with OpenSBC.
>>>>> Without this, the called party on the PSTN will either see "Private
>>>>> Caller"or "Anonymous" on their phone instead of the DID.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Can you send a sample of this from header that is rewritten by sipX?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Warren Kreckler
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Joegen E. Baclor" <joe...@gm...>
>>>>> To: <ope...@li...>
>>>>> Cc: <jo...@op...>
>>>>> Sent: Friday, December 07, 2007 12:08 AM
>>>>> Subject: Re: [OpenSIPStack] B2BUA how to route
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> You need to use the SIP Trunking capability of OpenSBC for this. Do
>>>>>> you need to authenticate calls with your ITSP?
>>>>>>
>>>>>>
>>>>>> sales@ER wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> Almost have this puppy working.
>>>>>>>
>>>>>>> Sipx and opensbc generally well understood.
>>>>>>>
>>>>>>> Problem:
>>>>>>>
>>>>>>> When OSBC receives INVITE from sipX => ITSP,
>>>>>>> OSBC route the INVITE back to sipX.
>>>>>>>
>>>>>>> We have two rules in the B2Bua route
>>>>>>> [sip:202.100.2.23:5060] sip: 202.100.2.23 this goes to our ITSP
>>>>>>> [sip:sipx.sip.net:5060] sip:sipx.sip.net this point to
>>>>>>>
> our
>
>>>>>>>
>>>>> sipx
>>>>>
>>>>>
>>>>>
>>>>>>> the missing rule/route?
>>>>>>>
>>>>>>> Where do you put the rule and what should the rule say to route
>>>>>>>
> INVITE
>
>>>>>>>
>>>>> out
>>>>>
>>>>>
>>>>>
>>>>>>> to our ITSP?
>>>>>>>
>>>>>>> Warren Kreckler
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>> ------------------------------------------------------------------------
>>>>
> -
>
>>>>>>> SF.Net email is sponsored by: The Future of Linux Business White
>>>>>>>
> Paper
>
>>>>>>> from Novell. From the desktop to the data center, Linux is going
>>>>>>> mainstream. Let it simplify your IT future.
>>>>>>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>>>>>>> _______________________________________________
>>>>>>> opensipstack-devel mailing list
>>>>>>> ope...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>> ------------------------------------------------------------------------
>>>>
> -
>
>>>>>> SF.Net email is sponsored by:
>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>> It's the best place to buy or sell services for
>>>>>> just about anything Open Source.
>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>> _______________________________________________
>>>>>> opensipstack-devel mailing list
>>>>>> ope...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>
>
|
|
From: Ilian J. C. P. <ip...@so...> - 2007-12-12 08:52:58
|
Hi Whit, Whit Thiele wrote: > Hey Guys, > > Is it possible to play a recorded file (like a .wav file) from the ATLSIP > As Joegen has said, this functionality is not readily available in ATLSIP. > Softphone so that it plays and can be heard by both the caller and the > callee at the same time? > You will need a mixer for this condition. The way I see it this can probably be implemented via a filter. Refer to OpalPCSSConnection::OnPatchMediaStream(..) and check how OpalSilenceDetector and OpalEchoCanceler filters handle it. Another filter class is needed to handle the mixing of the streams with a wav file (PWavFile). I can probably implement this myself but it will take a while because I have other higher priority projects. Regards, Ilian > I've seen a lot of references in the code to Play File, but not really sure > how it works (ie. VoiceFileChannel::PlayFile) Any tips would be great... > > Thanks, > > Whit > > > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > |
|
From: Joegen E. B. <joe...@gm...> - 2007-12-12 02:39:43
|
Whit, There is currently no provision to play wav files through the softphone interface. If you want to dig deeper, you need to look at the media server implementation. Ilian is in the best position to give you more details how this can be done. I am sorry I can't be of further assistance to you on this. Joegen Whit Thiele wrote: > Hey Guys, > > Is it possible to play a recorded file (like a .wav file) from the ATLSIP > Softphone so that it plays and can be heard by both the caller and the > callee at the same time? > > I've seen a lot of references in the code to Play File, but not really sure > how it works (ie. VoiceFileChannel::PlayFile) Any tips would be great... > > Thanks, > > Whit > > > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > > |
|
From: Joegen E. B. <joe...@gm...> - 2007-12-12 02:36:51
|
sales@ER wrote: > Hi > > I need help with Routing. These is my credencials > > lan 69.x.x.0/24 > sipx server 69.x.x.240 > openSBC 69.x.x.241 > ITSP 204.x.x.202 > calling from 773.3277006 > calling to 7739050161 > > UpperRegistration:: > [sip:sipx.sip.net:*] sip:sipx.sip.net:5060;domain=sipx.sip.net > [sip:sipx.sip.net:*] sip:69.x.x.240:5060;domain=sipx.sip.net > [sip:69.x.x.240] sip:69.x.x.240:5060;domain=sipx.sip.net > > You have multiple * or catch all routes. OpenSBC will stop your traversing your route the first time it sees a match. Since * matches all, your remaining routes will not be processed. Make sure you give specific prefixes for each of your routes and have the catch all as the "LAST:" entry. > These are my B2Bua routs: > //332606:36:42.505 PWL: [CID=0x0000] Appending route: <sip:5000@*> > sip:69.x.x.241:5060 > > 332606:36:42.505 PWL: [CID=0x0000] Appending route: > <sip:*@204.x.x.202:5060:5060> sip:sipx.sip.net:5060 > 332606:36:42.505 PWL: [CID=0x0000] Appending route: <sip:*@69.x.x.241:5060> > sip:204.x.x.202:5060;sip-trunk=true > 332606:36:42.506 PWL: [CID=0x0000] Appending route: <sip:*@sipx.sip.net:*> > sip:69.x.x.240:5060 > 332606:36:42.506 PWL: [CID=0x0000] Appending route: <sip:*@sipx.sip.net:*> > sip:spx.sip.net:5060 > 332606:36:42.506 PWL: [CID=0x0000] Appending route: <sip:*@sipx.sip.net:*> > sip:204.x.x.202:5060;sip-trunk=true > 332606:36:42.506 PWL: [CID=0x0000] Appending route: <sip:*@204.x.x.202:5060> > sip:204.x.x.202:5060;sip-trunk-true > > These are my Relay routs:: > 332606:36:42.508 PWL: [CID=0x0000] Appending route: <sip:sipx.sip.net:*> > sip:sipx.sip.net:5060;domain-sipx.sip.net;domain=sipx.sip.net > 332606:36:42.508 PWL: [CID=0x0000] Appending route: <sip:sipx.sip.net:*> > sip:69.x.x.240:5060;domain-sipx.sip.net > 332606:36:42.508 PWL: [CID=0x0000] Appending route: <sip:69.x.x.240> > sip:69.x.x.240:5060;domain-sipx.sip.net > 332606:36:42.515 PWL: [CID=0x0000] Appending route: <sip:773*@69.x.x.241> > sip:204.15.49.202;sip-trunk=true > 332606:36:42.515 PWL: [CID=0x0000] Appending route: <sip:???????@69.x.x.241> > sip:69.x.x.240 > 332606:36:42.516 PWL: [CID=0x0000] Appending route: <sip:773*@69.x.x.241> > sip:69.x.x.240 > 332606:36:42.516 PWL: [CID=0x0000] Appending route: <sip:*@69.x.x.241> > sip:69.x.x.240 > 332606:36:42.516 PWL: [CID=0x0000] Appending route: > <sip:+1??????????@204.x.x.202:5060> sip:204.x.x.202;sip-trunk=true > 332606:36:42.516 PWL: [CID=0x0000] Appending route: > <sip:773...@si...> sip:69.x.x.240 > 332606:36:42.516 PWL: [CID=0x0000] Appending route: > <sip:+1??????????@69.x.x.241> sip:204.x.x.202;sip-trunk=true > > *** THIS IS INBOUND FROM THE ITSP ***** > > I'm sorry to about the length of this part of the log. I'm not sure what to > leave out. > > 332606:38:20.916 PWL: [CID=0x0000] Using Iface: 69.x.x.241 to send to Dest: > 69.x.x.240 > 332606:38:25.715 DBG: [CID=0x073f] IST(3382899241) Timer I( 5000 ms ) > EXPIRED > 332606:38:25.715 DTL: [CID=0x073f] IST(3382899241) Event( Timer-I ) > Interval: 5000 > 332606:38:25.715 DTL: [CID=0x073f] IST(3382899241) Event(Final) > 332606:38:25.715 DTL: [CID=0x0000] *** REMOVED TRANSACTION *** > IST|a6bb915e484d621e@69.x.x.226|z9hG4bK8a8196a55c5e62fc|INVITE > 332606:38:25.716 DBG: [CID=0x0000] GC: First Stale Object SIPTransaction > 332606:38:25.716 DBG: [CID=0x073f] TRANSACTION: (IST) DESTROYED > 332606:38:25.716 DTL: [CID=0x073f] IST(3382899241) *** DESTROYED *** - > IST|a6bb915e484d621e@69.x.x.226|z9hG4bK8a8196a55c5e62fc|INVITE > 332606:38:25.865 DBG: [CID=0x073f] IST(3382899245) Timer I( 5000 ms ) > EXPIRED > 332606:38:25.865 DTL: [CID=0x073f] IST(3382899245) Event( Timer-I ) > Interval: 5000 > 332606:38:25.865 DTL: [CID=0x073f] IST(3382899245) Event(Final) > 332606:38:25.865 DTL: [CID=0x0000] *** REMOVED TRANSACTION *** > IST|a6bb915e484d621e@69.x.x.226|z9hG4bK-599b19e33762d717079ffaadf75fb191|INV > ITE > 332606:38:25.866 DBG: [CID=0x0000] GC: First Stale Object SIPTransaction > 332606:38:25.866 DBG: [CID=0x073f] TRANSACTION: (IST) DESTROYED > 332606:38:25.866 DTL: [CID=0x073f] IST(3382899245) *** DESTROYED *** - > IST|a6bb915e484d621e@69.x.x.226|z9hG4bK-599b19e33762d717079ffaadf75fb191|INV > ITE > 332606:38:37.604 INF: [CID=0x0d06] <<< INVITE > sip:7739050161@69.x.x.241:5060;npdi=yes;user=phone SIP/2.0 SRC: > 204.x.x.202:5060:UDP enc=0 bytes=885 > 332606:38:37.604 DBG: [CID=0x0d06] > 332606:38:37.604 DBG: [CID=0x0d06] INVITE > sip:7739050161@69.x.x.241:5060;npdi=yes;user=phone SIP/2.0 > 332606:38:37.604 DBG: [CID=0x0d06] From: > <sip:7733277006@204.x.x.202;user=phone>;tag=SD730h601-10000000-0-375494081 > 332606:38:37.604 DBG: [CID=0x0d06] To: > <sip:7739050161@69.x.x.241;user=phone> > 332606:38:37.604 DBG: [CID=0x0d06] Via: SIP/2.0/UDP > 204.x.x.202:5060;branch=z9hG4bKbbqp8q3068qhodo366s1.1 > 332606:38:37.604 DBG: [CID=0x0d06] CSeq: 1 INVITE > 332606:38:37.604 DBG: [CID=0x0d06] Call-ID: > SD730h601-289c86beb3f6565e4c594c95f195ab42-v3000i1 > 332606:38:37.604 DBG: [CID=0x0d06] Contact: > <sip:7733277006@204.x.x.202:5060;transport=udp> > 332606:38:37.604 DBG: [CID=0x0d06] Max-Forwards: 66 > 332606:38:37.604 DBG: [CID=0x0d06] Remote-Party-ID: > <sip:7733277006@192.168.35.70;user=phone>;party=calling;id-type=subscriber;p > rivacy=off;screen=yes > 332606:38:37.604 DBG: [CID=0x0d06] Content-Type: application/sdp > 332606:38:37.604 DBG: [CID=0x0d06] Content-Length: 285 > 332606:38:37.604 DBG: [CID=0x0d06] > 332606:38:37.604 DBG: [CID=0x0d06] v=0 > 332606:38:37.604 DBG: [CID=0x0d06] o=Sonus_UAC 22536 6223 IN IP4 204.x.x.10 > 332606:38:37.604 DBG: [CID=0x0d06] s=SIP Media Capabilities > 332606:38:37.604 DBG: [CID=0x0d06] c=IN IP4 204.x.x.10 > 332606:38:37.604 DBG: [CID=0x0d06] t=0 0 > 332606:38:37.604 DBG: [CID=0x0d06] m=audio 46112 RTP/AVP 18 0 8 100 > 332606:38:37.604 DBG: [CID=0x0d06] a=rtpmap:18 G729/8000 > 332606:38:37.604 DBG: [CID=0x0d06] a=rtpmap:0 PCMU/8000 > 332606:38:37.604 DBG: [CID=0x0d06] a=rtpmap:8 PCMA/8000 > 332606:38:37.604 DBG: [CID=0x0d06] a=rtpmap:100 telephone-event/8000 > 332606:38:37.604 DBG: [CID=0x0d06] a=fmtp:100 0-15 > 332606:38:37.604 DBG: [CID=0x0d06] a=sendrecv > 332606:38:37.604 DBG: [CID=0x0d06] a=maxptime:20 > 332606:38:37.604 DBG: [CID=0x0d06] > 332606:38:37.606 DBG: [CID=0x0d06] Finding transaction for INVITE > sip:7739050161@69.x.x.241:5060;npdi=yes;user=phone SIP/2.0 > 332606:38:37.606 DBG: [CID=0x0d06] Setting Transaction ID to > SD730h601-289c86beb3f6565e4c594c95f195ab42-v3000i1|z9hG4bKbbqp8q3068qhodo366 > s1.1|INVITE > 332606:38:37.606 DBG: [CID=0x0d06] > 332606:38:37.606 DBG: [CID=0x0d06] *** CREATING TRANSACTION (IST) *** > 332606:38:37.606 DBG: [CID=0x0d06] Message: INVITE > sip:7739050161@69.x.x.241:5060;npdi=yes;user=phone SIP/2.0 > 332606:38:37.606 DBG: [CID=0x0d06] Call-Id: > SD730h601-289c86beb3f6565e4c594c95f195ab42-v3000i1 > 332606:38:37.606 DBG: [CID=0x0d06] > 332606:38:37.607 DTL: [CID=0x0d06] IST(3382899246) *** CREATED *** - > IST|SD730h601-289c86beb3f6565e4c594c95f195ab42-v3000i1|z9hG4bKbbqp8q3068qhod > o366s1.1|INVITE > 332606:38:37.607 DTL: [CID=0x0d06] IST(3382899246) Event(SIPMessage) - > INVITE sip:7739050161@69.x.x.241:5060;npdi=yes;user=phone SIP/2.0 > 332606:38:37.608 DBG: [CID=0x0d06] TRANSACTION: (IST) INVITE > sip:7739050161@69.x.x.241:5060;npdi=yes;user=phone SIP/2.0 State: 0 > 332606:38:37.608 DBG: [CID=0x0d06] Event: SIPStack::Enqueue(INVITE > sip:7739050161@69.x.x.241:5060;npdi=yes;user=phone SIP/2.0) > 332606:38:37.609 DTL: [CID=0x0d06] IST(3382899246) > StateIdle->StateProceeding > 332606:38:37.610 INF: [CID=0x0d06] >>> SIP/2.0 100 Trying DST: > 204.x.x.202:5060:UDP SRC: 204.x.x.202:5060 enc=0 bytes=325 > 332606:38:37.611 DBG: [CID=0x0d06] > 332606:38:37.611 DBG: [CID=0x0d06] SIP/2.0 100 Trying > 332606:38:37.611 DBG: [CID=0x0d06] From: > <sip:7733277006@204.x.x.202;user=phone>;tag=SD730h601-10000000-0-375494081 > 332606:38:37.611 DBG: [CID=0x0d06] To: > <sip:7739050161@69.x.x.241;user=phone> > 332606:38:37.611 DBG: [CID=0x0d06] Via: SIP/2.0/UDP > 204.x.x.202:5060;branch=z9hG4bKbbqp8q3068qhodo366s1.1 > 332606:38:37.611 DBG: [CID=0x0d06] CSeq: 1 INVITE > 332606:38:37.611 DBG: [CID=0x0d06] Call-ID: > SD730h601-289c86beb3f6565e4c594c95f195ab42-v3000i1 > 332606:38:37.611 DBG: [CID=0x0d06] Content-Length: 0 > 332606:38:37.611 DBG: [CID=0x0d06] > 332606:38:37.611 DBG: [CID=0x0d06] > 332606:38:37.611 PWL: [CID=0x0000] Using Iface: 69.x.x.241 to send to Dest: > 204.x.x.202 > 332606:38:37.613 DBG: [CID=0x0d06] Event: B2BUserAgent::ProcessEvent( INVITE > sip:7739050161@69.x.x.241:5060;npdi=yes;user=phone SIP/2.0 ) > 332606:38:37.613 DTL: [CID=0x0d06] Event: ---> Inbound - INVITE > sip:7739050161@69.x.x.241:5060;npdi=yes;user=phone SIP/2.0 > 332606:38:37.614 DBG: [CID=0x0d06] Session CREATED > 332606:38:37.615 INF: [CID=0x0d06] *** CREATED (UAS) CALL *** > SD730h601-289c86beb3f6565e4c594c95f195ab42-v3000i1 > 332606:38:37.615 DBG: [CID=0x1163] Multidirectional Session CREATED > 332606:38:37.615 DBG: [CID=0x1163] B2BUAConnection Created 0x0x8682ce0 > 332606:38:37.615 DBG: [CID=0x1163] *** COUNTERS *** (Constructor)ICT=2 > NICT=0 IST=2 NIST=0 TIMERS=10 CALL=1 CONN=1 REG=1 RTP=0 QUEUE=0 CACHE=2 GC=5 > 332606:38:37.618 DBG: [CID=0x0d06] Finding transaction for SIP/2.0 407 Proxy > Authentication Required > 332606:38:37.618 DBG: [CID=0x0d06] Setting Transaction ID to > SD730h601-289c86beb3f6565e4c594c95f195ab42-v3000i1|z9hG4bKbbqp8q3068qhodo366 > s1.1|INVITE > 332606:38:37.618 DTL: [CID=0x0d06] Found > IST|SD730h601-289c86beb3f6565e4c594c95f195ab42-v3000i1|z9hG4bKbbqp8q3068qhod > o366s1.1|INVITE for SIP/2.0 407 Proxy Authentication Required > 332606:38:37.619 DTL: [CID=0x0d06] IST(3382899246) Event(SIPMessage) - > SIP/2.0 407 Proxy Authentication Required > 332606:38:37.619 DBG: [CID=0x0d06] TRANSACTION: (IST) SIP/2.0 407 Proxy > Authentication Required State: 2 > 332606:38:37.620 DTL: [CID=0x0d06] IST(3382899246) > StateProceeding->StateCompleted(SIP/2.0 407 Proxy Authentication Required) > 332606:38:37.620 DBG: [CID=0x0d06] IST(3382899246) Timer H( 32000 ms ) > STARTED > 332606:38:37.620 DBG: [CID=0x0d06] IST(3382899246) Timer G( 500 ms ) STARTED > 332606:38:37.620 DBG: [CID=0x0d06] Added ACK Transaction > SD730h601-289c86beb3f6565e4c594c95f195ab42-v3000i134345f6d64a6dc119cf6ede434 > 3ef63c|z9hG4bKbbqp8q3068qhodo366s1.1|ACK > 332606:38:37.623 INF: [CID=0x0d06] >>> SIP/2.0 407 Proxy Authentication > Required DST: 204.x.x.202:5060:UDP SRC: 69.x.x.241:5060 enc=0 bytes=607 > 332606:38:37.623 DBG: [CID=0x0d06] > 332606:38:37.623 DBG: [CID=0x0d06] SIP/2.0 407 Proxy Authentication > Required > 332606:38:37.623 DBG: [CID=0x0d06] From: > <sip:7733277006@204.x.x.202;user=phone>;tag=SD730h601-10000000-0-375494081 > 332606:38:37.623 DBG: [CID=0x0d06] To: > <sip:7739050161@69.x.x.241;user=phone>;tag=34345f6d64a6dc119cf6ede4343ef63c > 332606:38:37.623 DBG: [CID=0x0d06] Via: SIP/2.0/UDP > 204.x.x.202:5060;iid=2210;branch=z9hG4bKbbqp8q3068qhodo366s1.1;rport=5060;re > ceived=204.x.x.202 > 332606:38:37.623 DBG: [CID=0x0d06] CSeq: 1 INVITE > 332606:38:37.623 DBG: [CID=0x0d06] Call-ID: > SD730h601-289c86beb3f6565e4c594c95f195ab42-v3000i1 > 332606:38:37.623 DBG: [CID=0x0d06] Server: OpenSIPStack-1.1.7-18 > 332606:38:37.623 DBG: [CID=0x0d06] Proxy-Authenticate: Digest > realm=204.x.x.202, nonce="0cb83afd88d6268a838163668bf9fbaa", > opaque="1fb20e65f43c813a9b79a9d3d239ec07", algorithm=MD5 > 332606:38:37.623 DBG: [CID=0x0d06] Content-Length: 0 > 332606:38:37.623 DBG: [CID=0x0d06] > 332606:38:37.623 DBG: [CID=0x0d06] > 332606:38:37.623 PWL: [CID=0x0000] Using Iface: 69.x.x.241 to send to Dest: > 204.x.x.202 > 332606:38:37.683 INF: [CID=0x0d06] <<< ACK > sip:7739050161@69.x.x.241:5060;npdi=yes;user=phone SIP/2.0 SRC: > 204.x.x.202:5060:UDP enc=0 bytes=422 > 332606:38:37.683 DBG: [CID=0x0d06] > 332606:38:37.683 DBG: [CID=0x0d06] ACK > sip:7739050161@69.x.x.241:5060;npdi=yes;user=phone SIP/2.0 > 332606:38:37.683 DBG: [CID=0x0d06] From: > <sip:7733277006@204.x.x.202;user=phone>;tag=SD730h601-10000000-0-375494081 > 332606:38:37.683 DBG: [CID=0x0d06] To: > <sip:7739050161@69.x.x.241;user=phone>;tag=34345f6d64a6dc119cf6ede4343ef63c > 332606:38:37.683 DBG: [CID=0x0d06] Via: SIP/2.0/UDP > 204.x.x.202:5060;branch=z9hG4bKbbqp8q3068qhodo366s1.1 > 332606:38:37.683 DBG: [CID=0x0d06] CSeq: 1 ACK > 332606:38:37.683 DBG: [CID=0x0d06] Call-ID: > SD730h601-289c86beb3f6565e4c594c95f195ab42-v3000i1 > 332606:38:37.683 DBG: [CID=0x0d06] Max-Forwards: 66 > 332606:38:37.683 DBG: [CID=0x0d06] Content-Length: 0 > 332606:38:37.683 DBG: [CID=0x0d06] > 332606:38:37.683 DBG: [CID=0x0d06] > 332606:38:37.684 DBG: [CID=0x0d06] Finding transaction for ACK > sip:7739050161@69.x.x.241:5060;npdi=yes;user=phone SIP/2.0 > 332606:38:37.685 DBG: [CID=0x0d06] Found ACK Transaction > SD730h601-289c86beb3f6565e4c594c95f195ab42-v3000i134345f6d64a6dc119cf6ede434 > 3ef63c|z9hG4bKbbqp8q3068qhodo366s1.1|ACK > 332606:38:37.685 DTL: [CID=0x0d06] IST(3382899246) Event(SIPMessage) - ACK > sip:7739050161@69.x.x.241:5060;npdi=yes;user=phone SIP/2.0 > 332606:38:37.685 DBG: [CID=0x0d06] TRANSACTION: (IST) ACK > sip:7739050161@69.x.x.241:5060;npdi=yes;user=phone SIP/2.0 State: 3 > 332606:38:37.685 DBG: [CID=0x0d06] IST(3382899246) Timer G STOPPED > 332606:38:37.685 DBG: [CID=0x0d06] IST(3382899246) Timer H STOPPED > 332606:38:37.686 DTL: [CID=0x0d06] IST(3382899246) > StateProceeding->StateConfirmed > 332606:38:37.686 DBG: [CID=0x0d06] IST(3382899246) Timer I( 5000 ms ) > STARTED > 332606:38:42.674 DBG: [CID=0x0d06] IST(3382899246) Timer I( 5000 ms ) > EXPIRED > 332606:38:42.675 DTL: [CID=0x0d06] IST(3382899246) Event( Timer-I ) > Interval: 5000 > 332606:38:42.675 DTL: [CID=0x0d06] IST(3382899246) Event(Final) > 332606:38:42.675 DTL: [CID=0x0000] *** REMOVED TRANSACTION *** > IST|SD730h601-289c86beb3f6565e4c594c95f195ab42-v3000i1|z9hG4bKbbqp8q3068qhod > o366s1.1|INVITE > 332606:38:42.675 DBG: [CID=0x0000] GC: First Stale Object SIPTransaction > 332606:38:42.675 DBG: [CID=0x0d06] TRANSACTION: (IST) DESTROYED > 332606:38:42.676 DTL: [CID=0x0d06] IST(3382899246) *** DESTROYED *** - > IST|SD730h601-289c86beb3f6565e4c594c95f195ab42-v3000i1|z9hG4bKbbqp8q3068qhod > o366s1.1|INVITE > 332606:38:52.675 DBG: [CID=0x073f] ICT(3382899242) Timer D( 32000 ms ) > EXPIRED > 332606:38:52.675 DTL: [CID=0x073f] ICT(3382899242) Event( Timer-D ) > Interval: 32000 > 332606:38:52.675 DTL: [CID=0x073f] ICT(3382899242) Event(Final) > 332606:38:52.676 DTL: [CID=0x0000] *** REMOVED TRANSACTION *** > ICT|a6bb915e484d621e@69.x.x.226|z9hG4bKee96386364a6dc119cf6ede4343ef63c-8f2d > 8a53abaa85d7169af0d382bec7b0|INVITE > 332606:38:52.676 DBG: [CID=0x0000] GC: First Stale Object SIPTransaction > 332606:38:52.676 DBG: [CID=0x073f] TRANSACTION: (ICT) DESTROYED > 332606:38:52.676 DTL: [CID=0x073f] ICT(3382899242) *** DESTROYED *** - > ICT|a6bb915e484d621e@69.x.x.226|z9hG4bKee96386364a6dc119cf6ede4343ef63c-8f2d > 8a53abaa85d7169af0d382bec7b0|INVITE > 332606:38:52.866 DBG: [CID=0x073f] ICT(3382899244) Timer D( 32000 ms ) > EXPIRED > 332606:38:52.866 DTL: [CID=0x073f] ICT(3382899244) Event( Timer-D ) > Interval: 32000 > 332606:38:52.866 DTL: [CID=0x073f] ICT(3382899244) Event(Final) > 332606:38:52.866 DTL: [CID=0x0000] *** REMOVED TRANSACTION *** > ICT|a6bb915e484d621e@69.x.x.226|z9hG4bKf46f4f6364a6dc119cf6ede4343ef63c-48dc > 73fd0b41ca0fd2415556850654fc|INVITE > 332606:38:52.867 DBG: [CID=0x0000] GC: First Stale Object SIPTransaction > 332606:38:52.867 DBG: [CID=0x073f] TRANSACTION: (ICT) DESTROYED > 332606:38:52.867 DTL: [CID=0x073f] ICT(3382899244) *** DESTROYED *** - > ICT|a6bb915e484d621e@69.x.x.226|z9hG4bKf46f4f6364a6dc119cf6ede4343ef63c-48dc > 73fd0b41ca0fd2415556850654fc|INVITE > 332606:39:09.617 DTL: [CID=0x06cb] *** QUEUED FOR DELETION *** SIPSession: > SD730h601-289c86beb3f6565e4c594c95f195ab42-v3000i1 > 332606:39:09.617 DTL: [CID=0x06cb] *** QUEUED FOR DELETION *** SIPSession: > SD730h601-289c86beb3f6565e4c594c95f195ab42-v3000i1-connection > 332606:39:09.617 DBG: [CID=0x0000] GC: First Stale Object SIPSession > 332606:39:43.132 DBG: [CID=0x0000] GC: First Stale Object B2BUACall > 332606:39:43.132 DBG: [CID=0x1163] B2BUAConnection Destroyed 0x0x8682ce0 > 332606:39:43.132 INF: [CID=0x1163] *** COUNTERS *** ICT=0 NICT=0 IST=1 > NIST=0 TIMERS=1 CALL=1 CONN=0 REG=1 RTP=0 QUEUE=1 CACHE=2 GC=4 > 332606:39:43.132 DBG: [CID=0x0d06] CONNECTION: Session DESTROYED > 332606:39:43.132 INF: [CID=0x0d06] *** DESTROYED CALL *** > SD730h601-289c86beb3f6565e4c594c95f195ab42-v3000i1 > 332606:39:43.132 DBG: [CID=0x0d06] CALL: (inbound) : Session DESTROYED > > > > > |
|
From: Joegen E. B. <joe...@gm...> - 2007-12-12 02:27:52
|
Hi Jacob, Thanks for the packet capture but its not very helpful in investigating packet format problems. We need to see the actual state of the packet in the wire. You can send me the capture offlist if you are concerned about the privacy of your network. It will be for my eyes only given that you will trust my intent. Joegen Jacob Waterman wrote: > Hi Ilian, Hi Joegen, > > Thanks for your responses! Here is the full INVITE message and the > corresponding "100: Trying" response. > > No. Time Source Destination Protocol > Info > 885 99.833033 Rem.Addr.90.138 Loc.Addr.1.35 SIP/SDP > Request: INVITE sip:Des...@Lo...dr.1.35:5060, with session description > > Frame 885 (941 bytes on wire, 941 bytes captured) > Ethernet II, Src: ZyxelCom_7f:5b:cd (00:13:49:7f:5b:cd), Dst: > CompalCo_d9:53:e9 (00:16:d4:d9:53:e9) > Internet Protocol, Src: Rem.Addr.90.138 (Rem.Addr.90.138), Dst: > Loc.Addr.1.35 (Loc.Addr.1.35) > User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) > Session Initiation Protocol > Request-Line: INVITE sip:Des...@Lo...dr.1.35:5060 SIP/2.0 > Method: INVITE > [Resent Packet: False] > Message Header > Via: SIP/2.0/UDP Rem.Addr.90.138:5060 > Via: SIP/2.0/UDP Rem.Addr.90.141 > :5060;branch=z9hG4bK2299f16cbf64a411fd8a1986 > Max-Forwards: 69 > From: <sip:Ori...@Re...dr.90.138>;tag=2299f16cbfc5e3b2fd8a1998 > To: <sip:Des...@Re...dr.90.138> > Call-ID: 229...@Re...dr.90.141 > CSeq: 1 INVITE > User-agent: SysMaster VoIP Gateway v1.2.0 > Contact: <sip:sm...@Re...dr.90.138:5060> > Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,INFO,REFER,SUBSCRIBE > Content-Type: application/sdp > Content-Length: 342 > Message body > Session Description Protocol > Session Description Protocol Version (v): 0 > Owner/Creator, Session Id (o): - 223217380501517 1 IN IP4 > Rem.Addr.90.138 > Session Name (s): - > Connection Information (c): IN IP4 Rem.Addr.90.138 > Time Description, active time (t): 0 0 > Media Description, name and address (m): audio 22614 RTP/AVP 0 8 > 18 4 101 > Media Attribute (a): rtpmap:0 PCMU/8000 > Media Attribute (a): rtpmap:8 PCMA/8000 > Media Attribute (a): rtpmap:18 G729/8000 > Media Attribute (a): fmtp:18 annexb=no > Media Attribute (a): rtpmap:4 G723/8000 > Media Attribute (a): rtpmap:101 telephone-event/8000 > Media Attribute (a): fmtp:101 0-16 > Media Description, name and address (m): video 22616 RTP/AVP 102 > Media Attribute (a): rtpmap:102 H263-1998/90000 > > No. Time Source Destination Protocol > Info > 886 99.856567 Loc.Addr.1.35 Rem.Addr.90.138 SIP > Status: 100 Trying > > Frame 886 (375 bytes on wire, 375 bytes captured) > Ethernet II, Src: CompalCo_d9:53:e9 (00:16:d4:d9:53:e9), Dst: > ZyxelCom_7f:5b:cd (00:13:49:7f:5b:cd) > Internet Protocol, Src: Loc.Addr.1.35 (Loc.Addr.1.35), Dst: Rem.Addr.90.138( > Rem.Addr.90.138) > User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) > Session Initiation Protocol > Status-Line: SIP/2.0 100 Trying > Status-Code: 100 > [Resent Packet: False] > Message Header > From: <sip:Ori...@Re...dr.90.138>;tag=2299f16cbfc5e3b2fd8a1998 > To: <sip:Des...@Re...dr.90.138> > Via: SIP/2.0/UDP Rem.Addr.90.138:5060 > Via: SIP/2.0/UDP Rem.Addr.90.141 > :5060;branch=z9hG4bK2299f16cbf64a411fd8a1986 > CSeq: 1 INVITE > Call-ID: 229...@Re...dr.90.141 > Content-Length: 0 > > Thanks again! > > Best regards, > > Jacob > > On Dec 7, 2007 5:34 AM, Ilian Jeri C. Pinzon <ip...@so...> > wrote: > > >> Jacob, >> >> That's strange. Can you post the entire SIP message and not just the >> compressed form? That will be very helpful. >> >> - Ilian >> >> Jacob Waterman wrote: >> >>> Hi, >>> >>> I am using the SoftPhoneInterface class as a basis for a softphone >>> implementation. I am able to register and make calls just fine, but when >>> >> it >> >>> comes to receiving calls, even after having registered with my SIP >>> provider's server, no event is triggered in the SoftPhoneInterface class >>> (Event_IncomingCall), and so I am unable to answer a call. >>> >>> Using Wireshark, however, I see that the INVITE request is being >>> >> received by >> >>> my SIP provider's server, but all that is returned from my end, >>> automatically, is a "Status: 100 Trying" message, and then nothing else >>> happens. >>> >>> Here is my Wireshark protocol: >>> >>> No. Time Source Destination Protocol >>> Info >>> >>> *Registering* >>> 264 19.624891 Local.Address.1.35 Remote.Address.90.138 >>> SIP Request: REGISTER sip:Remote.Address.90.138 >>> 268 19.853526 Remote.Address.90.138 Local.Address.1.35 >>> SIP Status: 407 Proxy Authentication Required (1 bindings) >>> 270 19.895982 Local.Address.1.35 Remote.Address.90.138 >>> SIP Request: REGISTER sip:Remote.Address.90.138 >>> 271 20.099519 Local.Address.1.35 Remote.Address.90.138 >>> SIP Request: REGISTER sip:Remote.Address.90.138 >>> 272 20.120145 Remote.Address.90.138 Local.Address.1.35 >>> SIP Status: 200 OK (1 bindings) >>> 273 20.321326 Remote.Address.90.138 Local.Address.1.35 >>> SIP Status: 200 OK (1 bindings) >>> >>> *Making a call - Successful* >>> 4632 334.556501 Local.Address.1.35 Remote.Address.90.138 >>> SIP/SDP Request: INVITE sip:Dia...@Re...dress.90.138, with >>> session description >>> 4635 334.634657 Local.Address.1.35 Remote.Address.90.138 >>> SIP/SDP Request: INVITE sip:Dia...@Re...dress.90.138, with >>> session description >>> 4639 334.785283 Remote.Address.90.138 Local.Address.1.35 >>> SIP Status: 100 Trying >>> 4640 334.801885 Remote.Address.90.138 Local.Address.1.35 >>> SIP/SDP Status: 200 OK, with session description >>> 4642 334.866339 Remote.Address.90.138 Local.Address.1.35 >>> SIP/SDP Status: 200 OK, with session description >>> 4652 335.302885 Remote.Address.90.138 Local.Address.1.35 >>> SIP/SDP Status: 200 OK, with session description >>> 4660 336.302943 Remote.Address.90.138 Local.Address.1.35 >>> SIP/SDP Status: 200 OK, with session description >>> 4691 338.348935 Remote.Address.90.138 Local.Address.1.35 >>> SIP/SDP Status: 200 OK, with session description >>> 4750 342.363792 Remote.Address.90.138 Local.Address.1.35 >>> SIP/SDP Status: 200 OK, with session description >>> 4795 345.240244 Local.Address.1.35 Remote.Address.90.138 >>> SIP Request: ACK sip:Dia...@Re...dress.90.138:5060 >>> 6852 367.034986 Local.Address.1.35 Remote.Address.90.138 >>> SIP Request: BYE sip:Dia...@Re...dress.90.138:5060 >>> 6859 367.139967 Local.Address.1.35 Remote.Address.90.138 >>> SIP Request: BYE sip:Dia...@Re...dress.90.138:5060 >>> 6860 367.243944 Remote.Address.90.138 Local.Address.1.35 >>> SIP Status: 200 OK >>> 6862 367.346488 Remote.Address.90.138 Local.Address.1.35 >>> SIP Status: 200 OK >>> >>> *Receiving a call - "Status: 100 Trying"* >>> 7104 386.368960 Remote.Address.90.138 Local.Address.1.35 >>> SIP/SDP Request: INVITE sip:MyN...@Lo...dress.1.35:5060, with >>> >> session >> >>> description >>> 7105 386.397928 Local.Address.1.35 Remote.Address.90.138 >>> SIP Status: 100 Trying >>> >>> *Unregistering* >>> 7653 425.373636 Local.Address.1.35 Remote.Address.90.138 >>> SIP Request: REGISTER sip:Remote.Address.90.138 (remove all >>> bindings) >>> 7657 425.606269 Remote.Address.90.138 Local.Address.1.35 >>> SIP Status: 200 OK (0 bindings) >>> >>> Any ideas as to why this might be the case would be greatly appreciated. >>> >>> Thanks! >>> >>> Best regards, >>> >>> Jacob >>> >>> >> ------------------------------------------------------------------------- >> >>> SF.Net email is sponsored by: The Future of Linux Business White Paper >>> from Novell. From the desktop to the data center, Linux is going >>> mainstream. Let it simplify your IT future. >>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >>> _______________________________________________ >>> opensipstack-devel mailing list >>> ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >>> >>> >>> >> ------------------------------------------------------------------------- >> SF.Net email is sponsored by: >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php >> _______________________________________________ >> opensipstack-devel mailing list >> ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >> >> > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > > |
|
From: Joegen E. B. <joe...@gm...> - 2007-12-12 02:12:44
|
You would probably be able to reach at least up to enum, osbc... But you might not be able to failover to a sip-trunk right now because the SIP-Trunk is handled differently than any other route. I am not very sure. Have you tried [sip:*] enum:nu...@e1..., sip:numkber@osbc2, sip:number@your_itsp;sip-trunk=true ? Joegen Dinesh Dialani wrote: > Hi Joegen, > > I am using Sip Trunk as well as Enum capabilities of OpenSBC. I have a > question. > > I want that whenever an outbound call is established, it should first > search enum records corresponding to phone number dialed and if found > make a call directly. > > But it may happen that the other party also has an OpenSBC installed > and it has put IP of my OpenSBC in List of Blocked IP's, so the other > party will send a 403 Forbidden message. > > Now two situation can arise: > 1. The call should be disconnected. > 2. The call should now be made using Sip Trunk facilities of OpenSBC. > > I want to know how can I handle the situation in which if a call is > rejected by other party through Enum then the call should be > established through Sip Trunk. > > > > Do an Enum lookup > UA----->OpenSBC 1 > ----------------------------> Enum Server > > Enum lookup is successful > <---------------------------- > return a Sip URI > > > > > OpenSBC 1 Call directly to other party > > -----------------------------> OpenSBC 2 > > > Blocked IP of OpensBC 1 > > <----------------------------- > Sends a 403 Forbidden message > > > Establish a call using Sip > Trunk > > ------------------------------> > > > Call is established > successfully > > <------------------------------- > > > > Regards, > > Dinesh > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ------------------------------------------------------------------------ > > _______________________________________________ > Opensipstack-osbcdevel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-osbcdevel > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.503 / Virus Database: 269.17.0/1180 - Release Date: 12/10/2007 2:51 PM > |
18 messages has been excluded from this view by a project administrator.
