opensipstack-devel Mailing List for OpenSIPStack (Page 34)
Brought to you by:
joegenbaclor
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: Joegen E. B. <joe...@gm...> - 2007-12-12 02:06:28
|
Julian F. Tasis, III wrote: > Good day, > > Hi guys just experienced when a sip message arrives and it contains a header field with no value just \r\n the behavior of the stack will be different causing it to send response sip messages that contains double \r\n. > Can you send me a pcap off list? > Just like to ask how conferencing work in voip. I base my code on SBCIVRHandler. I wanted to connect 2 to 3 person talking to each other. Can someone teach me the proper sip signalling for this type of calls. > Here is the list of RFC's you should read http://www.opensipstack.org/links_rfc.html#6. Implementing this RFC's is only half of the requirements for you to have your own Conference Server, you still need to have the ability for your servers to decode/mix/transcode the streams. HTH > Humble Regards, > Julian > ------------------------------------------------------------------------- > 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:03:55
|
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. |
From: Whit T. <de...@wh...> - 2007-12-11 17:30:23
|
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 |
From: <sa...@ER...> - 2007-12-11 16:35:21
|
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 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: Jacob W. <wat...@go...> - 2007-12-11 13:55:32
|
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 > |
From: Julian F. T. I. <jf...@id...> - 2007-12-11 02:22:11
|
Good day, Hi guys just experienced when a sip message arrives and it contains a = header field with no value just \r\n the behavior of the stack will be = different causing it to send response sip messages that contains double = \r\n. Just like to ask how conferencing work in voip. I base my code on = SBCIVRHandler. I wanted to connect 2 to 3 person talking to each other. = Can someone teach me the proper sip signalling for this type of calls.=20 Humble Regards, Julian |
From: Joegen E. B. <joe...@gm...> - 2007-12-10 01:40:52
|
It seems like OpenSIPStack is not able to parse the INVITe and is getting discarded. Would you be able to send a capture of this INVITE? 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 > > > |
From: Joegen E. B. <joe...@gm...> - 2007-12-10 01:39:42
|
Thanks for the patch... I will include it in the next generations of patches. H.Kropf wrote: > My "OSSApplication::CreateUserFolder()" implementation > > Sorry, NOT TESTED > > //============================================================= > // OSSApplication.h > //============================================================= > > class OSSApplication : public OSSApplicationAncestor > { > ... > > public: > static const OString GetUserHomeDir(); > static const OString CreateUserFolder(const char* dir_name); > > ... > }; > > //============================================================= > // OSSApplication.cxx > //============================================================= > > #ifdef _WIN32_WCE > #include <shlobj.h> > #include <direct.h> > #else > #include <stdlib.h> > #endif > > const OString OSSApplication::GetUserHomeDir() > { > #ifdef _WIN32_WCE // === Win32 ========================== > > char dir[MAX_PATH]; > SecureZeroMemory(dir, sizeof(dir)); > > //Minimal OS: Win2k, WinNT 4.0 + IE 4.0, Win98, Win95 + IE 4.0 > // require import lib "shell32.lib" > //if( SHGetSpecialFolderPathA(NULL, (LPSTR)dir, CSIDL_APPDATA, TRUE) ) > > //Minimal OS: > //Win95+IE 5.0, Win98+IE 5.0, Win98SE, WinNT 4.0+IE 5.0, WinNT 4.0 SP4 > if( SUCCEEDED(SHGetFolderPathA(NULL, CSIDL_APPDATA | CSIDL_FLAG_CREATE, > NULL, 0, (LPSTR)dir)) ) > return OString( (LPCSTR)dir ); > else > return OString(); > > #else // === POSIX ========================== > > char* dir = NULL; > dir = getenv("HOME"); > if(dir) > return OString( (const char*)dir ); > else > return OString(); > > #endif > } > > //------------------------------------------------------------------ > > const OString OSSApplication::CreateUserFolder(const char* dir_name) > { > OString result_path = GetUserHomeDir(); > if(result_path.IsEmpty) > result_path = PProcess::Current().GetFile().GetDirectory(); > > #ifdef _WIN32_WCE // === Win32 ========================== > if( result_path.Right(1) != "\\") result_path += "\\"; > #else // === POSIX ========================== > if( result_path.Right(1) != "/") result_path += "/"; > #endif > > if(dir_name) > { > result_path += dir_name; > result_path.Trim(); > _mkdir(result_path); > } > > // TO-DO : need check results of "_mkdir" command > > return result_path; > } > > > > Joegen E. Baclor wrote: > >> Good suggestion. I think the best place to put this code is as a static >> method in OSSApplication. Something like >> OSSApplication::CreateUserFolder() with similar behavior in linux and >> window. For linux, it would be create in the $(HOME) directory. For >> windows, it would be Document and Settings. Aside from the registry >> folder, we have the logs and CALEA folders that are also dynamically >> created by OpenSBC. A central function would benefit these two as >> well. Would you be able to patch OSSApplicaiton with this method and >> behave the same way in linux and windows? I will be glad to add it as >> your contribution. >> >> H.Kropf wrote: >> >> >>> I suggest to use the following code:for Win NT / 2k / XP >>> >>> //-------------------------------------------------------------------------- >>> // uses c:\Documents and Settings\[User]\OSS\registry\ >>> //-------------------------------------------------------------------------- >>> char dir[MAX_PATH+1]; >>> SecureZeroMemory(dir, sizeof(dir)); >>> >>> SHGetSpecialFolderPath(NULL, (LPSTR)dir, CSIDL_APPDATA, TRUE); >>> >>> PathAppend(dir, "OSS"); >>> if( !PathFileExists( dir ) ) _mkdir((LPCSTR)dir); >>> PathAppend(dir, "registry"); >>> if( !PathFileExists( pb_path ) ) _mkdir(dir); >>> //-------------------------------------------------------------------------- >>> >>> >>> instead of >>> >>> //-------------------------------------------------------------------------- >>> // uses c:\Program Files\[program name]\registry\ . Whether the user >>> has the rights to create this folder here? >>> //-------------------------------------------------------------------------- >>> OString dir = PProcess::Current().GetFile().GetDirectory() + "registry"; >>> if( !PFile::Exists( dir.c_str() ) ) >>> PDirectory::Create( dir.c_str() ); >>> //-------------------------------------------------------------------------- >>> >>> in >>> >>> //======== RegisterSessionManager.cxx ======== >>> >>> RegistrationDatabase::RegistrationDatabase() >>> { >>> #if HAS_CPPSQLITE >>> m_HasContactRecovery = PrepareContactRecoveryDB( >>> "ContactRecovery.sqlite" ); >>> #else >>> m_HasContactRecovery = TRUE; >>> OString dir = PProcess::Current().GetFile().GetDirectory() + "registry"; >>> if( !PFile::Exists( dir.c_str() ) ) >>> PDirectory::Create( dir.c_str() ); >>> m_RegRecoveryDIR = dir.c_str(); >>> #endif >>> } >>> >>> > > > ------------------------------------------------------------------------- > 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 > > > |
From: Joegen E. B. <joe...@gm...> - 2007-12-10 01:34:38
|
sales@ER wrote: > Hi > > Is there a doc for SIP Trunk? When and why to use it and relationship to > B2Bua etc...? > > Warren Kreckler > > > Unfortunately not. SIP Trunking is very new in the arsenal and would be hard to use without a more advanced configuration module. For now, there is a temporary provision to test it using the config pages via XML. I have attached the annoucement i've sent last October 17, 2007 To tell OpenSBC that the call should be processed by the SIP Trunk your B2BUARoute entry shouold include a sip-trunk paramameter. Example: [sip:1212*] sip:mytrunkprovider.com <http://mytrunkprovider.com>;sip-trunk=true ------- Hi, SIP Trunking is not prime time yet but you may already try it using the latest CVS copy of OpenSBC/OpenSIPStack. To Enable Trunking, you must provide an XML configuration in "SIP Trunk Config". Below is a template XML config. In this sample config, sip:win32.opensipstack.org is assumed to be the internal domain of OpenSBC while sip:opteron.opensipstack.org is the domain of your SIP Provider. [SIPTrunk] * trunk-name: This is the unique name OpenSBC will use to identify you SIP Trunk * route-set: This is the DNS resolvable domain or IP address of your trunk provider * sip-domain: This is the SIP Domain used as the host part of the To and From URIs * expires: Global expire interval for trunk registrations in seconds [Trunk-Accounts] * account - An instance of a virtual UA that will register to the Trunk Provider domain ** user-name - The user part of the From-URI ** auth-user-name - User name used for Authorization and Authentication ** auth-password - Password used for Authorization and Authentication ** inbound-route - URI specifying the identity of the UA in the internal domain ** expires - If set, this will be the expires used when the virtual UA registers to the Trunk Provider [Transient-Accounts] - Transient accounts are similar to normal Trunk-Account in terms of the parameters. The only difference is that they are also meant to be shared (in round robin fashion) by calls which are not defined in the normal trunk-accounts. This is normally used if you have a few accounts with a Trunk Provider and is meant to be shared by all your external users. ------------------------START OF XML CONFIG---------------------------------- <root> <siptrunk trunk-name="opteron.opensipstack.org" route-set="opteron.opensipstack.org" sip-domain="opteron.opensipstack.org" expires="10"> <trunk-accounts> <account user-name="1001" auth-user-name="1001" auth-password="1001" inbound-route="sip:90...@wi..." expires="3600" /> <account user-name="1002" auth-user-name="1002" auth-password="1002" inbound-route="sip:90...@wi..." expires="3600" /> <account user-name="1003" auth-user-name="1003" auth-password="1003" inbound-route="sip:90...@wi..." expires="3600" /> </trunk-accounts> <transient-accounts> <account user-name="1001" auth-user-name="1001" auth-password="1001" inbound-route="sip:90...@wi..." /> <account user-name="1002" auth-user-name="1002" auth-password="1002" inbound-route="sip:90...@wi..." /> <account user-name="1003" auth-user-name="1003" auth-password="1003" inbound-route="sip:90...@wi..." /> </transient-accounts> </siptrunk> </root> Joegen |
From: Joegen E. B. <joe...@gm...> - 2007-12-10 01:22:07
|
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: <sa...@ER...> - 2007-12-08 23:39:15
|
Hi Can some one help me understand the relationship between B2Bua, Sip Trunk and Upper Registration Routes. With some examples lets assume: SBC 200.10.10.5 Sip Server 200.10.10.10 Lan 200.10.10.0/24 ip Phone 200.10.10.101 ITSP 100.10.10.10 Is there a round robin hand-off relationship or conflick between B2Bua and Sip Trunk. Im getting a error "OpenSBC transport Status" in the Web Admin tool In the Sip Trunk i have 100.10.10.10 == ITSP SIP TRUNK: 200.10.10.10 :5060 error Address Already in use **** Failed ****** Well there ever be workig How To doc? Gaurav Kheterpal <gkh...@is...> sent in a pcap to the list but it was removed. 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://sourceforge.net/services/buy/index.php _______________________________________________ opensipstack-devel mailing list ope...@li... https://lists.sourceforge.net/lists/listinfo/opensipstack-devel |
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 |
From: <sa...@ER...> - 2007-12-08 23:34:23
|
Hi Can some one help me understand the relationship between B2Bua, Sip Trunk and Upper Registration Routes. With some examples lets assume: SBC 200.10.10.5 Sip Server 200.10.10.10 Lan 200.10.10.0/24 ip Phone 200.10.10.101 ITSP 100.10.10.10 Is there a round robin hand-off relationship or conflick between B2Bua and Sip Trunk. Im getting a error "OpenSBC transport Status" in the Web Admin tool In the Sip Trunk i have 100.10.10.10 == ITSP SIP TRUNK: 200.10.10.10 :5060 error Address Already in use **** Failed ****** Well there ever be workig How To doc? Gaurav Kheterpal <gkh...@is...> sent in a pcap to the list but it was removed. Warren Kreckler |
From: <sa...@ER...> - 2007-12-08 19:09:46
|
Hi Is there a doc for SIP Trunk? When and why to use it and relationship to B2Bua etc...? Warren Kreckler |
From: <sa...@ER...> - 2007-12-07 16:51:34
|
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. 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. 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. 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: Joegen E. B. <joe...@gm...> - 2007-12-07 06:08:23
|
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 > > > |
From: Ilian J. C. P. <ip...@so...> - 2007-12-07 04:34:58
|
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 > > |
From: Jacob W. <wat...@go...> - 2007-12-06 14:33:01
|
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 |
From: <sa...@ER...> - 2007-12-06 03:16:31
|
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 |
From: <sa...@ER...> - 2007-12-06 03:06:23
|
Hi I found the solution: Background: In our testing we are using public addressing to allow remove developers to gain easy access to both sipx and opensbc. The 2nd NIC whicd had a private address and was activated was not used but we were wrong opensbc see's the card alive and wants to use it, event thought we set the interface to only use the 1st NIC. Not thinking it was not in play we forgot about it. Problem: We were not able to connect to :9999 to local box but no able to from local or remote networks Solution: Disabled the 2nd NIC card. Warren Kreckler ----- Original Message ----- From: "jo...@op..." <joe...@gm...> To: <ope...@li...> Sent: Saturday, December 01, 2007 6:38 PM Subject: Re: [OpenSIPStack] Web Interface Question > I am not very sure if I get your question right but the web interface of > OpenSBC is accessible from any computer in the network via HTTP port > 9999 of the IP address of where OpenSBC is installed > > http://opensbc_ip_address:9999 > > Please give more information if this is not what you meant. > > Joegen > > sales@ER wrote: > > Hi > > > > How do i chage opensbc so i can use the web interface from any computer on > > or off the network > > > > 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: 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 |
From: <sa...@ER...> - 2007-12-06 02:54:14
|
Hi How do you code a rule to replace the From URI. from a host name to an ipaddr? Warren Kreckler |
From: H.Kropf <mai...@gl...> - 2007-12-05 14:16:22
|
My "OSSApplication::CreateUserFolder()" implementation Sorry, NOT TESTED //============================================================= // OSSApplication.h //============================================================= class OSSApplication : public OSSApplicationAncestor { ... public: static const OString GetUserHomeDir(); static const OString CreateUserFolder(const char* dir_name); ... }; //============================================================= // OSSApplication.cxx //============================================================= #ifdef _WIN32_WCE #include <shlobj.h> #include <direct.h> #else #include <stdlib.h> #endif const OString OSSApplication::GetUserHomeDir() { #ifdef _WIN32_WCE // === Win32 ========================== char dir[MAX_PATH]; SecureZeroMemory(dir, sizeof(dir)); //Minimal OS: Win2k, WinNT 4.0 + IE 4.0, Win98, Win95 + IE 4.0 // require import lib "shell32.lib" //if( SHGetSpecialFolderPathA(NULL, (LPSTR)dir, CSIDL_APPDATA, TRUE) ) //Minimal OS: //Win95+IE 5.0, Win98+IE 5.0, Win98SE, WinNT 4.0+IE 5.0, WinNT 4.0 SP4 if( SUCCEEDED(SHGetFolderPathA(NULL, CSIDL_APPDATA | CSIDL_FLAG_CREATE, NULL, 0, (LPSTR)dir)) ) return OString( (LPCSTR)dir ); else return OString(); #else // === POSIX ========================== char* dir = NULL; dir = getenv("HOME"); if(dir) return OString( (const char*)dir ); else return OString(); #endif } //------------------------------------------------------------------ const OString OSSApplication::CreateUserFolder(const char* dir_name) { OString result_path = GetUserHomeDir(); if(result_path.IsEmpty) result_path = PProcess::Current().GetFile().GetDirectory(); #ifdef _WIN32_WCE // === Win32 ========================== if( result_path.Right(1) != "\\") result_path += "\\"; #else // === POSIX ========================== if( result_path.Right(1) != "/") result_path += "/"; #endif if(dir_name) { result_path += dir_name; result_path.Trim(); _mkdir(result_path); } // TO-DO : need check results of "_mkdir" command return result_path; } Joegen E. Baclor wrote: > Good suggestion. I think the best place to put this code is as a static > method in OSSApplication. Something like > OSSApplication::CreateUserFolder() with similar behavior in linux and > window. For linux, it would be create in the $(HOME) directory. For > windows, it would be Document and Settings. Aside from the registry > folder, we have the logs and CALEA folders that are also dynamically > created by OpenSBC. A central function would benefit these two as > well. Would you be able to patch OSSApplicaiton with this method and > behave the same way in linux and windows? I will be glad to add it as > your contribution. > > H.Kropf wrote: > >> I suggest to use the following code:for Win NT / 2k / XP >> >> //-------------------------------------------------------------------------- >> // uses c:\Documents and Settings\[User]\OSS\registry\ >> //-------------------------------------------------------------------------- >> char dir[MAX_PATH+1]; >> SecureZeroMemory(dir, sizeof(dir)); >> >> SHGetSpecialFolderPath(NULL, (LPSTR)dir, CSIDL_APPDATA, TRUE); >> >> PathAppend(dir, "OSS"); >> if( !PathFileExists( dir ) ) _mkdir((LPCSTR)dir); >> PathAppend(dir, "registry"); >> if( !PathFileExists( pb_path ) ) _mkdir(dir); >> //-------------------------------------------------------------------------- >> >> >> instead of >> >> //-------------------------------------------------------------------------- >> // uses c:\Program Files\[program name]\registry\ . Whether the user >> has the rights to create this folder here? >> //-------------------------------------------------------------------------- >> OString dir = PProcess::Current().GetFile().GetDirectory() + "registry"; >> if( !PFile::Exists( dir.c_str() ) ) >> PDirectory::Create( dir.c_str() ); >> //-------------------------------------------------------------------------- >> >> in >> >> //======== RegisterSessionManager.cxx ======== >> >> RegistrationDatabase::RegistrationDatabase() >> { >> #if HAS_CPPSQLITE >> m_HasContactRecovery = PrepareContactRecoveryDB( >> "ContactRecovery.sqlite" ); >> #else >> m_HasContactRecovery = TRUE; >> OString dir = PProcess::Current().GetFile().GetDirectory() + "registry"; >> if( !PFile::Exists( dir.c_str() ) ) >> PDirectory::Create( dir.c_str() ); >> m_RegRecoveryDIR = dir.c_str(); >> #endif >> } >> |
From: <jo...@op...> - 2007-12-05 07:46:28
|
To sum up. One in the list is in favor of a python approach and another in favor of a built-in fast CGI approach. Everyone seems unanimous in having SQL server support. Just this morning, Ryan Colobong pointed me to http://www.cherrypy.org/ which is another python based solution to incorporate dynamic web pages to opensbc. There seem to be a lot of resources we could use in a python based solution. However, fast-cgi support in OpenSBC would carry on the tradition of simplicity in installation, it will take a lot longer just to develop the module that enabled fast-cgi support not to mention that HTTP is not really the turf OpenSIPStack. At this point I am leaning towards a python based solution. For those who are willing to pitch in your ideas, now is the time to speak up. Joegen Joegen E. Baclor wrote: > Hi Everyone, > > As I have hinted in the past, there is a plan to provide a new level of > administrative interface for OpenSBC. As most of you might have > discovered by now, OpenSBC is very easy to install and requires > virtually no configuration for you to be able to run and use it. This > is all because of a built-in HTTP server that allows for OpenSBC to be > configured remotely. However, since version 1.1.4 and with the > introduction of more advanced features like SIP Trunking, the built-in > HTTP Config Pages is out-growing its simplicity. We are now in a > point where we need to decide what technology to use to bring the > configuration modules to the next level. We need to seriously > consider the following criteria in choosing the solution. > > 1. It should be very easy to install and package > 2. Built-in access to back-end databases preferably Postgress > 3. Must be able to host Dynamic HTML Content > 4. Other criteria that might be useful are support for XML-RPC and SOAP > > > Some of the basic choices that I pulled out straight from my thoughts are > > 1. A separate web interface easily installable as standard Apache Web > application. Choices are PHP, JSP Ruby with SQL back-end > 2. Stand-alone Python HTTP Server just like the trac project. See > http://trac.edgewall.org/ > 3. Enhance the HTTP Admin to support Fast-CGI extension to allow for > dynamic HTTP content to be hosted straight by OpenSBC > > I would want to hear from everyone if you are leaning towards a certain > approach or would want another approach altogether. > > Joegen > > ------------------------------------------------------------------------- > 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 > > > > |
From: Joegen E. B. <joe...@gm...> - 2007-12-05 06:35:37
|
I have modified the host access list configuration to include a list of selected hosts to be banned access. Two new items are added to the config page. 1. Ban Selected Host - Flag whether OpenSBC would permanently reject INVITEs from the listed Banned hosts from the internet. 2. Banned Hosts - Entry for host can be a single IP Address or a range. Example: 192.168.0.1 or 10.0.0.1-10.0.0.255 Joegen E. Baclor wrote: > Hi Everyone, > > I have added a new configuration section "Host Access List" for OpenSBC > that allows only certain IP address to send calls to OpenSBC. It can > accept a list of single IP addresses or a network block. There are > only two parameters in this page > > 1. Trust All Hosts - Flag whether OpenSBC would accept INVITEs from ANY > host from the internet. If this flag is set to TRUE OpenSBC will only > accept calls from the IP Addresses or Range listed. > 2. Hosts - Entry for host can be a single IP Address or a range. > Example: 192.168.0.1 or 10.0.0.1-10.0.0.255 > > If the Access List is enabled and a call came in from an unknown host, > OpenSBC will answer with a forbidden with a Warning header. A sample of > such response is below: > > SIP/2.0 403 Forbidden > From: "unknown" <sip:20...@pb...>;tag=172561562940 > To: <sip:10...@pb...>;tag=de055ec348fa18109fd8d5d74376c6ed > Via: SIP/2.0/UDP > 127.0.0.1:1000;iid=5050;branch=z9hG4bKc0a800990000005847557d8900000c8200000117;rport=1000;received=192.168.120.1 > CSeq: 1 INVITE > Call-ID: E7335922-1B42-4670-817A-EE1FEFC337EC@192.168.0.153 > Server: OpenSIPStack-1.1.7-18 > Warning: 399 192.168.120.1 Is Not Allowed In Our Access List > Content-Length: 0 > > Joegen > > ------------------------------------------------------------------------- > 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 > > > |
From: <sa...@ER...> - 2007-12-05 05:19:40
|
Hi eric Yes, UA->OSBC->SIPX->OSBC->ITSP. We are determine to use OSBC with sipX. At this point it seems very dueable but it's the choice of ITSP that will be the stumbling block. OSBC needs an admin screen to minipulate the INVITE to tailor them to various ITSP requirements. Good Luck with your guide Warren Kreckler ----- Original Message ----- From: "eric hernaez" <er...@so...> To: <ope...@li...> Sent: Tuesday, December 04, 2007 10:55 PM Subject: Re: [OpenSIPStack] INVITE and multi via: > > > jo...@op... wrote: > > Hi Warren, > > > > If the call flow is Caller->sipX->SBC->ITSP, then OpenSBC would have > > just sent a single via. Is your call flow Caller->SBC->sipX->ITSP? > > > > > > We are working on publishing a How To guide for using OSBC with SIPX. > But until that is ready, think about using SIPX as a gateway for all > PSTN-bound calls so that the call flow would be as follows: > UA->OSBC->SIPX->OSBC->ITSP. > > Since OSBC will be proxying the media for NAT traversal in most cases, > having OSBC as a single IP address (for both signaling and media) known > to your ITSP will simplify their configuration as well. > > > > Joegen > > > > sales@ER wrote: > > > >> Hi > >> > >> Our ITSP can accept only 1 Via statement in an INVITE. The INVITE when it > >> reaches the SBC has an entry from the phone and two from sipx. I cannot find > >> any documentation about an option to remove Via Headers. > >> > >> 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 |