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
