Hello mates, Is it possible to use A2bill to correctly obtain the CDRs and bill OpenSER subscribers who only use Asterisk as a PSTN GTW in just a single MySQL view without need of replicating them again into another Asterisk MySQL database? WBR, LU.
On Tue, 2007-10-23 at 14:25 +0200, [EMAIL PROTECTED] wrote: > Send Users mailing list submissions to > users@openser.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://openser.org/cgi-bin/mailman/listinfo/users > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Users digest..." > > > Today's Topics: > > 1. "480 User not responding" instead of "408 Request Timeout" > when modparam("tm", "noisy_ctimer", 1)? (I?aki Baz Castillo) > 2. INVITE relayed with missing bytes (Papadopoulos Georgios) > 3. "480 User not responding" instead of "408 Request Timeout" > when modparam("tm", "noisy_ctimer", 1)? (Juha Heinanen) > 4. Re: "480 User not responding" instead of "408 Request > Timeout" when modparam("tm", "noisy_ctimer", 1)? (I?aki Baz Castillo) > 5. Re: case sensitivity with avp_db_load (Jiri Kuthan) > 6. Bug in 200 to CANCEL (wrong To_tag) (I?aki Baz Castillo) > 7. Re: About "q" values (Klaus Darilion) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 23 Oct 2007 12:29:02 +0200 > From: I?aki Baz Castillo <[EMAIL PROTECTED]> > Subject: [OpenSER-Users] "480 User not responding" instead of "408 > Request Timeout" when modparam("tm", "noisy_ctimer", 1)? > To: users@openser.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="utf-8" > > Hi, if modparam("tm", "noisy_ctimer", 1) and INVITE exceded "fr_inv_timer" > then OpenSer sends "408 Request Timeout" to caller and CANCEL to called. > > I'm sure this is correct according to RFC, but wouldn't be better replying > with "480 User not responding"? > > For example, Asterisk does nothing if it receives "408 Request Timeout" (it > ignores it). I've reported about about it: > http://bugs.digium.com/view.php?id=11058 > > Sure it's a fail of Asterisk who shoud accept "408" and terminate the call, > but anyway, wouldn't be correct to reply with "480" instead of "408"? > > Regards. > > > -- > Iaki Baz Castillo > > > > ------------------------------ > > Message: 2 > Date: Tue, 23 Oct 2007 13:36:02 +0300 > From: "Papadopoulos Georgios" <[EMAIL PROTECTED]> > Subject: [OpenSER-Users] INVITE relayed with missing bytes > To: <users@openser.org> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > Hello all, > > I am noticing that OpenSER relays an INVITE and the packet that is sent > out is clipped. You can see in the following packets that the forwarded > packet is missing a few bytes from the SDP part. Counting the bytes > shows that the outgoing packet is always 1512 bytes. Is this something > that has do with OpenSER (module parameter, compile options) or is it OS > related? > > thank you for any help > > George > > > > U 2007/10/23 13:27:46.165232 213.5.1.6:57665 -> 213.5.43.4:5060 > INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0. > Via: SIP/2.0/UDP > 213.5.1.6:5060;x-route-tag="cid:CID-ACN-3@213.5.1.6";branch=z9hG4bK1594C > 1AB9. > Remote-Party-ID: "GEOP Papadopoul" > <sip:[EMAIL PROTECTED]>;party=calling;screen=no;privacy=off. > From: "GEOP Papadopoul" <sip:[EMAIL PROTECTED]>;tag=237E8130-1821. > To: <sip:[EMAIL PROTECTED]>. > Date: Tue, 23 Oct 2007 10:27:46 GMT. > Call-ID: [EMAIL PROTECTED] > Supported: 100rel,timer,resource-priority,replaces. > Min-SE: 1800. > Cisco-Guid: 1848010793-2156466652-3218142496-4228086245. > User-Agent: Cisco-SIPGateway/IOS-12.x. > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, > SUBSCRIBE, NOTIFY, INFO, REGISTER. > CSeq: 101 INVITE. > Max-Forwards: 70. > Timestamp: 1193135266. > Contact: <sip:[EMAIL PROTECTED]:5060>. > Call-Info: > <sip:213.5.1.6:5060>;method="NOTIFY;Event=telephone-event;Duration=2000" > . > Expires: 180. > Allow-Events: telephone-event. > Content-Type: application/sdp. > Content-Disposition: session;handling=required. > Content-Length: 290. > . > v=0. > o=CiscoSystemsSIP-GW-UserAgent 5211 453 IN IP4 213.5.1.6. > s=SIP Call. > c=IN IP4 213.5.1.6. > t=0 0. > m=audio 16454 RTP/AVP 18 0 8 100. > c=IN IP4 213.5.1.6. > a=rtpmap:18 G729/8000. > a=fmtp:18 annexb=yes. > a=rtpmap:0 PCMU/8000. > a=rtpmap:8 PCMA/8000. > a=rtpmap:100 X-NSE/8000. > a=fmtp:100 192-194. > > > U 2007/10/23 13:27:46.173826 213.5.43.4:5060 -> 213.5.1.6:57665 > SIP/2.0 100 Giving a try. > Via: SIP/2.0/UDP > 213.5.1.6:5060;x-route-tag="cid:CID-ACN-3@213.5.1.6";branch=z9hG4bK1594C > 1AB9;rport=57665. > From: "GEOP Papadopoul" <sip:[EMAIL PROTECTED]>;tag=237E8130-1821. > To: <sip:[EMAIL PROTECTED]>. > Call-ID: [EMAIL PROTECTED] > CSeq: 101 INVITE. > Server: Altec Telecoms SIP Proxy. > Content-Length: 0. > . > > > U 2007/10/23 13:27:46.174241 213.5.43.4:5060 -> 213.5.17.226:5060 > INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0. > Record-Route: <sip:213.5.43.4;lr=on;ftag=237E8130-1821>. > Via: SIP/2.0/UDP 213.5.43.4;branch=z9hG4bK4acd.5092baa7.0. > Via: SIP/2.0/UDP > 213.5.1.6:5060;rport=57665;x-route-tag="cid:CID-ACN-3@213.5.1.6";branch= > z9hG4bK1594C1AB9. > Remote-Party-ID: "GEOP Papadopoul" > <sip:[EMAIL PROTECTED]>;party=calling;screen=no;privacy=off. > From: "GEOP Papadopoul" <sip:[EMAIL PROTECTED]>;tag=237E8130-1821. > To: <sip:[EMAIL PROTECTED]>. > Date: Tue, 23 Oct 2007 10:27:46 GMT. > Call-ID: [EMAIL PROTECTED] > Supported: 100rel,timer,resource-priority,replaces. > Min-SE: 1800. > Cisco-Guid: 1848010793-2156466652-3218142496-4228086245. > User-Agent: Cisco-SIPGateway/IOS-12.x. > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, > SUBSCRIBE, NOTIFY, INFO, REGISTER. > CSeq: 101 INVITE. > Max-Forwards: 10. > Timestamp: 1193135266. > Contact: <sip:[EMAIL PROTECTED]:57665>. > Call-Info: > <sip:213.5.1.6:5060>;method="NOTIFY;Event=telephone-event;Duration=2000" > . > Expires: 180. > Allow-Events: telephone-event. > Content-Type: application/sdp. > Content-Disposition: session;handling=required. > Content-Length: 290. > P-hint: NATed client request. > . > v=0. > o=CiscoSystemsSIP-GW-UserAgent 5211 453 IN IP4 213.5.1.6. > s=SIP Call. > c=IN IP4 213.5.1.6. > t=0 0. > m=audio 16454 RTP/AVP 18 0 8 100. > c=IN IP4 213.5.1.6. > a=rtpmap:18 G729/8000. > a=fmtp:18 annexb=yes. > a=rtpmap:0 PCMU/8000. > a=rtpmap:8 PCMA/8000. > a=rtpmap:100 X-NSE/8000. > a=fmtp:100 > > > Disclaimer > The information in this e-mail and any attachments is confidential. It is > intended solely for the attention and use of the named addressee(s). If you > are not the intended recipient, or person responsible for delivering this > information to the intended recipient, please notify the sender immediately. > Unless you are the intended recipient or his/her representative you are not > authorized to, and must not, read, copy, distribute, use or retain this > message or any part of it. E-mail transmission cannot be guaranteed to be > secure or error-free as information could be intercepted, corrupted, lost, > destroyed, arrive late or incomplete, or contain viruses. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://openser.org/pipermail/users/attachments/20071023/eb97b4a3/attachment-0001.htm > > ------------------------------ > > Message: 3 > Date: Tue, 23 Oct 2007 13:36:10 +0300 > From: [EMAIL PROTECTED] (Juha Heinanen) > Subject: [OpenSER-Users] "480 User not responding" instead of "408 > Request Timeout" when modparam("tm", "noisy_ctimer", 1)? > To: I?aki Baz Castillo <[EMAIL PROTECTED]> > Cc: users@openser.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=iso-8859-1 > > Iaki Baz Castillo writes: > > > Sure it's a fail of Asterisk who shoud accept "408" and terminate the > call, > > but anyway, wouldn't be correct to reply with "480" instead of "408"? > > 480 is "temporarily unavailable", and it is returned if the requested > sip ua is not currently online, i.e., has not registered itself and > there is thus no contact to try. > > -- juha > > > > ------------------------------ > > Message: 4 > Date: Tue, 23 Oct 2007 12:49:09 +0200 > From: I?aki Baz Castillo <[EMAIL PROTECTED]> > Subject: Re: [OpenSER-Users] "480 User not responding" instead of "408 > Request Timeout" when modparam("tm", "noisy_ctimer", 1)? > To: users@openser.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > El Martes, 23 de Octubre de 2007, Juha Heinanen escribi: > > Iaki Baz Castillo writes: > > > Sure it's a fail of Asterisk who shoud accept "408" and terminate the > > > call, but anyway, wouldn't be correct to reply with "480" instead of > > > "408"? > > > > 480 is "temporarily unavailable", and it is returned if the requested > > sip ua is not currently online, i.e., has not registered itself and > > there is thus no contact to try. > > Yes, you are right, Asterisk confused me since means 480 as "480 User not > responding" that sounds Ok but is not the real definition. > > In this case the only solution is hoping Asterisk developers fix it. > > Thanks. > > > -- > Iaki Baz Castillo > > > > ------------------------------ > > Message: 5 > Date: Tue, 23 Oct 2007 12:52:21 +0200 > From: Jiri Kuthan <[EMAIL PROTECTED]> > Subject: Re: [OpenSER-Users] case sensitivity with avp_db_load > To: Christian Schlatter <[EMAIL PROTECTED]> > Cc: "users@openser.org" <users@openser.org> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > At 18:46 19/10/2007, Christian Schlatter wrote: > >Jiri Kuthan wrote: > >>At 17:34 19/10/2007, Christian Schlatter wrote: > >> > >>>I don't understand why [EMAIL PROTECTED] is not unique enough? > >>sometimes it is [EMAIL PROTECTED], sometimes [EMAIL PROTECTED], > >>sometimes it is [EMAIL PROTECTED] or even worse you can take your spouses' > >>name and from day D you begin to be [EMAIL PROTECTED], and your company > >>gets acquired and you become [EMAIL PROTECTED] (Which clients without > >>DNS/SRV can try to reach as [EMAIL PROTECTED], and those who pay > >>extra respect to you using capital letters as [EMAIL PROTECTED]) > >>The implication to sanity of data in usrloc, accounting and other tables is > >>immense > >>if you don't bring those to a common denominator. Any change to any name > >>becomes > >>a real pain. The point is names do changes, use of numbers is designed to > >>make > >>relations between tables invariable. > > > >Ok, this makes sense e.g. for foreign key relationships, > > yes. > > >but isn't this more of a database specific thing? > > > Well, I have though of it from SER angle with mysql usage and can't easily > relieve myself > from that viewpoint and may be a bit confused too -- how do you think a > database-centric > model would look like? > > I understand that for example the case-sensitive bit can be set as part of DB > scheme > definition -- is that the kind of things you have on your mind? > > In which case a counter-argument would be, that case-sensitiviness is a > matter of local > policy (i.e. app) which is more dynamic (e.g. per-domain) than schema > definition is. > How would a DB-specific way of dealing with things handle multiple aliases? > (cs|christian|....)? > > If that's it, what is the division line between app's and databases > responsibility? > > > We are using our university's LDAP based identity management system to > > manage SIP accounts, and openser accesses this system directly through > > H.350. Our assumption is that the SIP proxy shouldn't care about identity > > management at all, so it doesn't care if it is [EMAIL PROTECTED] or [EMAIL > > PROTECTED] > > I'm not sure what it means it doesn't care.... who does resolve aliases > for users (cristian|cs) and domains (.net|.com) so that whatever comes out > of it can be matched to for example accounting data? who take care of > case-sensitivness? > > > >You're raising a good point, but I think identity management should not be > >done in the SIP proxy. > > Actually what is "identity managment" -- it became a bit too popular > expresssion > so that its meaning is a bit fluid to me... anyhow, I will be thankful for > any hints. > Identity is indeed very important. > > > > >>>According to RFC 3261 section 19.1.4, SIP usernames are case sensitive, so > >>>you actually shouldn't convert them to upper/lower-case. > >>That's a protocol thing. An example implication is that you shall not > >>forward SIP request > >>to other domains whilst changing the URI. > >>However, if you are processing a request for your domain, you own the > >>username and the way > >>you process it is subject to your policy. You can use an LDAP alias to > >>expand to > >>other URI, you can do call-forwarding by rewriting the URI to something > >>completely > >>else, you can expand a speed-dial to a full URI, you can do anything you > >>desire > >>with the username you own. I personally prefer to ignore case, but the key > >>point > >>is you are allowed to and should set a coherent policy on how you deal with > >>names. > > > >I had to find out the hard way that asterisk is treating SIP usernames case > >sensitive which lead to the decision that it is the safest to handle SIP > >usernames case sensitive everywhere. > > It is actually a reasonable policy (at least from my POV), but a policy > should not be hardwired in code. > > -jiri > > > >Your're right though that this is a matter of local policy. > > > >/Christian > > > >>>And user/domain aliases is a different issue since it always involves some > >>>kind of alias mapping lookup. > >>That's the separate things following the same scheme indeed. If you don't > >>want to > >>do a data migration story on any name change, use IDs, for example UUIDs. > >>-jiri > >> > >>>/Christian > >>> > >>>>See above inline for what happens when you do it other ways. In any case > >>>>that's how unambiguous behaviour shall be achieved in a "water-proof" way. > >>>> > >>>>>So, I do not see any fundamental error here, given the subject of the > >>>>>discussion. > >>>>looking up user data by his username as opposed to by id is just very > >>>>poor idea, > >>>>let's face it. (those familiar with unix may find too that usernames are > >>>>used > >>>>as input/output user-interface thing, but the OS actually operates over > >>>>numbers) > >>>>The funny part is that getting things right is apparently not a big deal > >>>>in this > >>>>case, but getting it wrong can cause big headaches. > >>>>I am not sure though what of it is coding and what of it is configuration > >>>>thing in openser, I'm sure some will know. > >>>>-jiri > >>>> > >>>> > >>>>-- > >>>>Jiri Kuthan http://iptel.org/~jiri/ > >>>> > >>>>_______________________________________________ > >>>>Users mailing list > >>>>Users@openser.org > >>>>http://openser.org/cgi-bin/mailman/listinfo/users > >>> > >>> > >>>-- > >>>Jiri Kuthan http://iptel.org/~jiri/ > > > > > > > >-- > >Jiri Kuthan http://iptel.org/~jiri/ > > > > > ------------------------------ > > Message: 6 > Date: Tue, 23 Oct 2007 13:47:33 +0200 > From: I?aki Baz Castillo <[EMAIL PROTECTED]> > Subject: [OpenSER-Users] Bug in 200 to CANCEL (wrong To_tag) > To: users@openser.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="utf-8" > > Hi, > > If Asterisk CANCEL a call to OpenSer then Asterisk resends the CANCEL many > times because it ignores the 200 OK from OpenSer. > > I think this is an OpenSer bug because the 200 OK to the CANCEL contains a > To_tag different of the To_tag in the 180 (RFC 3261 in 9.2 says they SHOULD > be the same To tag). > > I've reported the bug but sincerely I'd like you to read it since I'm sure > many people work with Asterisk and OpenSer and could know something about > this CANCEL issue: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1818469&group_id=139143&atid=743020 > > Thanks for any comment. > > > -- > Iaki Baz Castillo > > > > ------------------------------ > > Message: 7 > Date: Tue, 23 Oct 2007 14:27:02 +0200 > From: Klaus Darilion <[EMAIL PROTECTED]> > Subject: Re: [OpenSER-Users] About "q" values > To: I?aki Baz Castillo <[EMAIL PROTECTED]> > Cc: users@openser.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > AFAIK SNOM phones also allow to set the q value > > Iaki Baz Castillo schrieb: > > Hi, for now I just have found a SIP device (Kphone) where I can choose "q" > > value for registration. > > > > I'd like to know if it's common to find SIP devices sending a "q" value. As > > I've seen, most of them send nothing so I use my "default_q" value 500 (0,5 > > in fact). > > > > In case there are comon devices sending a "q" in registration, what value > > is > > that "q"? > > > > I need to know it in order to make a serial forwarding adding contacts from > > a > > web application and playing with "q" value. > > > > Thanks a lot. > > > > > > ------------------------------ > > _______________________________________________ > Users mailing list > Users@openser.org > http://openser.org/cgi-bin/mailman/listinfo/users > > > End of Users Digest, Vol 29, Issue 70 > ************************************* _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
