November 2008 - sr-users

[Serusers] Digest Authentication with Tenor DX
by Ashutosh Kumar 29 Apr '25

29 Apr '25

Hi, Does someone have any idea/experience with Quintum DX radius server's support for digest mode authentication. The Access-Request packets sent by SER are getting an error back. Guide. Regards, Ashutosh Kumar Chetu, Inc. Ph : 1(305) 402 6724 - Witin US Ph : 91 120 5323340 - Outside US Fax:1 (305) 832 5987 For more information, please visit http://www.chetu.com

2 1

[OpenSER-Users] uaCSTA support in openser
by Hugo Koblmueller 09 Feb '11

09 Feb '11

high.all! i'm wondering if there is any support of uaCSTA in openser (planned)? i'm just working on the integration of asterisk (*) environment to OCS 2007 environment, having openSER in the middle (mainly for TCP/UDP translation and smoothing out the protocol deficienes on both sides). in this setup the * having the openSER in front is talking to the OCS (and vice versa) via the OCS mediation server, which is moreorless sending standard SIP messages, which enables normal softphone (integration to *) of the office communicator. this configuration is already working... now i'm planning to go for the CTI integration, where there is no OCS mediation server in between OCS and openSER, doing the translation of SIP/CSTA to SIP. i'm thinking about using openSER for this task, that's why i'm looking for a CSTA module or perl programm, which is capable of this functionality. afaik for the CTI communication there isn't the full complexity of CSTA needed, just a subset mainly for call setup and call clearing. anyone having experience on this topic? thx & cheers -hugo Great Ideas for Small Devices Hugo Koblmueller Senior Staff Engineer Software Development COMNEON electronic technology GmbH & Co. OHG Freistaedter Strasse 400 4040 Linz Austria hugo.koblmueller(a)comneon.com tel: fax: mobile: Skype ID: +43 (5) 1777 - 15730 <http://www.plaxo.com/click_to_call?lang=en&src=jj_signature&To=%2B43+%285%2 9+1777+%2D+15730&Email=hugo(a)koblmueller.com> +43 (5) 1777 - 15810 +43 (676) 82051280 <http://www.plaxo.com/click_to_call?lang=en&src=jj_signature&To=%2B43+%28676 %29+82051280&Email=hugo(a)koblmueller.com> drhookson Want to always have my latest info? <https://www.plaxo.com/add_me?u=21475050628&src=client_sig_212_1_banner_join &invite=1&lang=en> Want a signature like <http://www.plaxo.com/signature?src=client_sig_212_1_banner_sig&lang=en> this?

7 13

[Serusers] Deadly embrace with rtpproxy - Is it necessary? Can it be turned off?
by Frank Durda IV 20 Mar '09

20 Mar '09

I'm running into a problem with rtpproxy on this point, quoting from the README: - - - - - - - - - - - - after the session has been created, the proxy listens on the port it has allocated for that session and waits for receiving at least one UDP packet from each of two parties participating in the call. Once such packet is received, the proxy fills one of two ip:port structures associated with each call with source ip:port of that packet. When both structures are filled in, the proxy starts relaying UDP packets between parties; - - - - - - - - - - - However, a number of clients frequently fail to emit any audio when originating a call until they hear something from the TDM gateway, such as ring-back or the called party answering. So although rtpproxy is receiving a stream of audio, such as a voice mail menu robot, the calling party can't hear any of it unless they happen to make some noise or randomly and blindly press a DTMF key. This seems to be made worse on links with silence suppression, so there is no background noise to trigger two-way audio. This is being encountered between Class 4 carriers, so we don't have the option to get someone to adjust their phone/PBX settings or have them breathe heavier. Is there a setting adjustment to get rtpproxy to just pass the RTP packets from directed calling and called sources even if one party hasn't happened to make noise yet? I personally don't understand why this requirement for seeing audio from both sides before starting the flow in either direction if audio starts coming in even exists. It seems to have no benefit but is bound to cause this deadly embrace problem in many situations that may be beyond the control of the owners of the equipment passing traffic along to the site where rtpproxy is in use. Suggestions? Fix? I have looked at the latest snapshot of rtpproxy and the README is unchanged since 1.1 so apparently this behavior is still the same. Thanks in advance!

4 15

[OpenSER-Users] [OT] How to handle different DID's in incoming calls for a registered client?
by Iñaki Baz Castillo 27 Feb '09

27 Feb '09

Hi, maybe this question is a bit off-topic so I'm sorry for that. My question is about SIP providers using OpenSer that associate PSTN numbers to their local clients (SIP accounts): Usually the client must register to OpenSer in order to receive calls. Then it will appear in location table with "Contact=sip:clientX@IP". Suppose clientX has two PSTN numbers associated in a ENUM entry: +34999000111 +34999000222 When anyone in PSTN world calls to +34999000222 the call will arrive to the OpenSer from a gateway in an INVITE like: INVITE sip:+34999000222@gateway SIP/2.0 To: <sip:+34999000222@gateway> The OpenSer will do the lookup in location table and finally send this INVITE to the clientX: INVITE sip:clientX@IP_clientX SIP/2.0 To: <sip:+34999000222@gateway> The info about the called PSTN number is just available in "To" header, so a way to get different behaviour for each associated PSTN number is matching "To" URI. Is common to do it? which other alternatives are there? Thanks for any comment. Regards. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

7 17

[Kamailio-Users] Looking for a highly available / load balanced setup
by John D 11 Feb '09

11 Feb '09

I currently have three Asterisk servers in my environment. None of them speak to each other just yet. The idea is to install Kamailio and be able to load balance/distribute SIP calls to any of the three asterisk boxes. If an entire box plug gets pulled, the operation continues. If a Kamailio box gets the plug pulled (and due to limited resources, I plan at first to run kamailio on all three of the asterisk boxes), the operation will continue. Does anyone have good documentation or insight in order to facilitate this sort of setup? Thanks.

4 6

[Kamailio-Users] using "substr()" function from TEXTOPS in "onreply_route" block
by Alex R.S.M 08 Dec '08

08 Dec '08

Hi, I was wondering if anyone has used "substr()" function from TEXTOPS in "onreply_route" block. This function works fine in "route" and "branch_route" blocks. However, it creates duplicate fields (instead of substituting) when being used in "onreply_route" blocks. I need to modify FROM field in "onreply_route" block. As far as I know, "uac_replace_from()" function works only in request_route block, so my only option is to use "substr()". Thanks, Alex R _________________________________________________________________ Proud to be a PC? Show the world. Download the “I’m a PC” Messenger themepack now. hthttp://clk.atdmt.com/MRT/go/119642558/direct/01/

3 3

[Kamailio-Users] Port of kamailio to OpenBSD
by Don Jackson 05 Dec '08

05 Dec '08

I have motivated the creation of a port of kamailio to OpenBSD, the port creates binary packages, which can then be added via the pkg_add command. I could definitely use input and testing of this port from the kamailio community, if you are interested in running kamailio on OpenBSD, I could use your help! We also needed to create a port of radiusclient to support kamailio. Both ports are attached to the messages appended below. Don Begin forwarded message: > From: Don Jackson <don.jackson(a)gmail.com> > Date: November 18, 2008 11:16:22 AM PST > To: ports(a)openbsd.org > Subject: NEW: telephony/kamailio-1.4.2 (kamailio used to be called > OpenSER) > > > Tested on 4.4/amd64, definitely interested in more testing > > $ cat DESCR-main > > KAMAILIO (OpenSER) is a mature and flexible open source SIP server > (RFC3261). > It can be used on systems with limitted resources as well as on > carrier grade > servers, scaling to up to thousands call setups per second. It is > written in > pure C for Unix/Linux-like systems with architecture specific > optimizations to > offer high performances. It is customizable, being able to feature > as fast load > balancer; SIP server flavours: registrar, location server, proxy > server, > redirect server; gateway to SMS/XMPP; or advanced VoIP application > server. > > Begin forwarded message: > From: Don Jackson <don.jackson(a)gmail.com> > Date: November 18, 2008 11:11:53 AM PST > To: ports(a)openbsd.org > Subject: NEW: net/radiusclient-ng-0.5.6 > > > This port is needed for the kamailio/openser port (see subsequent > email) > > Tested on 4.4/amd64, definitely interested in more testing. > > $ cat pkg/DESCR > > Purpose of this project is to build portable, easy-to-use and standard > compliant library suitable for developing free and commercial software > that need support for a RADIUS protocol (RFCs 2138 and 2139). > > > >

2 3

