sr-users February 2008

sr-users@lists.kamailio.org

146 participants
260 discussions

[OpenSER-Users] Radius Acct Syntax Error?

by Drix Tabligan

Hi, A quick help from anyone please? I've compiled Openser to support radius accounting and did the necessary installations already. Freeradius is running and can do accounting and auth already when tested. I'm having a problem starting Openser 1.2. The output shows... --------------- 0(11900) set_mod_param_regex: acc matches module acc 0(11900) set_mod_param_regex: found <service_type> in module acc [/ usr/local/lib64/openser/modules/] 0(11900) set_mod_param_regex: acc matches module acc 0(11900) set_mod_param_regex: found <radius_config> in module acc [/ usr/local/lib64/openser/modules/] 0(11900) parse error (224,21-22): syntax error 0(11900) parse error (224,21-22): ERROR: bad config file (2 errors) --------------- If I comment out the modparam("acc", "radius_config", "/usr/local/etc/ radiusclient/radiusclient.conf") below, Openser runs. A snip of the openser config... --------------- modparam("acc", "acc_sip_code_column", "sip_code") modparam("acc", "acc_sip_reason_column", "sip_reason") modparam("acc", "service_type", 15) modparam("acc", "radius_config", "/usr/local/etc/radiusclient/ radiusclient.conf"); modparam("acc", "radius_flag", 0) modparam("acc", "radius_missed_flag",0) modparam("acc", "multi_leg_info", "src_leg=$avp(i:901);dst_leg=$avp(i: 902)") modparam("acc", "radius_extra", "Sip-RPid=$avp(s:rpid); \ Sip-Src-IP=$si; \ Sip-Src-Port=$sp; \ Divert-Reason=$avp(s:divert_reason); \ X-RTP-Stat=$avp(s:rtp_statistics); \ From-Header=$hdr(from); \ User-Agent=$hdr(user-agent); \ Contact=$hdr(contact); \ Event=$hdr(event); \ SIP-Proxy-IP=$avp(s:sip_proxy_ip)") -------------- Which means that radius accounting was compiled in as the other parameters doesn't spew the error. The radiusclient.conf and dictionary files are essentially untouched except for the necessary changes on the shared secret and ip addresses for the radius config. Openser, Freeradius and Radiusclient are running on the same box under FC7 64bit. Thank you in advance for your help... Drix

16 years, 9 months

Re: [OpenSER-Users] Failover using NAPTR/SRV

by Douglas Garstang

Ok, so rfc3263 defines what the user agent should do when a 503 reply, or no reply is received. What about the rest of the possible SIP replies? We use several different ITSP's. I just checked the logs for our last 50,000 calls from all of them and there was a total of 19 different replies received. They are: 200,400,401,403,404,408,410,480,484,486,487,488,500,501,502,503,504,603 Some of these can occur under normal conditions, 486 is busy for example, or 487 is generated by a CANCEL. What about the rest? Most of the rest can be classified as error conditions. Are you saying that if another error condition besides 503 is received that you don't do failover? Why? Douglas. ----- Original Message ---- From: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> To: Douglas Garstang <dougmig33(a)yahoo.com>; users openser.org <users(a)openser.org> Sent: Friday, February 15, 2008 5:56:45 AM Subject: Re: [OpenSER-Users] Failover using NAPTR/SRV Of course it is.....by IETF - see RFC3263. 4.3 Details of RFC 2782 Process Regards, Bogdan Douglas Garstang wrote: > Well that's weird. What do you mean by 'fail'? I thought dns_blacklist > was used when a 503 response was received? What if the connection > times out? What if another negative reply is received? Is this stuff > documented anywhere? > > ----- Original Message ---- > From: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> > To: Tobias Lindgren <tobias.lindgren(a)ip-only.se> > Cc: users(a)openser.org > Sent: Thursday, February 14, 2008 3:25:33 AM > Subject: Re: [OpenSER-Users] Failover using NAPTR/SRV > > Hi Tobias, > > if you have "dns_backlist=yes" in your config, if one of the destination > server fails (according to SIP definition), it's IP will be added to a > temporary blacklist (for 4 minutes) and not used. So, openser should do > dns-based failover and use the next entry provided by NAPTR/SRV/A lookup. > > Regards, > Bogdan > > Tobias Lindgren wrote: > > Hi all, > > > > I've been trying to find this information but I cannot find any exact > > specifications on how it really works. > > > > >From what I know using NAPTR/SRV records with OpenSER will allow > it to > > find and use servers behind those DNS-records. This works just fine. > > > > However, what I'm not sure about is what actually will happen in > OpenSER > > when one of two servers in this scenario would fail. > > > > For example, I have two servers as SRV where one is primary and one is > > secondary for SIP/UDP. What will happend in OpenSER when the primary > > server is down? Will OpenSER continue to send all request first towards > > that server or will it learn that one server is down and always send > > requests to the second server for a period of time and try the primary > > one just occassionally? > > > > Please direct me to any page where this is explained in detail, if such > > page exists. > > > > Br, > > /Tobias > > > > _______________________________________________ > > Users mailing list > > Users(a)lists.openser.org <mailto:Users@lists.openser.org> > > http://lists.openser.org/cgi-bin/mailman/listinfo/users > > > > > > > _______________________________________________ > Users mailing list > Users(a)lists.openser.org <mailto:Users@lists.openser.org> > http://lists.openser.org/cgi-bin/mailman/listinfo/users > > > ------------------------------------------------------------------------ > Never miss a thing. Make Yahoo your homepage. > <http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs> ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

