Dr Jonathan, As is clear , there is no formal mechanism for "packet based" billing.SIP applications assume "call duration " based billing.At this point of time ,I have following questions in mind:
1. Should it be made mandatory to handle message body in BYE method ? 2. Should there be mechanism to choose billing type at the time of user registeration? UA may register one billing type while SIP registrar may send another billing type in 2xx response to register method . This will require another header field (say, "billing-type:") 3. Should there be different billing type allowed for audio and video in the same call? Is this mechanism required? 4. Can SIP proxy enforce media routing through it? Ofcourse , in this case billing record generation will not be required at UA . waiting for ur response regards, vishal Prasanna writes: > Dr. Jonathan, > I accept that this idea is not a standardized practice and there is not > currect consensus on the handling of the bodies in non-INVITE messages and > in fact the non-sdp messages. But if we have to communicate some kind of > call charging from a switch, there is no way that we can do it as of now. > Even in a case of a pre-paid card service if the user needs to be > communicated with the money left in his card after the call is over, it is > quite impossible to communicate that to the terminal. > If the usage of ours have a lot of problems, I would be interested in > knowing what kind of dangers this leads to. Also can some explanation be > given what should a terminal do in a case it receives a html/text body in a > non-2xx final response for an INVITE indicating some kind of failure. This > body may contain a text explanation of why the call failed, for the status > line and even the warning header have their length limitations. > > Thanks for the response in advance. > Regards, > Prasanna > Huawei Technologies > Shenzhen. > > -----Original Message----- > From: Jonathan Rosenberg [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 05, 2002 12:11 PM > To: Prasanna > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] Body in BYE message?? > > > Any SIP request or response can carry a body. However, don't magically > expect interop just because its allowed. The only specified usage for > that at the moment is with SIP-T, where it carries the ISUP release > message. > > Usage to carry voicexml <exit> parameters, or to carry charging > infomration (although I think thats an awful idea and fraught with > peril), are not standardized at this time, would not interoperate, and > therefore should be considered proprietary. If you have such ideas, > please bring them to the sipping group, which exists to vet these ideas > and see if they should proceed towards standardization. > > -Jonathan R. > > Prasanna wrote: >> >> Hi, >> I think it is legal to send a body in the BYE message. One of the >> typical >> uses is carrying charge information for the call as a text body or html >> body >> to be displayed to the user. It is useful in B2B UA scenarios where the >> B2B >> UA (softswitch) bills the user. >> In fact in this case the 200 for BYE shall also carry a body, which I am >> not >> sure, if it is legal? >> >> Regards, >> Prasanna >> >> Date: Mon, 03 Jun 2002 07:25:53 -0400 >> From: "M. Ranganathan" <[EMAIL PROTECTED]> >> Reply-To: [EMAIL PROTECTED] >> Organization: N.I.S.T. Advanced Networking Technologies Division >> To: [EMAIL PROTECTED] >> Subject: [Sip-implementors] Body in BYE message?? >> >> Hello! >> >> Does it make sense (is it legal) to include a body in a BYE message and >> if so, what could be its uses? >> >> Thanks in advance for your replies. >> >> Regards >> >> Ranga. >> >> -- >> >> M. Ranganathan >> N.I.S.T. Advanced Networking Technologies Division >> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899 >> Tel:301 975 3664; fax:301 590 0932 >> >> Advanced Networking Technologies for the people! >> >> --__--__-- >> >> Message: 5 >> From: Neumaerker Elke <[EMAIL PROTECTED]> >> To: "'sip-implementors mailing list'" <[EMAIL PROTECTED]> >> Date: Mon, 3 Jun 2002 15:24:45 +0200 >> Subject: [Sip-implementors] Date-header in REGISTER response >> >> Hi all, >> >> According to bis09 "the response SHOULD include a Date header field". >> >> How should be the reaction of a Registrar, if it detects a malformed >> Date-header in the REGISTER-request ? >> >> (1) Ignore it and insert a correct Date-header in the REGISTER-response >> ? >> >> (2) Ignore it and return the malformed header ? >> >> (3) Reject the REGISTER with 400 Bad Request ? >> >> Thanks for your time, >> Elke >> >> _____________________________________ >> Email : [EMAIL PROTECTED] >> >> --__--__-- >> >> Message: 6 >> Date: Mon, 03 Jun 2002 09:04:48 -0500 >> From: "Vijay K. Gurbani" <[EMAIL PROTECTED]> >> Organization: Lucent Technologies, Inc./Bell Laboratories >> To: Jonathan Rosenberg <[EMAIL PROTECTED]> >> CC: Attila Sipos <[EMAIL PROTECTED]>, >> [EMAIL PROTECTED], >> Robert Sparks >> <[EMAIL PROTECTED]> >> Subject: Re: [Sip-implementors] route sets for "Route" and >> "Record-Route" >> >> inline. >> >> Jonathan Rosenberg wrote: >> > >> > "Vijay K. Gurbani" wrote: >> > >> >>Inline. >> >> >> >>Attila Sipos wrote: >> >> >> >>>I have a question regarding section "12.2.1.1 Generating the Request" >> >>>in RFC2543 bis-09. >> >>> >> >>> >> >>> >> >>>> If the route set is not empty, and its first URI does not contain >> >>> >> >>the >> >> >> >>>> lr parameter, the UAC MUST place the first URI from the route set >> >>>> into the Request-URI, stripping any parameters that are not allowed >> >>>> in a Request-URI. The UAC MUST add a Route header field containing >> >>>> the remainder of the route set values in order, including all >> >>>> parameters. The UAC MUST then place the remote target URI into the >> >>>> Route header field as the last value. >> >>>> >> >>>> For example, if the remote target is sip:user@remoteua and the >> route >> >>>> set contains >> >>>> >> >>>> <sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4> >> >>>> >> >>>> >> >>>> The request will be formed with the following Request-URI and Route >> >>>> header field: >> >>>> >> >>>> METHOD sip:proxy1 >> >>>> Route: >> <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua> >> >>>> >> >>>The last sentence in the first paragraph says: >> >>>"The UAC MUST then place the remote target URI into the >> >>>Route header field as the last value." >> >>> >> >>>My question: >> >>>Is the remote traget URI added to the "route set"? >> >> >> >>Yes; it is appended to the Route set. >> > >> > No, that is not right. Please see Robert's response on this - Robert >> is >> > correct. >> >> I am afraid, as far as I can tell, in the particular case that Attila >> is describing above, the remote target URI will be added to the Route >> set because *the topmost entry in the Route set did NOT contain a >> "lr"*. Thus, the UA is dealing with a next hop server that is not >> -09bis compliant. >> >> From a UAC's point of view, the target URI is used as the R-URI only >> when the Route set is empty, or the first entry in the Route set >> contains an "lr" (thereby specifying a next hop server that is -09bis >> compliant). >> >> - vijay >> -- >> Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >> Wireless Networks Group/Internet Software and Services >> Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 >> Naperville, Illinois 60566 Voice: +1 630 224 0216 >> >> --__--__-- >> >> Message: 7 >> Subject: Re: [Sip-implementors] route sets for "Route" and >> "Record-Route" >> From: Robert Sparks <[EMAIL PROTECTED]> >> To: "Vijay K. Gurbani" <[EMAIL PROTECTED]> >> Cc: Jonathan Rosenberg <[EMAIL PROTECTED]>, >> Attila Sipos >> <[EMAIL PROTECTED]>, [EMAIL PROTECTED] >> Date: 03 Jun 2002 10:24:00 -0500 >> >> Vijay - >> >> What piece of text are you looking at that is leading >> you to believe that the remote target URI would be placed >> in the route set? There shouldn't be _any_ text that could be >> interpreted that way. The remote target URI and the route set are >> disjoint concepts. >> >> The first element of the route set not being a loose router >> only affects how the Route header field of a message is >> constructed, not what is in the route set. Yes - if that >> first element doesn't contain ;lr, the Remote target URI is going >> to be placed in the Route header field. But that is not the same >> thing as placing it in the route set. >> >> RjS >> >> On Mon, 2002-06-03 at 09:04, Vijay K. Gurbani wrote: >> > inline. >> > >> > Jonathan Rosenberg wrote: >> > > >> > > "Vijay K. Gurbani" wrote: >> > > >> > >>Inline. >> > >> >> > >>Attila Sipos wrote: >> > >> >> > >>>I have a question regarding section "12.2.1.1 Generating the >> Request" >> > >>>in RFC2543 bis-09. >> > >>> >> > >>> >> > >>> >> > >>>> If the route set is not empty, and its first URI does not contain >> > >>> >> > >>the >> > >> >> > >>>> lr parameter, the UAC MUST place the first URI from the route set >> > >>>> into the Request-URI, stripping any parameters that are not >> allowed >> > >>>> in a Request-URI. The UAC MUST add a Route header field >> containing >> > >>>> the remainder of the route set values in order, including all >> > >>>> parameters. The UAC MUST then place the remote target URI into >> the >> > >>>> Route header field as the last value. >> > >>>> >> > >>>> For example, if the remote target is sip:user@remoteua and the >> route >> > >>>> set contains >> > >>>> >> > >>>> <sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4> >> > >>>> >> > >>>> >> > >>>> The request will be formed with the following Request-URI and >> Route >> > >>>> header field: >> > >>>> >> > >>>> METHOD sip:proxy1 >> > >>>> Route: >> <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua> >> > >>>> >> > >>>The last sentence in the first paragraph says: >> > >>>"The UAC MUST then place the remote target URI into the >> > >>>Route header field as the last value." >> > >>> >> > >>>My question: >> > >>>Is the remote traget URI added to the "route set"? >> > >> >> > >>Yes; it is appended to the Route set. >> > > >> > > No, that is not right. Please see Robert's response on this - Robert >> is >> > > correct. >> > >> > I am afraid, as far as I can tell, in the particular case that Attila >> > is describing above, the remote target URI will be added to the Route >> > set because *the topmost entry in the Route set did NOT contain a >> > "lr"*. Thus, the UA is dealing with a next hop server that is not >> > -09bis compliant. >> > >> > From a UAC's point of view, the target URI is used as the R-URI only >> > when the Route set is empty, or the first entry in the Route set >> > contains an "lr" (thereby specifying a next hop server that is -09bis >> > compliant). >> > >> > - vijay >> > -- >> > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >> > Wireless Networks Group/Internet Software and Services >> > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 >> > Naperville, Illinois 60566 Voice: +1 630 224 0216 >> >> --__--__-- >> >> _______________________________________________ >> Sip-implementors mailing list >> [EMAIL PROTECTED] >> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> >> End of Sip-implementors Digest >> >> _______________________________________________ >> Sip-implementors mailing list >> [EMAIL PROTECTED] >> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > [EMAIL PROTECTED] FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