[Kamailio-Users] How are computed $Tf and $Ts?
by Iñaki Baz Castillo 03 Dec '08

03 Dec '08

Hi, it doesn't make sense: xlog("L_INFO","--- time pre http: $Tf - $Ts\n"); http_query("/test1.html", "r_uri=$(ru{s.escape.param})&f_uri=$(fu{s.escape.param})", "$var(result)"); xlog("L_INFO","--- time post http: $Tf - $Ts\n"); I always get: --- time pre http: Mon Nov 24 14:37:25 2008 - 1227533845 --- time post http: Mon Nov 24 14:37:25 2008 - 1227533845 Of course it's just impossible that the http query takes 0.000 seconds. I could use 'benchmark' module fot this stuf, but I wonder why $Tf returns the same value in any place of the script. Maybe it is just computed at the script start for each message? Thanks. -- Iñaki Baz Castillo

2 4

Re: [Serusers] How can I keep SER from changing reply Response Code from 503 to 500?
by Frank Durda IV 03 Dec '08

03 Dec '08

Jeroen van Bemmel wrote: > Frank, > > RFC3261 specifically specifies that proxies should convert response code > 503 into 500: > > A proxy which receives a 503 (Service Unavailable) response > SHOULD NOT forward it upstream unless it can determine that any > subsequent requests it might proxy will also generate a 503. > In other words, forwarding a 503 means that the proxy knows it > cannot service any requests, not just the one for the Request- > URI in the request which generated the 503. If the only > response that was received is a 503, the proxy SHOULD generate > a 500 response and forward that upstream. > > So SER is behaving in accordance with the standard. There might be a > configuration option to turn this off? Well, yes and no. Thanks for pointing out this item in the RFC which I missed, but if the RFC action is honored, then SER should have emitted "500 Server Internal Error" which is in the RFC, and not the hybrid and made-up "500 Service Unavailable", which is not in the RFC. So, I think SER is wrong at least on that point. (Personally I think SIP desperately needs at least 20 additional defined Response Codes so we can all quit using the existing not-entirely-inappropriate values to cover real-life situations, but right now the book says that's all the codes that we've all got to work with. When you see a dozen SS7 release codes all map to the same SIP Response Codes, you don't have nearly enough SIP Response Codes, but I digress.) That said, our SER server knows the given condition sent from a paired PSTN switch is permanent, eg the SIP caller can't call this number via our network now, tomorrow or next week because of who you they or whom their provider is (or what they failed to buy), so in this situation returning 503 all the way out of our network is correct behavior (as stated in the RFC), and doing so allows the upstream entity to click over to the next preferred carrier that might reach that destination. We have found that many SIP providers simply blindly lob all calls at the cheapest carrier and if a given call bounces, repeat that action with the next-cheapest carrier, and the next until they finally resort to a Tandem that will take anything, but will also be the most expensive way to route the call. Nearly all require us to send them back a 503 (a few want us to send 502 back instead) to say back to them "not via here, try next door". Deplorable and this method certainly causes slow call set-up times, but that is what quite a few of these outfits are doing. So, our SER must send them back a 503 and not a 500 in this situation. If I explicitly state one in a reply rule, will that override this default behavior, or will some deeper part of SER veto even a sl_reply("503", "Service Unavailable"); added to the onreply_route? If so, where is this piece of source code, so that I may break this well-intended but undesired behavior?

5 8

Re: [Serusers] Registering port instead of contact field port
by Iñaki Baz Castillo 02 Dec '08

02 Dec '08

El Jueves, 27 de Noviembre de 2008, Daniel Serrano escribió: > Dear all, > > I am using SER as IM server and I found that the SER use the contact > field to storage the user's location in the memory for future requests. > I noted this using the command "serctl alias show" and checking some > traces. > Since I'm using a NAT scenario I'd like to use the UDP port that my > SER server receives during the registration instead of the contact > field port to reach the users after their registration. Is there any > way to do this? "rport" does it, but the client must indicate support of "rport" by adding ";rport" parameter to its Via header. Anyway, *SER can force it by using "force_rport()". -- Iñaki Baz Castillo

3 5

[Kamailio-Users] PDT module - multiple prefix single domain
by Matteo Piazza 02 Dec '08

02 Dec '08

Hi all, I notice a thing about PDT module. If you try to put in the table two entry with the same destination domain at the load of the parameter is reported an error of duplication: Nov 28 09:32:23 [5169] ERROR:pdt:pdt_load_db: sdomain [*]: prefix [04610202] or domain <tnn.multivoce.tnnet.it> duplicated entry of the table id | sdomain | prefix | domain ----+---------+----------+-------------------------- 1 | * | * | intercom.tnnet.it 4 | * | 04610200 | tsm.multivoce.tnnet.it 2 | * | 04610201 | tnn.multivoce.tnnet.it 3 | * | 04610202 | tnn.multivoce.tnnet.it Is this mean that the prefix must be only one for a single domain. This is a limition where I have a single domain that manage multiple prefix not consecutive. Did I understand right? Matteo -- ==================================== Matteo Piazza Trentino Network s.r.l. a Socio Unico matteo.piazza(a)trentinonetwork.it Via Gilli, 2 - 38100 TRENTO Tel (+39) 0461.020224 ====================================

3 6

[Kamailio-Users] Thomson ST2030 SIP contact problem
by Samuel Muller 01 Dec '08

01 Dec '08

Hello all, I've a little problem with the SIP phone Thomson ST2030. When it registers, it auto-adds ";user=phone" in all the fields it can be. The problem is that it can't be called due to the contact header, kamailio can't found the phone. I tried to delete the filed during the REGISTER and the PROXY AUTH processes, with no success ... If someone has a solution, many thanks ! -- -- kamailio.cfg : -- -- ... # ;user=phone hack if (search("^Contact:.*;user=phone")) { xlog("L_INFO", "-> user=phone found, remove it - F=$fu ContactHF=$ct"); replace_all(";user=phone", "\r\n"); #subst("/;user=phone$;$")) } ... => all the logs here : -- -- SQL result -- -- Database: openser SQL query: SELECT * FROM `location` WHERE `id` = 383 LIMIT 0, 30 ; id 383 username 0123451013 domain sip.720.fr contact sip:0123451013@192.168.0.158:5060;user=phone received sip:77.246.81.162:1902 path NULL expires 2008-11-28 13:02:16 q 0.00 callid 18786315-c0a80101-5-a(a)192.168.0.158 cseq 270 last_modified 2008-11-28 12:02:16 flags 0 cflags 64 user_agent THOMSON ST2030 hw5 fw1.63 00-14-7F-00-5E-0A socket udp:77.246.81.132:5060 methods NULL -- -- kamailio REGISTER sip buffer -- -- REGISTER sip:sip.720.fr;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.0.158:5060 ;branch=z9hG4bK363142985921875976-158787787 From: <sip:0123451013@sip.720.fr:5060;user=phone>;tag=c0a80101-976e8ab To: <sip:0123451013@sip.720.fr:5060;user=phone> Call-ID: 18786315-c0a80101-5-a(a)192.168.0.158 CSeq: 250 REGISTER Max-Forwards: 69 Expires: 3600 Contact: <sip:0123451013@192.168.0.158:5060;user=phone> Authorization: Digest username="0123451013", realm="sip.720.fr", nonce="492f8a92000000697e7fefd30ce752d7e50c6166da2cc6e2", uri="sip:sip.720.fr", response="37f8ec824ba77eb37583f38f2a509f77", algorithm=MD5, qop=auth, cnonce="976e8cb", nc=00000001 User-Agent: THOMSON ST2030 hw5 fw1.63 00-14-7F-00-5E-0A Allow-Events: refer,dialog,message-summary,check-sync,talk,hold Content-Length: 0 -- -- ngrep log : -- -- U 2008/11/28 12:13:59.813649 77.246.81.162:8680 -> 77.246.81.132:5060 INVITE sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> SIP/2.0. Via: SIP/2.0/UDP 192.168.0.113:5060;branch=z9hG4bK-eb23842c. From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Remote-Party-ID: "Sam" <sip:0123451010@sip.720.fr<sip%3A0123451010(a)sip.720.fr> >;screen=yes;party=calling. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 50. Proxy-Authorization: Digest username="0123451010",realm="sip.720.fr ",nonce="492fd3a300000094c9e8b4f3805f7f96dc3f36f981a64570",uri=" sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> ",algorithm=MD5,response="1538e1ac3e3181f8bfb6f473f2470a6a",qop=auth,nc=00000001,cnonce="7c8a76fd". Contact: "Sam" <sip:0123451010@192.168.0.113:5060>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 263. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 192.168.0.113. t=0 0. m=audio 35692 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. U 2008/11/28 12:13:59.820056 77.246.81.132:5060 -> 77.246.81.162:8680 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.0.113:5060 ;branch=z9hG4bK-eb23842c;rport=8680;received=77.246.81.162. From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Server: 720 DEGRES SIP PROXY. Content-Length: 0. Warning: 392 77.246.81.132:5060 "Noisy feedback tells: pid=14141 req_src_ip=77.246.81.162 req_src_port=8680 in_uri=sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr>out_uri= sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> via_cnt==1". . U 2008/11/28 12:13:59.882639 77.246.81.132:5060 -> 77.246.81.162:1902 INVITE sip:0123451013@192.168.0.158:5060;user=phone SIP/2.0. Record-Route: <sip:77.246.81.132 ;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK821.3a570854.0. Via: SIP/2.0/UDP 192.168.0.113:5060;rport=8680;received=77.246.81.162 ;branch=z9hG4bK-eb23842c. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 49. Contact: "Sam" <sip:0123451010@77.246.81.162:8680>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 281. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. Privacy: id. Remote-Party-ID: <<null>>;party=caller;privacy=yes;screen=no. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 77.246.81.133. t=0 0. m=audio 35132 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes. U 2008/11/28 12:14:00.273883 77.246.81.132:5060 -> 77.246.81.162:1902 INVITE sip:0123451013@192.168.0.158:5060;user=phone SIP/2.0. Record-Route: <sip:77.246.81.132 ;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK821.3a570854.0. Via: SIP/2.0/UDP 192.168.0.113:5060;rport=8680;received=77.246.81.162 ;branch=z9hG4bK-eb23842c. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 49. Contact: "Sam" <sip:0123451010@77.246.81.162:8680>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 281. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. Privacy: id. Remote-Party-ID: <<null>>;party=caller;privacy=yes;screen=no. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 77.246.81.133. t=0 0. m=audio 35132 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes. U 2008/11/28 12:14:01.272604 77.246.81.132:5060 -> 77.246.81.162:1902 INVITE sip:0123451013@192.168.0.158:5060;user=phone SIP/2.0. Record-Route: <sip:77.246.81.132 ;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK821.3a570854.0. Via: SIP/2.0/UDP 192.168.0.113:5060;rport=8680;received=77.246.81.162 ;branch=z9hG4bK-eb23842c. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 49. Contact: "Sam" <sip:0123451010@77.246.81.162:8680>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 281. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. Privacy: id. Remote-Party-ID: <<null>>;party=caller;privacy=yes;screen=no. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 77.246.81.133. t=0 0. m=audio 35132 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes. U 2008/11/28 12:14:03.283852 77.246.81.132:5060 -> 77.246.81.162:1902 INVITE sip:0123451013@192.168.0.158:5060;user=phone SIP/2.0. Record-Route: <sip:77.246.81.132 ;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK821.3a570854.0. Via: SIP/2.0/UDP 192.168.0.113:5060;rport=8680;received=77.246.81.162 ;branch=z9hG4bK-eb23842c. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 49. Contact: "Sam" <sip:0123451010@77.246.81.162:8680>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 281. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. Privacy: id. Remote-Party-ID: <<null>>;party=caller;privacy=yes;screen=no. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 77.246.81.133. t=0 0. m=audio 35132 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes. U 2008/11/28 12:14:04.905612 77.246.81.162:8680 -> 77.246.81.132:5060 CANCEL sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> SIP/2.0. Via: SIP/2.0/UDP 192.168.0.113:5060;branch=z9hG4bK-eb23842c. From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 CANCEL. Max-Forwards: 50. Proxy-Authorization: Digest username="0123451010",realm="sip.720.fr ",nonce="492fd3a300000094c9e8b4f3805f7f96dc3f36f981a64570",uri=" sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> ",algorithm=MD5,response="07e4433c6000309b8cac1f917dbb9643",qop=auth,nc=00000002,cnonce="7c8a76fd". User-Agent: Linksys/SPA941-5.1.8. Content-Length: 0. . U 2008/11/28 12:14:04.912088 77.246.81.132:5060 -> 77.246.81.162:8680 SIP/2.0 501 Method Not Supported Here. Via: SIP/2.0/UDP 192.168.0.113:5060 ;branch=z9hG4bK-eb23842c;rport=8680;received=77.246.81.162. From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> >;tag=d25c9349df891607b66aeb00d1da49ca.b1d0. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 CANCEL. Server: 720 DEGRES SIP PROXY. Content-Length: 0. Warning: 392 77.246.81.132:5060 "Noisy feedback tells: pid=14137 req_src_ip=77.246.81.162 req_src_port=8680 in_uri=sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr>out_uri= sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> via_cnt==1". -- Samuel MULLER Ingénieur Reseaux & Telecom 720 DEGRES +33 (0)663 128 505 sml(a)720.fr

3 6

[Kamailio-Users] Webx-SER: a new project to give kamailio users a web interface (like Serweb was)
by yannick 30 Nov '08

30 Nov '08

Hello, I started a project to give users of Kamailio server a web interface to register and manage their datas. It was inspired by a need of the Ekiga.net platform ( https://www.ekiga.net ) to allow users register like they were able to do when Ekiga.net was using SER and Serweb. I called this software Webx-SER. Webx-SER feature now: * Registration of accounts to kamailio * Password reminder * Changing password Technically, Webx-SER use PHP and MySQL. It has a cache system for common non-interactives pages, a template system to split HTML from PHP and a captcha system to prevent bots. Some work has been put in managing forms to make it user-friendly. The licence is GPL 3 or higher. Webx-SER is actually used on https://www.ekiga.net There is a web site for Webx-SER developments, including users and devels mailing-list, bug tracking system, source tarball releases and GIT repository for source code here: http://webxser.tuxfamily.org/ Feedback, comments, help in coding will be warmly welcome. I also want to thanks Damien Sandras and Jan Schampera for their help, support and inspiration. Best regards, Yannick Defais -- Me joindre en téléphonie IP / vidéoconférence ? sip:yannick@ekiga.net Logiciel de VoIP Ekiga : http://www.ekiga.org http://wiki.ekiga.org/index.php/Which_programs_work_with_Ekiga_%3F

2 3

[Kamailio-Users] Attendant call transfer between asterisk gateway and OpenSER problem
by muhammad akl 28 Nov '08

28 Nov '08

I have the following scenario : Pstn Number(1234567) <-----------> Asterisk GW <----------------> Openser | <-------------->11803 | | | <--------------> 11801 Firstly extension 11803 will call the pstn number and this works fine without no problem , after that 11803 will put 1234567 on hold and will call 11801 , then 11803 will transfer 1234567 to 11801 (<---- the problem now started ), what is happening now is that both 123456 and 11801 will be on hold with 11803 after the transfer is done I've traced the full dialog between the three extensions and found an interesting part , which a NOTIFY message came from asterisk and contains this sentence : SIP/2.0 481 Call leg/transaction does not exist The addresses of the devices as follows : Asterisk Gw : 192.168.200.202 OpenSER : 192.168.200.10 11803 : 192.168.200.222 11801 : 192.168.200.224 The full trace : http://muhammad.akl.googlepages.com/debug.txt Regards

2 2

Re: [Kamailio-Users] Trying to deliver a call across multiple peers with t_relay
by Tyler Brauer 28 Nov '08

28 Nov '08

Thank you Klaus for the suggestions. I've implemented the configuration below. When the first t_relay fails, Kamailio generates the 408 Request Timeout and doesn't attempt to try an INVITE to the second address. This what the syslog says: Nov 28 06:11:13 server kamailio[1315]: Attempting Carrier 1 Nov 28 06:11:28 server kamailio[1323]: Attempting Carrier 2 Nov 28 06:11:28 server kamailio[1323]: ERROR:tm:t_forward_nonack: no branch for forwarding Nov 28 06:11:28 server kamailio[1323]: ERROR:tm:w_t_relay: t_forward_nonack failed Nov 28 06:11:28 server kamailio[1317]: Attempting Carrier 1 And here's the watered-down version of my configuration. # - - - - - - - - - - - - - - - - - - - - route[0] { if($si=='10.10.10.10') { # Allowed Host route(1); } else { sl_send_reply("603", "Decline"); exit; } } # - - - - - - - - - - - - - - - - - - - - route[1] { if(msg:len > 2048) { sl_send_reply("513", "Message Too Big"); exit; } if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); exit; } if (method==OPTIONS) { if ((uri==myself) && (! uri=~"sip:.*[@]+.*")) { options_reply(); exit; } } if (!method=="REGISTER") { record_route(); } if (loose_route()) { append_hf("P-hint: rr-enforced\r\n"); } if (is_method("CANCEL")) { if (t_check_trans()) { t_relay(); } exit; } route(2); } # - - - - - - - - - - - - - - - - - - - - route[2] { xlog("L_INFO", "Attempting Carrier 1"); t_on_failure("3"); t_relay("udp:1.1.1.1:5090","0x2"); exit; } # - - - - - - - - - - - - - - - - - - - - failure_route[3] { xlog("L_INFO", "Attempting Carrier 2"); t_on_failure("4"); t_relay("udp:2.2.2.2:5060"); exit; } # - - - - - - - - - - - - - - - - - - - - failure_route[4] { # I would like to know how to redirect the # original call destined to extension "100" # to 2015551234, but the originating server # will get nervous if the username@ part # of its SIP request is changed. How could } # - - - - - - - - - - - - - - - - - - - - Any further suggestions would be appreciated. Thanks!

2 1

[Kamailio-Users] Does enum_query support wildcard and non-terminal NAPTR record ?
by jerome boileau 28 Nov '08

28 Nov '08

Hi, I'm testing an ENUM DNS server (BIND9) with Openser 1.2.0. It seems that Openser Enum module doesn't support wildcard and non terminal NAPTR record. Enum module is working well when the NAPTR record is defined in the ENUM DNS with complete phone number and ‘u’ flag. Here is an example of the NAPTR record: 1.2.3.4.5.6.7.8.9.3.3.enum1.net IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:+33987654321@example.com!". When I declared a wildcard in the ENUM DNS (ie: *.enum1.net IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:+33987654321@example.com!".), enum_query function didn't find the NAPTR record. The following message is returned in the log, enum_query(): No NAPTR record found for 1.2.3.4.5.6.7.8.9.3.3.enum1.net. Should resolver (ie resolve.c source file) or enum module be modified to handle wildcard or is it just a parameter to set ? In case of wildcard CNAME record instead of NAPTR, openser behave in the same way, the CNAME record was not found. I also tried to use a non-terminal NAPTR to forward the ENUM DNS query towards another domain. Here is the NAPTR record declared in the ENUM DNS: 1.2.3.4.5.6.7.8.9.3.3.enum1.net IN NAPTR 10 100 "" "" "!^.*([0-9]{11})$!\\1.enum2.net!". By using sip_match function, the enum_query (ie do_query) function discards the NAPTR record without ‘u’ flag. I removed the check on the flag (comment sip_match function) so the NAPTR record is not discarded. But instead of looking for the terminal NATR record, enum_query function overwrites the Request URI with the non-terminal NAPTR record. Is the handling of non terminal NAPTR fixed in a new version of enum module ? If not, is it planned ? Thanks in advance for your help. Best regards, Jérôme -- View this message in context: http://www.nabble.com/Does-enum_query-support-wildcard-and-non-terminal-NAP… Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

3 3

[Kamailio-Users] simultaneus calls limitations
by BERGANZ François 28 Nov '08

28 Nov '08

Hello all, How can I contrôle « simultaneus calls limitation I could try to add in the database the number off simultaneous calls per user and when I check invite+1 cancel-1 bye-1 busy-1 BUT I have to insert in the database for each calls the call-id to know which user to do +1 or -1 Have you another idea? Thank you Cordialement, BERGANZ François P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

2 1

[Kamailio-Users] How to add Retry-After header in 503 response
by Alex Hermann 28 Nov '08

28 Nov '08

Hello, is there a way to add a Retry-After header to a 503 response i'm sending out using t_reply? Use case: t_relay creates an internal 408 on timeout. From failure-route, i want to pass it upstream as 503 with retry-after header. Changing the reply to 503 using t_reply works, but how to add the header? The reply obviously doens't pass through any reply_route. -- Greetings, Alex Hermann

3 4

[Kamailio-Users] Trying to deliver a call across multiple peers with t_relay
by Tyler Brauer 28 Nov '08

28 Nov '08

Good morning/afternoon/evening! I'm trying to accomplish two things. * First, I'd like to try sending a call from our B2BUA through Kamailio to one of our SIP peers, but in the event that the peer is unreachable, try the same call across an alternate peer. I'm currently trying something in our routing block like this. if(!t_relay("udp:1.1.1.1:5060","0x2")) { if(!t_relay("udp:2.2.2.2:5060")) { xlog("L_INFO", "Could not complete"); } } I've also been trying to put together something similar using t_on_failure(#) and a failure_route[#] block to say "if the first t_relay fails, try this instead". In both instances, when fr_timer elapses because the first peer hasn't responded to an INVITE, I can't stop Kamailio from throwing a "SIP/2.0 408 Request Timeout" back to the B2BUA. I have tried setting the flag on t_relay to keep quiet in the event of a forward failure, and instead use something like sl_send_reply("181", "Call Is Being Forwarded") to say to the agent "hold on, we're still trying". I can't seem to find the syntax to make any of that work. The 408 still keeps getting delivered (in spite of the flag on t_relay) to our server, which causes it to stop trying to deliver the call through Kamailio. * The second thing I'd like is that if the first two peers are unavailable, the request is rewritten to go across a third peer as a PSTN call. (eg: a call tries to reach 101(a)1.1.1.1 fails, then 101(a)2.2.2.2 fails, so then 2015551234(a)3.3.3.3 is tried). This requires rewriting the username field of the request URI, but I'm not sure how to do that without confusing the originating server. Could anyone help with the config syntax to resolve either of those two problems? Thank you very much!

3 2

[Kamailio-Users] important: pseudo-variables moved from core to pv module
by Elena-Ramona Modroiu 27 Nov '08

27 Nov '08

Hi, all pseudo-variables exported by core in the past are now in PV module. Therefore if you use any of them in your config you have to load the PV module. This is valid with devel version (trunk). This change was discussed some time ago on devel mailing list, the core is slimmer now. Soon transformations will be moved as well, making possible to export new transformations from modules. The core will include only the API to export PV and transformations, plus the engine to use them in config file. Regards, Ramona

3 2

[Serusers] Registering port instead of contact field port
by Daniel Serrano 27 Nov '08

27 Nov '08

Dear all, I am using SER as IM server and I found that the SER use the contact field to storage the user's location in the memory for future requests. I noted this using the command "serctl alias show" and checking some traces. Since I'm using a NAT scenario I'd like to use the UDP port that my SER server receives during the registration instead of the contact field port to reach the users after their registration. Is there any way to do this? Thanks in advanced. * Daniel Serrano D.** *

2 1

[Kamailio-Users] WARNING dbrow2info: non-local socket
by ALAEDDINE abbech 27 Nov '08

27 Nov '08

Hi, maybe this has been discussed before and maybe I'm not too good in reading mailinglists, but anyhow. If you have two OpenSER proxies storing to the same location table. I see in my logs: WARNING:usrloc:dbrow2info: non-local socket @of other server:5060 ...ignoring, I have a probleme with my DB when i register some UA. This is crucial? If this is not crucial, might this message be supressed in some way? Thanks,

2 3

Re: [Kamailio-Users] method value of the CSeq field
by Alex Balashov 27 Nov '08

27 Nov '08

Iñaki Baz Castillo wrote: > El Miércoles, 26 de Noviembre de 2008, Alex Balashov escribió: >> Iñaki Baz Castillo wrote: >>> El Miércoles, 26 de Noviembre de 2008, Alex Balashov escribió: >>>> You can parse it yourself using textops from $hdr(CSeq). >>> Not needed at all, just read $rm variable (works for requests and >>> responses). >> I didn't say it was needed, just that it could be done. ;) $rm is >> definitely best. > > I agree with you, parsing $hdr(CSeq) is cooler XD > In about the same measure that #include <stdio.h> #include <stdlib.h> int main(void) { FILE *fp = fopen("/dev/stdout", "w"); fprintf(fp, "Hello World!\n"); fclose(fp); return EXIT_SUCCESS; } is cooler than 10 PRINT "HELLO WORLD" 20 END :) -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599

2 1

[Kamailio-Users] http_query function
by jh＠tutpro.com 27 Nov '08

27 Nov '08

--text follows this line-- i wrote a http_query function that allows kamailio to make an http request and get access to parts of the reply. see trunk/modules/utils/README for details. -- juha

7 19

[Kamailio-Users] attendant call transfer between asterisk gateway and OpenSER problem
by muhammad akl 27 Nov '08

27 Nov '08

I have the following scenario : Pstn Number(1234567) <-----------> Asterisk GW <----------------> Openser | <-------------->11803 | | | <--------------> 11801 Firstly extension 11803 will call the pstn number and this works fine without no problem , after that 11803 will put 1234567 on hold and will call 11801 , then 11803 will transfer 1234567 to 11801 (<---- the problem now started ), what is happening now is that both 123456 and 11801 will be on hold with 11803 after the transfer is done I've traced the full dialog between the three extensions and found an interesting part , which a NOTIFY message came from asterisk and contains this sentence : SIP/2.0 481 Call leg/transaction does not exist The addresses of the devices as follows : Asterisk Gw : 192.168.200.202 OpenSER : 192.168.200.10 11803 : 192.168.200.222 11801 : 192.168.200.224 The full trace is below : interface: nge1 (192.168.200.0/255.255.255.0) filter: (ip) and ( port 5060 ) # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:1234567@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1DC2F22B. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372869 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273718813 273718813 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. 8 # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1DC2F22B. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060 >;tag=5be75dc65ffa8fb5a76b533c12178918.d1e1. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372869 INVITE. Proxy-Authenticate: Digest realm="192.168.200.10", nonce="492cf863ac436e9c37697617b6c5e4491e58df17". Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:1234567@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1DC2F22B. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060 >;tag=5be75dc65ffa8fb5a76b533c12178918.d1e1. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372869 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:1234567@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. Proxy-Authorization: Digest username="11803", realm="192.168.200.10", nonce="492cf863ac436e9c37697617b6c5e4491e58df17", opaque="", uri=" sip:1234567@192.168.200.10:5060", response="fefb838d12f5d716f5e1789a2a36ed93". Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273718813 273718813 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. _ # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 INVITE sip:1234567@192.168.200.202:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK596c.3851.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. Proxy-Authorization: Digest username="11803", realm="192.168.200.10", nonce="492cf863ac436e9c37697617b6c5e4491e58df17", opaque="", uri=" sip:1234567@192.168.200.10:5060", response="fefb838d12f5d716f5e1789a2a36ed93". Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273718813 273718813 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK596c.3851.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK596c.3851.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2712 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2712 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2A279063. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK596c.3851.2. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2A279063. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 234. . v=0. o=11803 273718813 273718814 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 0.0.0.0. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendonly. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 INVITE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK696c.5c64.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 234. . v=0. o=11803 273718813 273718814 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 0.0.0.0. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendonly. # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK696c.5c64.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK696c.5c64.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2713 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=recvonly. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2713 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=recvonly. # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T555ECDF6. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK696c.5c64.2. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T555ECDF6. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:11801@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T584FCDF0. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491577 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273772573 273772573 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T584FCDF0. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060 >;tag=5be75dc65ffa8fb5a76b533c12178918.146b. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491577 INVITE. Proxy-Authenticate: Digest realm="192.168.200.10", nonce="492cf87251a238af089dfab6b5d7f8c274907ba8". Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:11801@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T584FCDF0. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060 >;tag=5be75dc65ffa8fb5a76b533c12178918.146b. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491577 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Content-Length: 0. . 2 # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:11801@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491578 INVITE. Proxy-Authorization: Digest username="11803", realm="192.168.200.10", nonce="492cf87251a238af089dfab6b5d7f8c274907ba8", opaque="", uri=" sip:11801@192.168.200.10:5060", response="c182454ce412ce07dd2a0d13c416bf58". Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273772573 273772573 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. b # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491578 INVITE. Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.224:5060 INVITE sip:11801@192.168.200.224:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKa2ce.3cf7.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491578 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273772573 273772573 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. # U 192.168.200.224:5060 -> 192.168.200.10:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKa2ce.3cf7.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. CSeq: 612491578 INVITE. User-Agent: DPH-14001.01. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Content-Length: 0. . # U 192.168.200.224:5060 -> 192.168.200.10:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKa2ce.3cf7.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491578 INVITE. User-Agent: DPH-14001.01. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Content-Length: 0. . 0 # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491578 INVITE. User-Agent: DPH-14001.01. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Content-Length: 0. . # U 192.168.200.224:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKa2ce.3cf7.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. Require: timer. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491578 INVITE. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. Content-Type: application/sdp. Content-Length: 167. . v=0. o=11801 276818065 276818065 IN IP4 192.168.200.224. s=DPH-14001.01. c=IN IP4 192.168.200.224. t=0 0. m=audio 41000 RTP/AVP 0. a=rtpmap:0 PCMU/8000/1. a=sendrecv. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. Require: timer. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491578 INVITE. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. Content-Type: application/sdp. Content-Length: 167. . v=0. o=11801 276818065 276818065 IN IP4 192.168.200.224. s=DPH-14001.01. c=IN IP4 192.168.200.224. t=0 0. m=audio 41000 RTP/AVP 0. a=rtpmap:0 PCMU/8000/1. a=sendrecv. # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:11801@192.168.200.224:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3C593173. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491578 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Max-Forwards: 70. Content-Length: 0. . 0 # U 192.168.200.10:5060 -> 192.168.200.224:5060 ACK sip:11801@192.168.200.224:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKa2ce.3cf7.2. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3C593173. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491578 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:11801@192.168.200.224:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1280D8E9. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491579 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 234. . v=0. o=11803 273772573 273772574 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 0.0.0.0. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendonly. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1280D8E9. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491579 INVITE. Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.224:5060 INVITE sip:11801@192.168.200.224:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK92ce.5361.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1280D8E9. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491579 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 234. . v=0. o=11803 273772573 273772574 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 0.0.0.0. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendonly. # U 192.168.200.224:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK92ce.5361.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1280D8E9. Require: timer. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491579 INVITE. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. Content-Type: application/sdp. Content-Length: 167. . v=0. o=11801 276818065 276818065 IN IP4 192.168.200.224. s=DPH-14001.01. c=IN IP4 192.168.200.224. t=0 0. m=audio 41000 RTP/AVP 0. a=rtpmap:0 PCMU/8000/1. a=recvonly. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1280D8E9. Require: timer. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491579 INVITE. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. Content-Type: application/sdp. Content-Length: 167. . v=0. o=11801 276818065 276818065 IN IP4 192.168.200.224. s=DPH-14001.01. c=IN IP4 192.168.200.224. t=0 0. m=audio 41000 RTP/AVP 0. a=rtpmap:0 PCMU/8000/1. a=recvonly. # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:11801@192.168.200.224:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T72B9563C. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491579 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Max-Forwards: 70. Content-Length: 0. . 1 # U 192.168.200.10:5060 -> 192.168.200.224:5060 ACK sip:11801@192.168.200.224:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK92ce.5361.2. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T72B9563C. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491579 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 REFER sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T218F1384. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372872 REFER. Refer-To: < sip:11801@192.168.200.10:5060?Replaces=CALL_ID21_0015E9A0D90F_T1842345680%40192.168.200.222%3Bto-tag%3D0015E970817D_T1147221029%3Bfrom-tag%3D0015E9A0D90F_T408052446 >. Referred-by: <sip:11803@192.168.200.10 <sip%3A11803(a)192.168.200.10>>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Content-Length: 0. . P # U 192.168.200.10:5060 -> 192.168.200.202:5060 REFER sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK396c.8f11.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T218F1384. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372872 REFER. Refer-To: < sip:11801@192.168.200.10:5060?Replaces=CALL_ID21_0015E9A0D90F_T1842345680%40192.168.200.222%3Bto-tag%3D0015E970817D_T1147221029%3Bfrom-tag%3D0015E9A0D90F_T408052446 >. Referred-by: <sip:11803@192.168.200.10 <sip%3A11803(a)192.168.200.10>>. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 202 Accepted. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK396c.8f11.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T218F1384. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372872 REFER. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 202 Accepted. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T218F1384. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372872 REFER. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . # U 192.168.200.202:5060 -> 192.168.200.10:5060 NOTIFY sip:11803@192.168.200.222:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.202:5060;branch=z9hG4bK511c6a05;rport. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 102 NOTIFY. User-Agent: Asterisk PBX. Max-Forwards: 70. Event: refer;id=1844372872. Subscription-state: terminated;reason=noresource. Content-Type: message/sipfrag;version=2.0. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Length: 49. . SIP/2.0 481 Call leg/transaction does not exist. # U 192.168.200.10:5060 -> 192.168.200.222:5060 NOTIFY sip:11803@192.168.200.222:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=as17b63c65>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK3dbb.fc91.0. Via: SIP/2.0/UDP 192.168.200.202:5060;branch=z9hG4bK511c6a05;rport=5060. From: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 102 NOTIFY. User-Agent: Asterisk PBX. Max-Forwards: 69. Event: refer;id=1844372872. Subscription-state: terminated;reason=noresource. Content-Type: message/sipfrag;version=2.0. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Length: 49. . SIP/2.0 481 Call leg/transaction does not exist. # U 192.168.200.222:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK3dbb.fc91.0. Via: SIP/2.0/UDP 192.168.200.202:5060;branch=z9hG4bK511c6a05;rport=5060. From: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 102 NOTIFY. User-Agent: DPH-14001.01. Content-Length: 0. . 6 # U 192.168.200.10:5060 -> 192.168.200.202:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.202:5060;branch=z9hG4bK511c6a05;rport=5060. From: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 102 NOTIFY. User-Agent: DPH-14001.01. Content-Length: 0. . # U 192.168.200.201:26114 -> 192.168.200.10:5060 . . .............. # U 192.168.200.101:5060 -> 192.168.200.10:5060 .................. # U 192.168.200.224:5060 -> 192.168.200.10:5060 BYE sip:11803@192.168.200.222:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.224:5060;branch=z9hG4bK_0015E970817D_T7AFA8E38. From: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 1461395436 BYE. User-Agent: DPH-14001.01. Contact: <sip:11801@192.168.200.224:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.222:5060 BYE sip:11803@192.168.200.222:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E970817D_T1147221029>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKd255.f616.0. Via: SIP/2.0/UDP 192.168.200.224:5060;branch=z9hG4bK_0015E970817D_T7AFA8E38. From: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 1461395436 BYE. User-Agent: DPH-14001.01. Contact: <sip:11801@192.168.200.224:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKd255.f616.0. Via: SIP/2.0/UDP 192.168.200.224:5060;branch=z9hG4bK_0015E970817D_T7AFA8E38. From: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 1461395436 BYE. User-Agent: DPH-14001.01. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.224:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.224:5060;branch=z9hG4bK_0015E970817D_T7AFA8E38. From: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 1461395436 BYE. User-Agent: DPH-14001.01. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273718813 273718815 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 INVITE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK496c.a647.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273718813 273718815 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK496c.a647.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK496c.a647.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2714 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2714 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T36B8312B. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK496c.a647.2. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T36B8312B. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 BYE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2506AE3F. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372874 BYE. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 BYE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK196c.a9d3.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2506AE3F. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372874 BYE. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK196c.a9d3.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2506AE3F. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372874 BYE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2506AE3F. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372874 BYE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. .

1 0

[Kamailio-Users] serMyAdmin 1.0 Beta error
by Ricky Gutierrez 26 Nov '08

26 Nov '08

Hi list, recently I had to make some modifications to the chart subscriber of my openser to be able to use the CDRTool, now when I make an user with the serMyAdmin-BETA-1.0.war it shows me an error : please they can help me with this problem? best regards rickygm Grails Runtime Exception Error Details [leonardo]Caused by: org.springframework.jdbc.UncategorizedSQLException: Hibernate operation: could not insert: [User]; uncategorized SQLException for SQL [insert into subscriber (version, password_hash, auth_username, rpid, datetime_created, domain_id, domain, email_address, first_name, ha1, ha1b, last_name, username, password, role_id, class) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, 'User')]; SQL state [HY000]; error code [1364]; Field 'quota' doesn't have a default value; nested exception is java.sql.SQLException: Field 'quota' doesn't have a default value Class: UserController

2 2

[Kamailio-Users] basic config
by Lens Oreste 26 Nov '08

26 Nov '08

I am trying to do a basic configuration, I need to add a couple of routes and add radius for billing. Please let me show me how

3 2

[Kamailio-Users] method value of the CSeq field
by Alex R.S.M 26 Nov '08

26 Nov '08

Hi, Is there any variable to return the method value of the CSeq field? (example: returns "ACK" for CSeq:1165 ACK) $cs returns only the "Sequence Number". Thansk, Alex R, _________________________________________________________________ Access your email online and on the go with Windows Live Hotmail. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_access…

4 6

Re: [Kamailio-Users] UAC on ACK in reInvite
by Schober Walter 26 Nov '08

26 Nov '08

To finish the thread: I just entered below loose_route(): if (check_route_param("vsf=")) { avp_write("$hdr(Route[0])", "$avp(rr-param)"); avp_subst("$avp(rr-param)", "/^.*?(;vsf=[^>]+).*/\1/"); # $hdr(Route[0]) is not 1st header only, if multi header in one line xlog("L_INFO", ">> Stored UAC params $avp(rr-param)"); add_rr_param("$avp(rr-param)"); } > -----Original Message----- > From: Schober Walter > Sent: Wednesday, November 26, 2008 2:39 PM > To: 'Klaus Darilion' > Cc: 'users(a)lists.kamailio.org' > Subject: RE: AW: [Kamailio-Users] UAC on ACK in reInvite > > See below... > > > -----Original Message----- > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > Sent: Wednesday, November 26, 2008 1:21 AM > [...] > > > > This is clearly a bug in the useragent. The route set must not be > > changed with reINVITEs. Thus, according to the standard the > > Record-Route > > headers for indialog requests are not needed. Maybe you are calling > > record_route() for indialog requests and this confuses the client. > Fully agree on this. But some proxies add Record-Route, some > don't, Openser/Kamailio can configure it. > > It's not that clear in the RFC, but I see it the same way: > RFC 3261, 12.2 Request within a Dialog > ... > Requests within a dialog MAY contain Record-Route and > Contact header > fields. However, these requests do not cause the dialog's > route set > to be modified, although they may modify the remote target URI. > > 12.2.1.2 Processing the Responses > -> The only thing mentioned is that the _Target URI_ gets > refreshed by the 200 OK. > > => reInvites do not modify the routeset of any subsequent > request, neither the ACK not any other upcoming request. > > > Try removing the record_route() for indialog requests - may > then the > > buggy client remembers the original route set. > Done. Client sends ACK on reInvite directly then :-( > Counterpath is OK, Teles Voipbox not, other clients to be tested ... > > So I will have to add vsf uri param from Route to record > route in the proxy. This at least is a reason to upgrade :-) > It's done more easily with tranformations. > > Thanks for the discussion! For me it's "clearly a bug in the > UA" now, too ;-) However, let's find a workaround. > > br > Walter

1 0

[Serusers] Need help on a call forward always question
by Steven C. Blair 26 Nov '08

26 Nov '08

I am experiencing an issue with server side call forward always which I didn't see before but I now believe has always existed. Call forward always has been working. We recently switched phone manufacturers and now have the ability to offer bridged line appearance (BLA). Part of the process for offering BLA is to have the phones register with the shared attribute for a given line. When we enable this attribute server side call forward always breaks. When I say break I mean that the call forwards OK but the intermediate IP phone now rings which it never did before. Using ngrep I see that even with the old config (non-BLA setup) we had the same message flow: Invite (from PSTN gateway)-> Invite received at proxy-> Proxy responds to gateway with 200 OK-> Proxy loads forward address from mysql usr_preferences table Proxy rewrite R-URI to the forward address - avp_pushto("$ruri/username", "s:fwdaaddr"); Proxy send invite to this new address - but... Proxy also sends invite to each contact address registered to the original AOR. This should not happen but I think it was Always happening and the old phones just ignored it. Any thoughts on why and how to correct this behavior? The ser.cfg snippets involved are included below: Determine if call forward all is on: # call forward always if (avp_db_load("$ruri/username", "s:callfwdall")) { if (avp_check("s:callfwdall","eq/y/i")) { xlog("L_INFO", "\n[SER]: [%Tf] [%ci] User <%ru> has enabled Call Forward Always\n"); avp_write("$ruri", "$ocn"); - save original RURI for voicemail access if needed if (avp_db_load("$ruri/username", "s:fwdaaddr")) { avp_pushto("$ruri/username", "s:fwdaaddr"); rewritehostport("mydomain.edu"); xlog("L_INFO", "\n[SER]: [%Tf] [%ci] Calls for user <%tu> FORWARDING to <%ru>\n"); route(2); break; }; And call relaying is done by: route[2] { xlog("L_INFO", "\n[SER]: Route block #2 campus 5-digit extensions:\n\n"); xlog("L_INFO", "\n[SER]: [%Tf] [%ci] Route block #2: sending oncampus call from <%fu> to local gateway\n"); avp_write("65", "inv_timeout"); rewritehostport("my-gwy-ip-address:5060"); t_on_failure("1"); # for gwy failover t_relay(); break; }; Thanks,Steve Senior Network Engineer, Information Systems and Computing Networking and Telecommunications , Suite 221A /6228 University of Pennsylvania Voice:215-573-8396 FAX:215-898-9348

1 0

[Serusers] Call forward always question
by Steven C. Blair 26 Nov '08

26 Nov '08

I am experiencing an issue with server side call forward always which I didn't see before but I now believe has always existed. We recently switched phone manufacturers and now have the ability to offer bridged line appearance (BLA). Part of the process for offering BLA is to have the phones register with the shared attribute for a given line. When we enable this attribute server side call forward always breaks. When I say break I mean that the call forwards OK but the intermediate IP phone now rings which it never did before. Using ngrep I see that even with the old config we had the same message flow: Invite (from PSTN gateway)-> Invite received at proxy-> Proxy responds to gateway with 200 OK-> Proxy loads forward address from mysql usr_preferences table Proxy rewrite R-URI to the forward address - avp_pushto("$ruri/username", "s:fwdaaddr"); Proxy send invite to this new address - but... Proxy also sends invite to each contact address registered to the original AOR. This should not happen but I think it was Always happening and the old phones just ignored it. Any thoughts on why and how to correct this behavior? The ser.cfg snippets involved are included below: Determine if call forward all is on: # call forward always if (avp_db_load("$ruri/username", "s:callfwdall")) { if (avp_check("s:callfwdall","eq/y/i")) { xlog("L_INFO", "\n[SER]: [%Tf] [%ci] User <%ru> has enabled Call Forward Always\n"); avp_write("$ruri", "$ocn"); - save original RURI for voicemail access if needed if (avp_db_load("$ruri/username", "s:fwdaaddr")) { avp_pushto("$ruri/username", "s:fwdaaddr"); rewritehostport("mydomain.edu"); xlog("L_INFO", "\n[SER]: [%Tf] [%ci] Calls for user <%tu> FORWARDING to <%ru>\n"); route(2); break; }; And call relaying is done by: route[2] { xlog("L_INFO", "\n[SER]: Route block #2 campus 5-digit extensions:\n\n"); xlog("L_INFO", "\n[SER]: [%Tf] [%ci] Route block #2: sending oncampus call from <%fu> to local gateway\n"); avp_write("65", "inv_timeout"); rewritehostport("my-gwy-ip-address:5060"); t_on_failure("1"); # for gwy failover t_relay(); break; }; Thanks,Steve

1 0

[Kamailio-Users] Statistic in openser
by ALAEDDINE abbech 26 Nov '08

26 Nov '08

Hi, I know the commande #openserctl monitor and # openserctl fifo get_statistics all But i like have the number of INVITE / second in openser and the succeful INVITE/second. Who know any commande to have this statistic? thanks

3 2

Re: [Kamailio-Users] UAC on ACK in reInvite
by Schober Walter 26 Nov '08

26 Nov '08

See below... > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Wednesday, November 26, 2008 1:21 AM [...] > > This is clearly a bug in the useragent. The route set must not be > changed with reINVITEs. Thus, according to the standard the > Record-Route > headers for indialog requests are not needed. Maybe you are calling > record_route() for indialog requests and this confuses the client. Fully agree on this. But some proxies add Record-Route, some don't, Openser/Kamailio can configure it. It's not that clear in the RFC, but I see it the same way: RFC 3261, 12.2 Request within a Dialog ... Requests within a dialog MAY contain Record-Route and Contact header fields. However, these requests do not cause the dialog's route set to be modified, although they may modify the remote target URI. 12.2.1.2 Processing the Responses -> The only thing mentioned is that the _Target URI_ gets refreshed by the 200 OK. => reInvites do not modify the routeset of any subsequent request, neither the ACK not any other upcoming request. > Try removing the record_route() for indialog requests - may then the > buggy client remembers the original route set. Done. Client sends ACK on reInvite directly then :-( Counterpath is OK, Teles Voipbox not, other clients to be tested ... So I will have to add vsf uri param from Route to record route in the proxy. This at least is a reason to upgrade :-) It's done more easily with tranformations. Thanks for the discussion! For me it's "clearly a bug in the UA" now, too ;-) However, let's find a workaround. br Walter

2 1

[Kamailio-Users] avp assignment in openser 1.1
by ALAEDDINE abbech 26 Nov '08

26 Nov '08

Hi all, I have openser 1.1.0 and i can't do any change before i'm certain. can i write this code or we have an other syntaxe with version 1.1. $avp(s:PAI):= '"' + $fU + '" ' + '<sip:01010101010@192.222.115.213:5060>'; append_hf("P-Asserted-Identity: $avp(s:PAI)\r\n"); thanks

3 2

[Kamailio-Users] disply name RFC 3325
by ALAEDDINE abbech 26 Nov '08

26 Nov '08

Hi, I want to disply a number "010101010101" with use of RFC 3325 in openser. I read the RFC 3325 but i don't understand how do it. Where i put this number ? in diply name in P-Asserted-Identity, in username in P-Asserted-Identity ,in diply name in FROM or in username in FROM ?

4 5

[Kamailio-Users] replace the ' sip to' header
by BERGANZ François 26 Nov '08

26 Nov '08

Hello, I need to change the to sip header. How can I do it? Cordialement, BERGANZ François cid:image001.gif@01C8F7CD.6BC1D2C0 http://www.acropolistelecom.net <http://www.acropolistelecom.net/> P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

3 2

[Kamailio-Users] avp assignment in openser 1.1
by ALAEDDINE abbech 26 Nov '08

26 Nov '08

Hi all, I have openser 1.1.0 and i can't do any change before i'm certain. can i write this code or we have an other syntaxe with version 1.1. $avp(s:PAI):= '"' + $fU + '" ' + '<sip:01010101010@192.222.115.213:5060>'; append_hf("P-Asserted-Identity: $avp(s:PAI)\r\n"); thanks

1 0

Re: [Kamailio-Users] UAC on ACK in reInvite
by Schober Walter 26 Nov '08

26 Nov '08

Hi Klaus! Thanks for the hint! Indeed looking into the vsf=xxx parameter a little bit closer, I found out, that on the reInvite the uac_replace() is done due to the Route: vsf=xxx Param (knew that :-), but the vsf=xxx is not added again on to the Record-Route (missed that :-). So the 2nd 200 OK doesn't contain it in the route-set anymore, thus the following ACK doesn't have it in the Route Header. Is it up to me to add it to Record-Route Header, if the Route Header contains these parameters? Shouldn't the uac_replace() do that on replacing the From again? Let's see, what I can do here. Br Walter -----Ursprüngliche Nachricht----- Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Gesendet: Dienstag, 25. November 2008 18:04 An: Schober Walter Cc: users(a)lists.kamailio.org Betreff: Re: [Kamailio-Users] UAC on ACK in reInvite Hi Walter! Automatic restoring uses record route parameters to store the original from URI. Maybe there is something wrong with the RR header. I can not remember any changes in UAC module, thus I am not sure if an update will help you. regards klaus Schober Walter wrote: > Hello All! > > Tried to fix that anyhow but without success yet. Anyone who could > just tell me, if it's fixed in 1.4.something? > > Scenario: > A -> Openser 1.1.1 -> Openser 1.1.1 -> Openser 1.1.1 (UAC:normalize > From to phone number in national format) -> B > > A Invites B => all OK > A reInvites B with T.38 -> INVITE => OK > <- 200 OK => OK > -> ACK => From field not handled by UAC. > > UAC config all default, so UAC restore mode "auto". Neither INVITE nor > ACK get's uac_replace'd in if(loose_route()) block, but INVITE get's > handled properly. > > Upgrading to 1.4 or 1.3 is risky - or is it not? ;-) - because never > touch a running system, isn't it? > But then that customer comes with that Allied Telesis CPE :-) (And Ati > blames the proxy for not matching the ACK in the CPE although they use > a from-tag, too). > > Many Thanks! > br > Walter > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

2 1

[Kamailio-Users] UAC on ACK in reInvite
by Schober Walter 25 Nov '08

25 Nov '08

Hello All! Tried to fix that anyhow but without success yet. Anyone who could just tell me, if it's fixed in 1.4.something? Scenario: A -> Openser 1.1.1 -> Openser 1.1.1 -> Openser 1.1.1 (UAC:normalize From to phone number in national format) -> B A Invites B => all OK A reInvites B with T.38 -> INVITE => OK <- 200 OK => OK -> ACK => From field not handled by UAC. UAC config all default, so UAC restore mode "auto". Neither INVITE nor ACK get's uac_replace'd in if(loose_route()) block, but INVITE get's handled properly. Upgrading to 1.4 or 1.3 is risky - or is it not? ;-) - because never touch a running system, isn't it? But then that customer comes with that Allied Telesis CPE :-) (And Ati blames the proxy for not matching the ACK in the CPE although they use a from-tag, too). Many Thanks! br Walter

