[OpenSER-Users] Single MySQL view for OpenSER and Asterisk for billing

[lu]

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, users-request at openser.org wrote:
> Send Users mailing list submissions to
> 	users at 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
> 	users-request at openser.org
> 
> You can reach the person managing the list at
> 	users-owner at openser.org
> 
> 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 <ibc at aliax.net>
> Subject: [OpenSER-Users] "480 User not responding" instead of "408
> 	Request	Timeout" when modparam("tm", "noisy_ctimer", 1)?
> To: users at openser.org
> Message-ID: <200710231229.02671.ibc at aliax.net>
> 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" <geop at altectelecoms.gr>
> Subject: [OpenSER-Users] INVITE relayed with missing bytes
> To: <users at openser.org>
> Message-ID:
> 	<9DB9DF2949D8774796CB054FBEC15699077F68F2 at Tyran.int.acn.gr>
> 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:1012118204501 at 213.5.43.4:5060 SIP/2.0.
> Via: SIP/2.0/UDP
> 213.5.1.6:5060;x-route-tag="cid:CID-ACN-3 at 213.5.1.6";branch=z9hG4bK1594C
> 1AB9.
> Remote-Party-ID: "GEOP Papadopoul"
> <sip:2116872933 at 213.5.1.6>;party=calling;screen=no;privacy=off.
> From: "GEOP Papadopoul" <sip:2116872933 at 213.5.1.6>;tag=237E8130-1821.
> To: <sip:1012118204501 at 213.5.43.4>.
> Date: Tue, 23 Oct 2007 10:27:46 GMT.
> Call-ID: 6E2DF805-808911DC-AA258232-F1669B65 at 213.5.1.6.
> 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:2116872933 at 213.5.1.6: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 at 213.5.1.6";branch=z9hG4bK1594C
> 1AB9;rport=57665.
> From: "GEOP Papadopoul" <sip:2116872933 at 213.5.1.6>;tag=237E8130-1821.
> To: <sip:1012118204501 at 213.5.43.4>.
> Call-ID: 6E2DF805-808911DC-AA258232-F1669B65 at 213.5.1.6.
> 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:demo1 at 192.168.1.39: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 at 213.5.1.6";branch=
> z9hG4bK1594C1AB9.
> Remote-Party-ID: "GEOP Papadopoul"
> <sip:2116872933 at 213.5.1.6>;party=calling;screen=no;privacy=off.
> From: "GEOP Papadopoul" <sip:2116872933 at 213.5.1.6>;tag=237E8130-1821.
> To: <sip:1012118204501 at 213.5.43.4>.
> Date: Tue, 23 Oct 2007 10:27:46 GMT.
> Call-ID: 6E2DF805-808911DC-AA258232-F1669B65 at 213.5.1.6.
> 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:2116872933 at 213.5.1.6: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: jh at tutpro.com (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 <ibc at aliax.net>
> Cc: users at openser.org
> Message-ID: <18205.52890.80005.791185 at harjus.tutpro.com>
> 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 <ibc at aliax.net>
> Subject: Re: [OpenSER-Users] "480 User not responding" instead of "408
> 	Request	Timeout" when modparam("tm", "noisy_ctimer", 1)?
> To: users at openser.org
> Message-ID: <200710231249.10003.ibc at aliax.net>
> 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 <jiri at iptel.org>
> Subject: Re: [OpenSER-Users] case sensitivity with avp_db_load
> To: Christian Schlatter <cs at unc.edu>
> Cc: "users at openser.org" <users at openser.org>
> Message-ID: <20071023105243.746DB1810C5A at mail.iptel.org>
> 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 username at domain is not unique enough?
> >>sometimes it is christian at domain.com, sometimes christian.schlatter at domain.com,
> >>sometimes it is christian.schlatter at .domain.org or even worse you can take your spouses'
> >>name and from day D you begin to be christian.blair at domain.org, and your company
> >>gets acquired and you become christian.blair at oracle.com. (Which clients without
> >>DNS/SRV can try to reach as christian.blair at sip.oracle.com, and those who pay
> >>extra respect to you using capital letters as Christian.Blair at sip.oracle.com)
> >>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 christian.blair at domain.org or christian.blair at oracle.com.
> 
> 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 at 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 <ibc at aliax.net>
> Subject: [OpenSER-Users] Bug in 200 to CANCEL (wrong To_tag)
> To: users at openser.org
> Message-ID: <200710231347.33877.ibc at aliax.net>
> 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 <klaus.mailinglists at pernau.at>
> Subject: Re: [OpenSER-Users] About "q" values
> To: I?aki Baz Castillo <ibc at aliax.net>
> Cc: users at openser.org
> Message-ID: <471DE896.1080708 at pernau.at>
> 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 at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
> 
> 
> End of Users Digest, Vol 29, Issue 70
> *************************************