[SIPForum-discussion] SIP Call Waiting Messages and Call Charges

Thu Oct 6 13:27:45 UTC 2011

Thanks to everyone for the feedback so far.

Interesting what you mentioned Hemant on the network timeout, I had not considered this when thinking the early media would  work for this particular issue.

As far as I am aware a SIP carrier will begin charging for a call when the 200 OK reply to an INVITE has been Acknowleged?  My call flow for this was something like the below.

Does SIP carriers use any other messages/fields for billing information?

[cid:image001.jpg at 01CC8434.1D7DC7D0]

Best Regards,

Stewart Hayles
Product Specialist

 [cid:image002.gif at 01CC8434.1D7DC7D0]
NEC Infrontia Ltd
| Address: Innovation House, Mere Way, Ruddington Fields Business Park, Ruddington, Nottingham, NG11 6JS, ENGLAND
| Tel: 0115 969 5700
| Fax: 0115 931 5970
| Web: http://www.neci.co.uk<http://www.neci.co.uk/>

From: Hemant Kumar [mailto:uniqhemant at gmail.com]
Sent: 06 October 2011 12:11
To: Stewart Hayles
Cc: discussion at sipforum.org
Subject: Re: [SIPForum-discussion] SIP Call Waiting Messages and Call Charges

Hi,

>> Would the call be initially setup using early media to play the message?
You cant play early media due to following reasons -
1. Wait in the queue could be longer than the network timeouts. So there is a possibility that the call is disconnected abruptly by some network node.
 2 . There is also a possibility that the caller is put into queue after the call is established with a user (Just thinking of a customer care center).

I have very little knowledge about ACR handling by CDF but just trying to give a thought -
As the PBX has the knowledge about with whom the call is connected(End user or MRFC) so it can generate different set of START/STOP ACRs for CDF once call is established/terminated with MRFC to play announcement.

1. A calls B but call is in waiting (connected to MRFC to play announcement). Generate Start ACR having MRFC as Called Party.
2. Call is connected to End User B (after getting disconnected with MRFC). Generate Stop ACR for the MRFC call leg and Start ACR for the actual A->B call.

Leave the interpretation of ACRs(to charge or not depending on the called party) to CDF. ;-)

Actually similar sort of thing we are doing in our project but I am not sure how the CDF will act as it will not receive similar ACRs from other network nodes. (May be that is what your query is about).

Regards,
Hemant

On Wed, Oct 5, 2011 at 3:14 PM, Stewart Hayles <shayles at neci.co.uk<mailto:shayles at neci.co.uk>> wrote:
Hello all,

I have a question I hope someone out there may be able to help me with understanding a bit more clearly.

In Germany a new law is coming into effect where if a caller is held waiting on a line and listening to a queue message they are not charged for that portion of the call until a user actually picks up to speak with them.

I wondered how this would be implemented with regards to SIP carriers.  Would the call be initially setup using early media to play the message?  Is there any fields/messages used for charging information between the network and PBX?

I hope someone may have an understanding of what I am describing, would appreciate any details you may have on this if you have been involved in similar situation.

BR,

Stewart

 [https://mail.google.com/mail/?ui=2&ik=b4b3891170&view=att&th=132d798dbf426bad&attid=0.1&disp=emb&realattid=d24b22870430faa5_0.0.1&zw]
________________________________
Disclaimer - This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster at neci.co.uk<mailto:postmaster at neci.co.uk>. Any views or opinions presented in this email are solely those of the author and might not represent those of NEC Infrontia Ltd. NEC Infrontia Ltd monitor's email traffic data and also the content of email for the purposes of security. NEC Infrontia Ltd have also taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. NEC Infrontia Ltd. Registered in England: 3107691. Registered Office: Lyndhurst, 1 Cranmer Street, Long Eaton, Nottingham, NG10 1NJ. NEC Infrontia Ltd is a wholly owned subsidiary of NEC Nederland BV.

NEC Infrontia Ltd monitor's all telephone calls to and from the company for training and quality purposes.

_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org<mailto:discussion at sipforum.org>

--
- Hemant

________________________________
Disclaimer - This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster at neci.co.uk. Any views or opinions presented in this email are solely those of the author and might not represent those of NEC Infrontia Ltd. NEC Infrontia Ltd monitor's email traffic data and also the content of email for the purposes of security. NEC Infrontia Ltd have also taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. NEC Infrontia Ltd. Registered in England: 3107691. Registered Office: Lyndhurst, 1 Cranmer Street, Long Eaton, Nottingham, NG10 1NJ. NEC Infrontia Ltd is a wholly owned subsidiary of NEC Nederland BV.

NEC Infrontia Ltd monitor's all telephone calls to and from the company for training and quality purposes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20111006/76bd47ca/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 31263 bytes
Desc: image001.jpg
URL: <http://sipforum.org/pipermail/discussion/attachments/20111006/76bd47ca/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 2740 bytes
Desc: image002.gif
URL: <http://sipforum.org/pipermail/discussion/attachments/20111006/76bd47ca/attachment-0002.gif>