2 1

Re: [Kamailio-Users] Username vs DID
by ingdavidcespedes＠cable.net.co 25 Nov '08

25 Nov '08

----- Mensaje original ----- De: Matteo D'Amato <matteo(a)ecosma.com> Fecha: Martes, Noviembre 25, 2008 10:12 am Asunto: [Kamailio-Users] Username vs DID > Yes I am using a PSTN Gateway, should I create a new table to hold > the link between the username and DID or do I use the information > in the alias table? > > And there may be some local calls between users, so are you saying > it would have been easier to use their actual DID numbers as their > usernames? I have seen something like this ie: PSTN Number: 7565079 Internal Extension:5079 So you use as username= 5079, and PSTN number 7565079. But it's always better, I think, to have internal user names as "John" and associate its DID only when he is trying to reach the PSTN, adding the RFC 3325 header field P-Asserted-Identity with the DID number. > --Matteo

2 1

[Serusers] problem getting calls to my gateway
by G. Ricca 25 Nov '08

25 Nov '08

1 0

[Kamailio-Users] Username vs DID
by Matteo D'Amato 25 Nov '08

25 Nov '08

Hello, I have users with one or more DID numbers assigned to them and some with none. What is the standard convention when choosing usernames? Initially I started with usernames with the following format 1001,1002,etc however when a user dials a number their username shows up instead of their DID. I'm assigning DID with the alias command. Is there a way to show their DID number or do I need to change the way I create usernames? --Matteo

