Re: [Sip-implementors] Few offer/answer queries
>What is the behavior of the receiver if it receives offer with >different "session id" in >re-INVITE or UPDATE? Take down the call as REINVITE o-line with a new session id identifies a session that does not exist at UA. [Kamal] Taking down the existing call may not be a good idea, one can reject the request that contains changed SDP session-id. Instead the re-INVITE or UPDATE should be rejected. Kamal Cisco, Bangalore India -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harsha. R Sent: Tuesday, September 30, 2008 4:06 PM To: Vikram Chhibber Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Few offer/answer queries Vikram, Session id is kept constant across offers/answers sent by UAC/UAS. Only Session version is incremented for every new offer/answer sent by UAC/UAS. The reason UA *MUST NOT* change session id can probably be inferred from SDP RFC 4566, section 5.2 is a numeric string such that the tuple of , , , , and forms a globally unique identifier for the session. Therefore by changing the session id, you are changing the identifier for the session for either a UAC/UAS To answer your specific questions. >What is the behavior of the receiver if it receives offer with >different "session id" in >re-INVITE or UPDATE? Take down the call as REINVITE o-line with a new session id identifies a session that does not exist at UA. >Also, what should be the behavior of the receiver if it receives offer >with same "session id" as previous but with version incremented more >than one? IMO, a liberal implementation *SHOULD* allow this offer/answer to proceed. For me, this bears similarity to the case when CSeq is incremented more than 1 for a subsequent request from a UAC. >b) We emphasize that UAS should send back its full capability offer in >response to offer-less re-INVITE. Does that also have "SDP session >resetting" effect in the sense that the answer SDP MAY not have same "o" >line session-id as sent by remote previously? This scenario comes when >you are trying to negotiate media-session with another entity within an >established SIP dialog say network side call-transfer. In this case of forced SDP offer, UAS must use the same session id in the offer it sends, as it sent in a previous answer(in either 18X response/200 OK INVITE), and increment the session version by 1. Regards Harsha 2008/9/30 Vikram Chhibber <[EMAIL PROTECTED]> > Hi All, > > > > I have few queries on RFC 3264: An Offer/Answer Model with the Session > Description Protocol (SDP): > > > > 8 Modifying the Session > > > > When issuing an offer that modifies the session, > > the "o=" line of the new SDP MUST be identical to that in the > > previous SDP, except that the version in the origin field MUST > > increment by one from the previous SDP. > > > > The aforementioned statement defines the "o" line creation in the > offer by the sender. > > > > a) Does this also mean that the receiver must always expect same > "session id" in all the subsequent offers after initial offer/answer? > What is the behavior of the receiver if it receives offer with different "session id" > in > re-INVITE or UPDATE? Also, what should be the behavior of the receiver > if it receives offer with same "session id" as previous but with > version incremented more than one? > > Are the above scenarios "legal" for UA or should it treat these > normally and continue by following philosophy of being strict while > sending and lenient while receiving? > > > > b) We emphasize that UAS should send back its full capability offer in > response to offer-less re-INVITE. Does that also have "SDP session > resetting" effect in the sense that the answer SDP MAY not have same "o" > line session-id as sent by remote previously? This scenario comes when > you are trying to negotiate media-session with another entity within > an established SIP dialog say network side call-transfer. > > > > Thanks, > > ~Vikram > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > -- Regards Harsha ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] SIPit registration closes tomorrow
(This is the last reminder - thanks everyone on these lists for being so patient with the crossposts). Registration for SIPit 23 closes TOMORROW Friday October 3. Please register immediately if you haven't already done so. Links to the registration and more information can be found at http://www.sipit.net and http://www.etsi.org/plugtests/SIPit/SIPit.htm Thanks, and see you in Lannion week after next! RjS ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Early dialogs, reliable responses and PRACK addressing
Hello, Iñaki Baz Castillo wrote: > 2008/10/2, Dmitry Akindinov <[EMAIL PROTECTED]>: >>> For me this means that, in RFC 3261, Contact must be present in a 2xx >>> to an INVITE. >>> >> Yes, but according to this table it's optional for 1xx. And 3262 does not >> update that, though with reliable 1xx the Contact is more likely to be >> needed to address the PRACK. > > Yes, but RFc3261 updates the 1xx behaviour when it clearly says: > > RFC 3262: > -- > > 4 UAC Behavior > >The provisional response ***MUST establish a dialog*** if one is not yet > created. > --- > > And note that for a dialog to be established it's needed a remote > target (not the initial RURI). Yes, this is exactly how we get the idea of SIP dialogs, including the early ones. And that's why we want to avoid programming workarounds in our code particularly for this situation - because we believe that a 1xx without the Contact URI but requesting reliable handling is wrong. It's also not right even when reliable handling is not requested, but that does not hit us that bad :-) > So, it's true that RFC 3262 doesn't update the table, but note that > "Contact" just would be required if the 1xx includes a "Require: > 100rel", That's something we kept saying to the vendor for several month already. > so there is no need to update that table. In any case RFC > 3262 could add: > > Header field where proxy ACK BYE CAN INV OPT REG > ___ > Contact Ro - - m o o > Contact1xx - - - o- - > Contact 1xx + 100rel - - - m - - > Contact2xx - - - m o o > Contact3xx d- o - o o o > Contact485 - o - o o o It could, but it does not, unfortunately. > Well, as you say life would be better if RFC 3262 says that, but > however this is implicit by the above phrase "The provisional response > ***MUST establish a dialog*** if one is not yet created". Well, here we have a chain of reasoning (early dialog is created -> PRACK is sent within a dialog -> as an in-dialog request it should be addressed to RURI -> RURI should have been sent with 1xx -> RURI is required) versus the simple and short reference to tables in rfc3262 and 3261 not marking the Contact header as required. And for some it's hard to follow these chains. Thank you very much for your comments. I've sent the link to the list archive with this discussion to the vendor. I hope this will move the scales and they fix their SIP implementation. -- Best regards, Dmitry Akindinov ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] XML inside SIP
On Thu, Oct 2, 2008 at 12:39 PM, Manoj Priyankara (NOD) <[EMAIL PROTECTED]> wrote: > Does anyone know the usage of XML inside SIP messages (like NOTITY) ? There are tens of RFCs registering new XML-based MIME types as well as new XML namespaces. This paper [1] might be what you are looking for, though. [1] http://www1.cs.columbia.edu/~knarig/nyman.pdf -- Victor Pascual Ávila ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] sending DTMF as Notify
I'm not going to tell you how to do that because it isn't a legal sip usage. It is true that some things have been known to use unsolicited NOTIFY. I'm not certain I have heard of it for DTMF, but I have heard of it for MWI. But its still not a standard usage. The only plausible reason I can think of for you to want to do this is to interoperate with something that expects it. If that is your situation, then you need to defer to it regarding what it expects. Thanks, Paul Vivek Gupta wrote: > Hi, > > I need information on how to send DTMF tones as unsolicited Notify method > within an established dialogue. Can anyone explain the > steps to implement the same? > > Information on any SIP soft-phone that supports DTMF as Notify would be of > great of help? > > With regards, > Vivek GUpta > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Early dialogs, reliable responses and PRACK addressing
Harsha. R wrote: > ... they just refer to the fact that Tables 1 and 2 in rfc3262 extend > tables 2 and 3 in rfc3261 and the Contact is marked as optional in 1xx > responses. If 3262 clearly stated that reliable provisional responses > MUST have Contact - we would not have this issue > > Its not clear to me as to why the 18X is expecting a Contact. The purpose of > Contact is to do a target refresh. > 18X missing a Contact header means a target refresh has not happened. In > this case, address the PRACK to > the original remote target( mostly the one used for INVITE). We have had to incorporate this behavior into some of our products in order to get them to interoperate with some broken implementations. But as Iñaki has already stated, this has many issues and is not conforming behavior. Once the dialog has been established, with a target URI from a Contact, then you may omit the contact from future 1xxs if you wish. Too much is being made of the tables. Several of the people who initially put those tables in now wish they had not. The tables are insufficient to cover all the nuances. You *must* read the text to get the details. Iñaki has already cited the various sections which, taken together, mean that you MUST include a Contact to establish a dialog. Paul > If all goes well, PRACK reaches the intended UAS and call goes through; > if not, UAS will retransmit 18X (missing contact header) and your UAC will > keep sending > PRACK to the latest remote target(mostly the one used in INVITE). > After some time, UAS will take down the call on an implementation defined > timer expiry for 18x > > Regards > Harsha > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] XML inside SIP
2008/10/2, Manoj Priyankara (NOD) <[EMAIL PROTECTED]>: > > > Hi All, > > Does anyone know the usage of XML inside SIP messages (like NOTITY) ? What is exactly the question? -- Iñaki Baz Castillo <[EMAIL PROTECTED]> ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Early dialogs, reliable responses and PRACK addressing
2008/10/2, Dmitry Akindinov <[EMAIL PROTECTED]>: > > For me this means that, in RFC 3261, Contact must be present in a 2xx > > to an INVITE. > > > > Yes, but according to this table it's optional for 1xx. And 3262 does not > update that, though with reliable 1xx the Contact is more likely to be > needed to address the PRACK. Yes, but RFc3261 updates the 1xx behaviour when it clearly says: RFC 3262: -- 4 UAC Behavior The provisional response ***MUST establish a dialog*** if one is not yet created. --- And note that for a dialog to be established it's needed a remote target (not the initial RURI). So, it's true that RFC 3262 doesn't update the table, but note that "Contact" just would be required if the 1xx includes a "Require: 100rel", so there is no need to update that table. In any case RFC 3262 could add: Header field where proxy ACK BYE CAN INV OPT REG ___ Contact Ro - - m o o Contact1xx - - - o- - Contact 1xx + 100rel - - - m - - Contact2xx - - - m o o Contact3xx d- o - o o o Contact485 - o - o o o Well, as you say life would be better if RFC 3262 says that, but however this is implicit by the above phrase "The provisional response ***MUST establish a dialog*** if one is not yet created". -- Iñaki Baz Castillo <[EMAIL PROTECTED]> ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Early dialogs, reliable responses and PRACK addressing
Hello, Iñaki Baz Castillo wrote: > 2008/10/2, Dmitry Akindinov <[EMAIL PROTECTED]>: > >>> RFC 3262 says clearly that "The provisional response ***MUST establish a >> dialog*** if one is not yet created". >> ... they just refer to the fact that Tables 1 and 2 in rfc3262 extend >> tables 2 and 3 in rfc3261 and the Contact is marked as optional in 1xx >> responses. If 3262 clearly stated that reliable provisional responses MUST >> have Contact - we would not have this issue. >> Yet, how simpler the life would be if rfc3262 (at least) stated clearly >> that with reliable provisional responses the Contact header is required :-) > > Are you sure of the meaning of that Table 1 in RFC 3262? > > Note that RFC 3261 in table 2 says: > > Header field where proxy ACK BYE CAN INV OPT REG > ___ > Contact Ro - - m o o > Contact1xx - - - o - - > Contact2xx - - - m o o > Contact3xx d- o - o o o > Contact485 - o - o o o > > For me this means that, in RFC 3261, Contact must be present in a 2xx > to an INVITE. Yes, but according to this table it's optional for 1xx. And 3262 does not update that, though with reliable 1xx the Contact is more likely to be needed to address the PRACK. > So if we now look at Table 2 in RFC 3262 I see: > >Header field where PRACK >___ >Contact R - >Contact1xx - >Contact2xx - >Contact3xx o >Contact485 o > > For me this means that a Contact header is "not applicable (-)" when > replying to a PRACK, nothing about the 1xx for the INVITE in acse the > 1xx requires "100rel". > -- Best regards, Dmitry Akindinov ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] sending DTMF as Notify
>>INFO is more appropriate to send DTMF using "application/dtmf-relay" >>content-type. That is a matter of opinion - some would say that DTMF should be solicited before it is sent. I guess though in this case, the NOTIFY is unsolicited anyway. It is unusual for unsolicited NOTIFY to be used for DTMF (though I have seen unsolicited NOTIFY for call-waiting) I do agree that INFO is more usual for unsolicited DTMF transport. >> Please note that this is not IANA registered application mime type though. True. "application/dtmf-relay" is what Cisco have used, so many others have also adopted it. If a big player uses something non-standard, it can end up becoming a kind of de-facto standard. Regards, Attila From: [EMAIL PROTECTED] on behalf of Vikram Chhibber Sent: Thu 02/10/2008 10:19 To: Vivek Gupta Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] sending DTMF as Notify INFO is more appropriate to send DTMF using "application/dtmf-relay" content-type. Please note that this is not IANA registered application mime type though. For example: INFO sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]> SIP/2.0 Via: SIP/2.0/UDP 172.80.2.100:5060 From: >;tag=43 To: >;tag=9753.0207 Call-ID: [EMAIL PROTECTED] CSeq: 25634 INFO Content-Length: 26 Content-Type: application/dtmf-relay Signal= 1 Duration= 160 On Thu, Oct 2, 2008 at 1:44 PM, Vivek Gupta <[EMAIL PROTECTED]>wrote: > Hi, > > I need information on how to send DTMF tones as unsolicited Notify method > within an established dialogue. Can anyone explain the > steps to implement the same? > > Information on any SIP soft-phone that supports DTMF as Notify would be of > great of help? > > With regards, > Vivek GUpta > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP Proxy inserting Option Tags
>>Is a SIP proxy allowed to insert Option tags when forwarding a >>request? Not usually but this RFC allows it. I guess the reason is that protecting against a poxy's resource leakage is sometimes considered more important than allowing a call to proceed without the requirement. >> In that case, why "Require" is preferred than "Supported" in RFC4028? The require is used because the proxy absolutely requires it. Regards, Attila From: [EMAIL PROTECTED] on behalf of Victor Pascual Ávila Sent: Wed 01/10/2008 18:43 To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] SIP Proxy inserting Option Tags RFC3261 20.32 Require The Require header field is used by UACs to tell UASs about options that the UAC expects the UAS to support in order to process the request. RFC4028 8.1. Processing of Requests the proxy MAY insert a Require header field with the value 'timer' into the request. Is a SIP proxy allowed to insert Option tags when forwarding a request? In that case, why "Require" is preferred than "Supported" in RFC4028? Cheers, -- Victor Pascual Ávila ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP Proxy inserting Option Tags
>>IMHO a proxy CANNOT add a Require option tag, can it? it can but it is bit of a hack. RFC4028 itself does not recommend it. However it allows it to try to force a session timer even if the request originator does not support it. with the value 'timer', the proxy MAY insert a Require header field with the value 'timer' into the request. However, this is NOT RECOMMENDED. This allows the proxy to insist on a session timer for the session. This header field is not needed if a Supported header field was in the request; in this case, the proxy would already be sure the session timer can be used for the session. If "unsupported: timer" is returned, the UA, as you say, won't understand it. But it's of no consequence, the UA can't do anything anyway. The Unsupported response is for a user to try to understand why the request failed - if it failed due to "unsupported: timer", then the user can conclude that an upstream proxy inserted the "timer" requirement (but RFC4028 knowledge is required - not ideal I suppose). Regards, Attila From: [EMAIL PROTECTED] on behalf of Iñaki Baz Castillo Sent: Wed 01/10/2008 19:30 To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] SIP Proxy inserting Option Tags El Miércoles, 1 de Octubre de 2008, Victor Pascual Ávila escribió: > RFC3261 > 20.32 Require > The Require header field is used by UACs to tell UASs about options > that the UAC expects the UAS to support in order to process the > request. > > RFC4028 > 8.1. Processing of Requests > the proxy MAY insert a Require header field with the value 'timer' > into the request. > > Is a SIP proxy allowed to insert Option tags when forwarding a > request? In that case, why "Require" is preferred than "Supported" in > RFC4028? I don't understand how a proxy can add a "Require" option tag. Let me explain the issue with an example: - A sends INVITE to B through proxy P. - P adds "Require: ". - B replies "420 Bad Extension". - "420" arrives to P who forwards it to A. - So A receives the "420" with a header "Unsupported: ". - A didn't add that option tag so it doesn't understand what happened. IMHO a proxy CANNOT add a Require option tag, can it? -- Iñaki Baz Castillo ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] XML inside SIP
Hi All, Does anyone know the usage of XML inside SIP messages (like NOTITY) ? Thanks BR, Manoj ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] sending DTMF as Notify
INFO is more appropriate to send DTMF using "application/dtmf-relay" content-type. Please note that this is not IANA registered application mime type though. For example: INFO sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]> SIP/2.0 Via: SIP/2.0/UDP 172.80.2.100:5060 From: >;tag=43 To: >;tag=9753.0207 Call-ID: [EMAIL PROTECTED] CSeq: 25634 INFO Content-Length: 26 Content-Type: application/dtmf-relay Signal= 1 Duration= 160 On Thu, Oct 2, 2008 at 1:44 PM, Vivek Gupta <[EMAIL PROTECTED]>wrote: > Hi, > > I need information on how to send DTMF tones as unsolicited Notify method > within an established dialogue. Can anyone explain the > steps to implement the same? > > Information on any SIP soft-phone that supports DTMF as Notify would be of > great of help? > > With regards, > Vivek GUpta > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] sending DTMF as Notify
Hi, I need information on how to send DTMF tones as unsolicited Notify method within an established dialogue. Can anyone explain the steps to implement the same? Information on any SIP soft-phone that supports DTMF as Notify would be of great of help? With regards, Vivek GUpta ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Early dialogs, reliable responses and PRACK addressing
2008/10/2, Dmitry Akindinov <[EMAIL PROTECTED]>: > > RFC 3262 says clearly that "The provisional response ***MUST establish a > dialog*** if one is not yet created". > > > > ... they just refer to the fact that Tables 1 and 2 in rfc3262 extend > tables 2 and 3 in rfc3261 and the Contact is marked as optional in 1xx > responses. If 3262 clearly stated that reliable provisional responses MUST > have Contact - we would not have this issue. > Yet, how simpler the life would be if rfc3262 (at least) stated clearly > that with reliable provisional responses the Contact header is required :-) Are you sure of the meaning of that Table 1 in RFC 3262? Note that RFC 3261 in table 2 says: Header field where proxy ACK BYE CAN INV OPT REG ___ Contact Ro - - m o o Contact1xx - - - o - - Contact2xx - - - m o o Contact3xx d- o - o o o Contact485 - o - o o o For me this means that, in RFC 3261, Contact must be present in a 2xx to an INVITE. So if we now look at Table 2 in RFC 3262 I see: Header field where PRACK ___ Contact R - Contact1xx - Contact2xx - Contact3xx o Contact485 o For me this means that a Contact header is "not applicable (-)" when replying to a PRACK, nothing about the 1xx for the INVITE in acse the 1xx requires "100rel". -- Iñaki Baz Castillo <[EMAIL PROTECTED]> ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Early dialogs, reliable responses and PRACK addressing
2008/10/2, Harsha. R <[EMAIL PROTECTED]>: > Its not clear to me as to why the 18X is expecting a Contact. The purpose of > Contact is to do a target refresh. > 18X missing a Contact header means a target refresh has not happened. In > this case, address the PRACK to > the original remote target( mostly the one used for INVITE). > > If all goes well, PRACK reaches the intended UAS and call goes through; I don't agree here. The purpose of an-indialog request is to arrive just to the UAS in that dialog, not to others UAS with same AoR. If you send a PRACK (in-dialog request) with the same RURI as the initial INVITE then the proxy between UAC and UAS must do again a lookup to change the RURI and possibly do parallel forking. This will cause an in-dialog request arriving to other UAS registered with same AoR, each of them will reply "482 Call/Leg doesn't exist". IMHO that is not the purpose SIP was designed, maybe it's just a black hole, "legal", but incorrect. If we keep as "valid" any exotic possibility not strictly defined in the RFC's then SIP would become a pain. -- Iñaki Baz Castillo <[EMAIL PROTECTED]> ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