16 years, 9 months

[OpenSER-Users] OpenSER VS. SER

by Ali Jawad

Hi All I would like to know if anyone can state the most important differences between openSER and SER in terms of features. I am not very interested in CPU and RAM consumption I would like to know if there are any differences between the two servers in terms of functionality. Thanks

16 years, 9 months

[OpenSER-Users] Survey for new mailing list

by Bogdan-Andrei Iancu

Hi all, I the last year there was a good progress on the project policy regarding releases (major and minor). Still, from my experience as booth developer and user of openser, I feel the need for way to promptly and focused inform the users of openser about the fixes, especially critical fixes, that require immediate update. Many project have lists where you can subscribe in order to get notification for critical bug or security fixes. Currently, for openser, if you are not subscribed on devel list and if you are not "good" enough in "decrypting" the commit logs, you may miss important fixes you may want to update. I think is our duty as project to inform the users about the discovered flows in the stable versions. My suggestion is to create a new mailing list where, who is interested, will receive notifications when something critical was fixed in the stable versions of openser. Maybe a new list (like "alerts(a)lists.openser.org") where a developer, after making the fix, can issue (if considered important) an update alert for the interested people : Severity: Affected services/modules: Description: Rev number where the fix is available: How to update: ? I come to this as right now I'm working at two major fixes in the stable versions affecting two important serviced - user location and accounting. And I bet a lot of people will be interested in this in order to update their installations. Please let me know your thoughts on this. Best regards, Bogdan

16 years, 9 months

[OpenSER-Users] TM-module and ACK to 2xx (doesnt terminate txn?)

by Taisto Qvist