2 3

[Kamailio-Users] 100% CPU and crashed coredump available
by Ali Jawad 25 Nov '08

25 Nov '08

Hi I have a high end server and only openser + a couple of calls running, I was not able to logon to the server using my softphone anymore. The server in question is Openser 1.3 The dump file core can be found at http://www.4shared.com/file/72990148/8dca8efd/core.html Regards

3 4

[Kamailio-Users] caller id on AS5350XM
by Mark Anthony C. Delfin 25 Nov '08

25 Nov '08

Hi List, We have some issue when we are restricting caller id to a particular sip carrier using a Cisco 5350XM. The cisco 5350XM sends the from header as From: "anonymous" <sip:0xxxxxx0@xx.yy.zz.99 <sip%3A0282073300(a)202.85.241.99>>;tag=1F480924-17D9 but the sip provider's SBC is case sensitive and requires From: "Anonymous" <sip:0282073300@xx.yy.zz.99<sip%3A0282073300(a)202.85.241.99> >;tag=1F480924-17D9. I can't find a config on Cisco to change anonymous to Anonymous. Does anyone knows how to change this on the AS5350XM. Thank you. Regards, Mark Anthony C. Delfin

2 1

[Kamailio-Users] OpenSER v1.3.4 released
by Daniel-Constantin Mierla 24 Nov '08

24 Nov '08

Hello, a new release in 1.3 series is out. OpenSER (new project name: Kamailio) 1.3.4 is based on the latest version of branch 1.3, including many fixes in code and documentation, therefore those running 1.3.x are advised to upgrade. Source tarballs are available at: http://www.kamailio.org/pub/kamailio/1.3.4/src/ <http://www.kamailio.org/pub/openser/1.3.4/src> Detailed changelog: http://www.kamailio.org/pub/openser/1.3.4/ChangeLog Download via SVN: svn co https://openser.svn.sourceforge.net/svnroot/openser/branches/1.3 kamailio Tag for this release can be browsed at: http://openser.svn.sourceforge.net/viewvc/openser/tags/1.3.4/ Project site at SourceForge.net: http://sourceforge.net/projects/openser/ Modules' documentation: http://www.kamailio.org/docs/modules/1.3.x/ <http://www.kamailio.org/docs/modules/1.3.x> What is new in 1.3.x release series is summarized in the announcement of v1.3.0: http://www.kamailio.org/mos/view/OpenSER-v1.3.x-Release-Notes/ <http://www.kamailio.org/mos/view/OpenSER-v1.3.x-Release-Notes> /Note: Kamailio is the new name of OpenSER project. First version under Kamailio name was 1.4.0. Older versions will continue to use OpenSER name. / Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