Hi Guys, I'm having trouble with my ACK's on 2xx, and reading about the TM-module, it says for *t_check_trans()* : *ACK request - *true if the ACK is a local end-to-end ACK for an existent INVITE transaction. To me, that sounds like a contradiction in terms, since there is (rfc-wise) no transaction left after 2xx has been proxied through, and the ACK starts coming in(because of record-routing). (and my script's ACK-logic for consuming ACK for 3++ also eats the ACK for 2xx :-( ) Does the TM module not follow the rfc-described termination of invite-txn's? Then how long does the transaction live after 2xx has been forwarded? How come its implemented this way? If this is so, then how do I differentiate between an end-to-end ACK for 2xx, and a 3++ hop-by-hop ACK? I have to use flags and stuff? (Havent got that far yet in my openser understanding...) Regards Taisto Qvist Ip-Solutions.se

16 years, 9 months

[OpenSER-Users] Can we have different session identifiers for one session?

by Vikas CG.

HI all, Can we have different session identifiers for one session?? Scenario: For INVITE (Offer) im getting 200 OK (Answer). And it will have one session id at "o" line in sdp. I will send re-INVITE with different session id. Is it possible??? In RFC they have suggested to use unique identifier for session, But some sip hard phones are sending different session id's is it possible??? Plz suggest how to handle this scenario. Thanks, Vikas C.G.

16 years, 9 months

Re: [OpenSER-Users] [OpenSER-Devel] How to stop OpenSER from replying with 100 Trying?

by Henning Westerholt

On Monday 18 February 2008, Rajat Dudeja wrote: > (moved this thread to user list) > > I've even tried t_relay, but it gives 500 Application Server Error. Below > is my route logic: > route{ > if(!t_relay("0x01")) > { > sl_reply_error(); > exit; > } > if(!as_relay_t("app_server")){ > t_reply("500","Application Server error"); > } > } Hi Rajat, the as_relay_t from seas returns false, so your server returns correctly the 500. I assume that you've configured your SEAS server correctly. Please look into the log messages of your server to get some hints why this fail. You can also activate logging to the console with a config parameter if you like. If you don't spot any problems in the output, increase the debug level to get more hints. Please don't post this type of questions to the devel list. Thank you! Henning

16 years, 9 months

[OpenSER-Users] Question abour acc and failed INVITEs in 1.3

by Phil D'Amore

Hello: I have a situation where I am trying to send an INVITE to two different gateways serially. If the first gateway fails, and the second one succeeds, I would expect to see a record for the failure, and a record for the success. At least, this is the way 1.1 did it. In 1.3, I only see a record for the final success. I have both my db_flag and db_missed_flag set. Does anyone have an idea why I would not see the failure? Something new in 1.3? Thanks, Phil

16 years, 9 months

Re: [OpenSER-Users] SIP Trunk doesn't response to 200OK with an ACK

by Eric Phetteplace

On their end, they see they send an ACK after I send an OK. I sent them a tcdump file of my traffic during the session. Any suggestions? Eric

16 years, 9 months

[OpenSER-Users] SIP Trunk doesn't response to 200OK with an ACK

by Eric Phetteplace

Hello, Here's the results of an ngrep command. It is showing a situation where I make a call on the PSTN to a DID, which terminates on my SIP Trunk. OpenSER receives the INVITE, etc. and I answer with my SIP phone, my phone OKs to OpenSER, OpenSER OKs to the SIP Trunk, but the SIP Trunk never ACKS. What causes this? Thanks, Eric interface: eth0 (192.168.2.0/255.255.255.0) filter: (ip) and ( port 5060 ) # U 8.21.8.24:5060 -> 192.168.2.10:5060 INVITE sip:1001@2.6.7.9 SIP/2.0. Via: SIP/2.0/UDP 8.21.8.24:5060;branch=z9hG4bK69c359bd;rport. From: "19195551212" <sip:19195551212@8.21.8.24>;tag=as6869d7f8. To: <sip:1001@2.6.7.9>. Contact: <sip:19195551212@8.21.8.24>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. User-Agent: Vox Callcontrol. Max-Forwards: 70. Date: Sun, 17 Feb 2008 15:37:23 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Type: application/sdp. Content-Length: 311. . v=0. o=root 25921 25921 IN IP4 8.21.8.24. s=session. c=IN IP4 8.21.8.24. t=0 0. m=audio 15994 RTP/AVP 0 8 18 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. # U 192.168.2.10:5060 -> 8.21.8.24:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 8.21.8.24:5060;branch=z9hG4bK69c359bd;rport=5060. From: "19195551212" <sip:19195551212@8.21.8.24>;tag=as6869d7f8. To: <sip:1001@2.6.7.9>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. Server: OpenSER (1.3.0-notls (i386/linux)). Content-Length: 0. . # U 192.168.2.10:5060 -> 192.168.2.3:5060 INVITE sip:1001@192.168.2.3 SIP/2.0. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0. Via: SIP/2.0/UDP 8.21.8.24:5060;branch=z9hG4bK69c359bd;rport=5060. From: "19195551212" <sip:19195551212@8.21.8.24>;tag=as6869d7f8. To: <sip:1001@2.6.7.9>. Contact: <sip:19195551212@8.21.8.24>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. User-Agent: Vox Callcontrol. Max-Forwards: 69. Date: Sun, 17 Feb 2008 15:37:23 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Type: application/sdp. Content-Length: 329. P-hint: usrloc applied. . v=0. o=root 25921 25921 IN IP4 8.21.8.24. s=session. c=IN IP4 192.168.2.10. t=0 0. m=audio 35058 RTP/AVP 0 8 18 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. a=nortpproxy:yes. # U 192.168.2.3:5060 -> 192.168.2.10:5060 SIP/2.0 100 Trying. Content-Length: 0. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0,SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . # U 192.168.2.3:5060 -> 192.168.2.10:5060 SIP/2.0 180 Ringing. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0,SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . # U 192.168.2.10:5060 -> 8.21.8.24:5060 SIP/2.0 180 Ringing. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . # U 192.168.2.3:5060 -> 192.168.2.10:5060 SIP/2.0 200 OK. Content-Length: 217. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0,SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.3. t=0 0. a=direction:active. m=audio 49162 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. # U 192.168.2.10:5060 -> 8.21.8.24:5060 SIP/2.0 200 OK. Content-Length: 236. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.10. t=0 0. a=direction:active. m=audio 35060 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. a=nortpproxy:yes. # U 192.168.2.3:5060 -> 192.168.2.10:5060 SIP/2.0 200 OK. Content-Length: 217. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0,SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.3. t=0 0. a=direction:active. m=audio 49162 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. # U 192.168.2.10:5060 -> 8.21.8.24:5060 SIP/2.0 200 OK. Content-Length: 236. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.10. t=0 0. a=direction:active. m=audio 35060 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. a=nortpproxy:yes. # U 192.168.2.3:5060 -> 192.168.2.10:5060 SIP/2.0 200 OK. Content-Length: 217. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0,SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.3. t=0 0. a=direction:active. m=audio 49162 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. # U 192.168.2.10:5060 -> 8.21.8.24:5060 SIP/2.0 200 OK. Content-Length: 236. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.10. t=0 0. a=direction:active. m=audio 35060 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. a=nortpproxy:yes. # U 192.168.2.3:5060 -> 192.168.2.10:5060 BYE sip:19195551212@8.21.8.24 SIP/2.0. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Max-Forwards: 70. CSeq: 1 BYE. From: <sip:1001@2.6.7.9>;tag=35794812523426. Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. User-Agent: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.3;rport;branch=z9hG4bKc0a802030131c9b147b80e6900007d3200000019. . # U 192.168.2.10:5060 -> 8.21.8.24:5060 BYE sip:19195551212@8.21.8.24 SIP/2.0. Record-Route: <sip:192.168.2.10;lr=on;ftag=35794812523426>. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Max-Forwards: 69. CSeq: 1 BYE. From: <sip:1001@2.6.7.9>;tag=35794812523426. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. User-Agent: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bK3067.f0fdf201.0. Via: SIP/2.0/UDP 192.168.2.3;rport=5060;branch=z9hG4bKc0a802030131c9b147b80e6900007d320000001 9. P-hint: rr-enforced. . # U 192.168.2.10:5060 -> 8.21.8.24:5060 BYE sip:19195551212@8.21.8.24 SIP/2.0. Record-Route: <sip:192.168.2.10;lr=on;ftag=35794812523426>. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Max-Forwards: 69. CSeq: 1 BYE. From: <sip:1001@2.6.7.9>;tag=35794812523426. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. User-Agent: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bK3067.f0fdf201.0. Via: SIP/2.0/UDP 192.168.2.3;rport=5060;branch=z9hG4bKc0a802030131c9b147b80e6900007d320000001 9. P-hint: rr-enforced. . # U 192.168.2.3:5060 -> 192.168.2.10:5060 BYE sip:19195551212@8.21.8.24 SIP/2.0. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Max-Forwards: 70. CSeq: 1 BYE. From: <sip:1001@2.6.7.9>;tag=35794812523426. Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. User-Agent: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.3;rport;branch=z9hG4bKc0a802030131c9b147b80e6900007d3200000019. . # U 8.21.8.24:5060 -> 192.168.2.10:5060 SIP/2.0 481 Call leg/transaction does not exist. Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bK3067.f0fdf201.0;received=2.6.7.9. Via: SIP/2.0/UDP 192.168.2.3;rport=5060;branch=z9hG4bKc0a802030131c9b147b80e6900007d320000001 9. From: <sip:1001@2.6.7.9>;tag=35794812523426. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 1 BYE. User-Agent: Vox Callcontrol. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Length: 0. . # U 192.168.2.10:5060 -> 192.168.2.3:5060 SIP/2.0 481 Call leg/transaction does not exist. Via: SIP/2.0/UDP 192.168.2.3;rport=5060;branch=z9hG4bKc0a802030131c9b147b80e6900007d320000001 9. From: <sip:1001@2.6.7.9>;tag=35794812523426. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 1 BYE. User-Agent: Vox Callcontrol. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Length: 0. . exit 18 received, 0 dropped

16 years, 9 months

← Newer
1
...
10
11
12
13
14
15
16
...
26
Older →

Jump to page:

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 February 2008