Re: [Kamailio-Users] Is PRACK Supported?
by ingdavidcespedes＠cable.net.co 24 Nov '08

24 Nov '08

Thanks Alex That was exactly what I wanted to know, if it could relay PRACK messages and associate them with the corresponding provisional response message. ----- Mensaje original ----- De: Alex Balashov <abalashov(a)evaristesys.com> Fecha: Lunes, Noviembre 24, 2008 2:28 pm Asunto: Re: [Kamailio-Users] Is PRACK Supported? > Yes. But it is up to the endpoint to send the PRACK in response to > a > non-100 provisional message sent reliably, not the proxy, so > Kamailio > doesn't really need to 'support' anything related to the PRACK > method > other than relaying it, which it will. > > ingdavidcespedes(a)cable.net.co wrote: > > > Hi > > > > Does anyone know if RFC 3262 and its PRACK response are > supported by Kamailio? How can I implement it? > > > > Thanks in advance. > > > > David Cespedes > > > > > > _______________________________________________ > > Users mailing list > > Users(a)lists.kamailio.org > > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > > > -- > Alex Balashov > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > Mobile : (+1) (706) 338-8599 >

3 3

[Kamailio-Users] Is PRACK Supported?
by ingdavidcespedes＠cable.net.co 24 Nov '08

24 Nov '08

Hi Does anyone know if RFC 3262 and its PRACK response are supported by Kamailio? How can I implement it? Thanks in advance. David Cespedes

2 1

[Kamailio-Users] About http_query function and HTTP replies > 400
by Iñaki Baz Castillo 24 Nov '08

24 Nov '08

Hi, I see in the code: ----------- curl_easy_getinfo(curl, CURLINFO_HTTP_CODE, &stat); if ((stat >= 200) && (stat < 400)) { at = index(stream, (char)10); /* search for line feed */ if (at == NULL) { at = stream; /* set empty string */ } val.rs.s = stream; val.rs.len = at - stream; val.flags = PV_VAL_STR; dst = (pv_spec_t *)_dst; dst->setf(_m, &dst->pvp, (int)EQ_T, &val); } return stat; ----------- So if the reply is > 400 then the function doesn't extract the first line of the body. While it makes sense (if a web server returns 404 it means that the page has not been found so the body doesn't matter at all). But I'm trying to use "http_query" as a logic mechanism: - alice calls bob. - Kamailio asks a http server a query: http://web_server/check_permission.php?fu=alice&ru=bob - The web server runs its own logic (asking to BD and so) and decides that alice is not allowed to call bob. But bob wants to "explain" alice why he doesn't accept calls from him, so the web server replies: ----------------- HTTP/1.1 403 Forbidden Alice, you are very boring and I don't accept more calls from you ----------------- - So the $retcode of "http_query" would be 403 but we are also interested in the body (stored in $var(reply_http_query)) since we could generate a response like: sl_send_reply(403, "$var(reply_http_query)"); Doesn't it make sense? Also, web server could reply "HTTP/1.1 302 Moved temporaly" being the first line of the body the new SIP URI to contact. Opinions? BTW it could be really great if the reply body could be more complete, for example storing more than one line (various variables) and so... Regards. -- Iñaki Baz Castillo

1 0

Re: [Kamailio-Users] append_hf
by Matteo D'Amato 24 Nov '08

24 Nov '08

Hello, I'm trying to append trunk group information to my Contact header so I'm, using append_hf as follows append_hf("tgrp=30001 \r\n", "Contact"); but it seems to go on the second line. How do I remove the line feed? Max-Forwards: 69. Contact: <sip:1001@192.168.1.2:44114>. tgrp=DMS19 . --Matteo

3 8

[Serusers] REGISTER control based on UA
by inge 24 Nov '08

24 Nov '08

Hi all, I look for a workaround to use a white list in addition of authentification proces, based on User-Agent (ie. for example : deny "Asterisk IPBX" permit "Cisco IPhone...") I think to use permissions module, but I don't find an example of this usage. Thanks for your support. Regards, A. LEMOINE

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users November 2008