[SIPForum-techwg] IP PBX / SP Interop Draft Version 5 propose d edits

[Rohan Mahy]

Hi John,

I am sympathetic to your argument, but I am concerned that we are 
advertising an interoperability specification that will not 
interoperate if other elements do a few things that we can provide 
guidance against in very specific circumstances. If we say nothing, it 
is quite likely that once a SIP Connect entity starts using Identity or 
ICE, things will suddenly break in a way that prevents that entity from 
communicating at all and make it almost impossible to troubleshoot.  
With text like what I proposed, we can provide some very delicate 
future proofing.

thanks,
-rohan


On Mar 4, 2006, at 13:09, Elwell, John wrote:
> Rohan,
>
> While I understand your technical motivation, we must be clear on the 
> scope
> of this interop spec. It is a specification of interworking between an 
> IP
> PBX and an SP, or in other words, between a proxy on the IP PBX side 
> and a
> proxy on the SP side (refer to the architecture diagram in the draft). 
> So
> what it defines is what goes across that interface. If the proxy on the
> IPPBX side modifies these fields such that what is sent on the IP PBX 
> side
> of the proxy differs from what is sent across the interface to the SP 
> proxy,
> then that appears to be outside the scope of this specification. 
> Likewise on
> the SP side. So my vote is to exclude your proposed text.
>
> John
>
>> -----Original Message-----
>> From: Rohan Mahy [mailto:rohan at ekabal.com]
>> Sent: 03 March 2006 22:34
>> To: Hadriel Kaplan
>> Cc: 'SIP Forum Tech WG'
>> Subject: RE: [SIPForum-techwg] IP PBX / SP Interop Draft
>> Version 5 proposed edits
>>
>> Hadriel,
>>
>>> Can you also add a vote for whether or not to add Rohan's
>> addition to
>>> section 8?  I did not hear anyone else agree to it, and I strongly
>>> disagree
>>> to it.
>>>
>>> There is no service provided/documented by this interop
>> spec that requires
>>> this addition to be met, and there's a large sector of
>> service providers
>>> and
>>> enterprises that can not and do not wish to meet it.
>> Normally I would not
>>> care if the doc said so because that sector of operators
>> would simply
>>> ignore
>>> it, but for this particular requirement it would potentially break
>>> interoperability and suggest support for mechanisms which
>> are not defined
>>> in
>>> this document.
>>
>> Please motivate this statement.  Under what circumstances can
>> a service
>> provider or enterprise intermediary safely modify the SIP
>> body when any of
>> the conditions I mentioned are satisfied?  (For example, if
>> an Identity
>> header is present, modifying the body or the contact will cause a UAS
>> supporting Identity to reject the request.)
>>
>> The charter of this group _*REQUIRES*_ us to "do no harm" and protect
>> interoperability of current and *planned* IETF work.  The IETF already
>> recommends stronger language damning the practice of body
>> modification.
>> My proposal is much more specific and implicitly allows body
>> modification
>> in every case I can imagine where it is even remotely useful.  Please
>> consider this when accusing me of causing an interoperability problem.
>>
>>> It also references 2 IETF documents which are in draft form
>> only - which I
>>> thought we were trying to avoid in this doc?
>>
>> My proposed change does NOT require referencing any
>> additional documents.
>> I will however point out that Identity is approved and in the
>> RFC editor
>> with no blocking dependencies.  It is likely to be published
>> before the
>> SP-PBX interop spec.  As for ICE, it is a WG item and has undergone
>> significant review.  The concept has been stable for nearly
>> two years and
>> has significant WG and IESG support, and the only thing we
>> require from
>> ICE for this document is the string "a=candidate:".
>>
>> thanks,
>> -rohan
>>
>>
>>> Thanks,
>>> Hadriel
>>>
>>> -------------------Rohan's change-----------------
>>> Section 8
>>> propose we add a 4th item.  this was discussed very early, but was
>>> dropped.
>>> this is consistent with our "do no harm" motto:
>>> 4) SIP intermediaries MUST NOT modify IP addresses or port
>> numbers in the
>>> body or Contact header of any message if any of the following are
>>> true:
>>> - The SIP message contains an "Identity" header (indicating
>> use of the
>>> Identity extension)
>>> - the Content-Type of the body or any of its subparts is
>>> "application/pkcs7-mime" or "multipart/signed" (indicating
>> support for SIP
>>> S/MIME)
>>> - any "application/sdp" body in the message contains any
>> "a=candidate:"
>>> lines (indicating use of the ICE extension)
>>> - all the "c=" lines in any "application/sdp" bodies
>> contain only public
>>> IP
>>> addresses (indicating that another element has already ensured the
>>> addresses
>>> are correct).
>>> ---------------------end change-------------
>>>
>>> _____________________________________________
>>> From: techwg-bounces at sipforum.org
>> [mailto:techwg-bounces at sipforum.org] On
>>> Behalf Of Chris Sibley
>>> Sent: Friday, March 03, 2006 12:52 PM
>>> To: 'SIP Forum Tech WG'
>>> Subject: [SIPForum-techwg] IP PBX / SP Interop Draft
>> Version 5 proposed
>>> edits
>>>
>>> IP PBX / SP Interop WG team members,
>>>
>>> Following are the "top" issues derived from the "master
>> list" of 2/27 -
>>> 3/2
>>> comments. Please give them a quick read and respond to each
>> with a "yea or
>>> nay" vote on the recommended disposition.
>>>
>>> After this round of edits/discussion has been completed, I
>> will publish a
>>> final list of issues still requiring discussion (also
>> compiled from the
>>> "master list").
>>>
>>> Thanks!
>>>
>>> --Chris
>>>
>>> -----------------------
>>>
>>> RFC 3265 (Session Initiation Protocol (SIP)-Specific Event
>> Notification)
>>> Support
>>>
>>> Ernst Horvath wrote:
>>> "I would like to see the following RFCs removed from the
>> table in section
>>> 5:
>>> 3265, 3515, 3842, 3891, and 3892. The reason is that there
>> are no use
>>> cases
>>> specified for these extensions in the rest of the document,
>> and it is
>>> unreasonable to mandate global conformance to a generic
>> mechanism like
>>> REFER
>>> or the event framework. (Which role is mandatory -
>> subscriber, notifier or
>>> both - for which entity? Which methods can be referred, in which
>>> direction?
>>> Etc.)"
>>>
>>> Cullen Jennings wrote:
>>> "Why would you need 3265 - is this just for MWI"
>>>
>>> Rohan Mahy wrote:
>>> "Why is the SAS required to implement MWI? this is not
>> motivated in the
>>> text. recommend deleting the entire line."
>>>
>>> Recommended Disposition: Remove the requirement for RFC
>> 3265 from the
>>> specification.
>>>
>>>
>> --------------------------------------------------------------
>> --------------
>>>
>> --------------------------------------------------------------
>> --------------
>>> ------------------
>>>
>>> RFC 3892 (The Session Initiation Protocol (SIP) Referred-By
>> Mechanism)
>>> Support
>>>
>>> Ernst Horvath wrote:
>>> "I would like to see the following RFCs removed from the
>> table in section
>>> 5:
>>> 3265, 3515, 3842, 3891, and 3892. The reason is that there
>> are no use
>>> cases
>>> specified for these extensions in the rest of the document,
>> and it is
>>> unreasonable to mandate global conformance to a generic
>> mechanism like
>>> REFER
>>> or the event framework. (Which role is mandatory -
>> subscriber, notifier or
>>> both - for which entity? Which methods can be referred, in which
>>> direction?
>>> Etc.)"
>>>
>>> Cullen Jennings wrote:
>>> "I might be wrong but I think that 3892 requires S/MIME - I
>> doubt you want
>>> to do that "
>>>
>>> Rohan Mahy wrote:
>>> "This is also not motivated by the text. Referred-by
>> strongly recommends
>>> the
>>> use of auth-id bodies signed with S/MIME. I am not aware of *any*
>>> implementations of this portion of the Referred-By spec. If
>> we recommend
>>> Referred-By, we at least need to specify that this part is
>> not required
>>> (and
>>> why)."
>>>
>>> Recommended Disposition: Remove the requirement for RFC
>> 3892 from the
>>> specification
>>>
>>>
>> --------------------------------------------------------------
>> --------------
>>>
>> --------------------------------------------------------------
>> --------------
>>> ------------------
>>>
>>> Call Progress Tones
>>>
>>> Ernst Horvath wrote:
>>> "I have a real problem with section 15.1. The generation of
>> local tones is
>>> an implementation matter and most likely subject to diverse
>>> national regulations. Therefore this section should really
>> be outside the
>>> scope of this specification."
>>>
>>> Cullen Jennings wrote:
>>> "The call progress tones are US only. This seems really bad
>> for a sip
>>> forum
>>> document. I would be happy to contribute a list of other
>> tones if you
>>> would
>>> like :-)"
>>>
>>> Rohan Mahy wrote:
>>> "The response code to tone mapping here is US centric and
>> does not even
>>> accommodate variations among US phone systems (for example,
>> some US phone
>>> systems use Fast Busy instead of SIT tone for "all circuits
>> busy". Ideally
>>> the tones generated by the PBX will be configurable. I'm inclined to
>>> declare
>>> the specific tones out of scope."
>>>
>>> Recommended Disposition: Remove the specific call progress tone
>>> information
>>> and replace with a general statement that PBX systems
>> SHOULD generate some
>>> form of call progress tone.
>>>
>>>
>> --------------------------------------------------------------
>> --------------
>>>
>> --------------------------------------------------------------
>> --------------
>>> ------------------
>>>
>>> CDR Issues
>>>
>>> Hadriel Kaplan wrote:
>>> "The third paragraph [of section 9.1] confuses me greatly.
>> I am not clear
>>> what CDRs have to do with interoperability. If the service provider
>>> chooses
>>> not to charge an Enterprise for anything, then they don't
>> comply with this
>>> spec? (they won't stay in business for long, but that's
>> another problem)
>>> It
>>> also implies a problem: how will the SAS know that a call
>> truly came from
>>> an
>>> Enterprise's PBX, when it went through the service
>> provider's SPS. It then
>>> lays out a solution for that by saying information identifying the
>>> Enterprise must be extracted from the cert and signaled to the SAS
>>> (somehow). That seems out of scope for an interop spec - if
>> the service
>>> provider wishes to identify the enterprise PBX call through
>> internally
>>> secured charging vectors, or call-ids combined with
>> p-asserted-ids, or
>>> whatever, it's up to them. It won't impact interoperability
>> unless you
>>> want
>>> the enterprise PBX to send some special header for this."
>>>
>>> Hadriel Kaplan wrote:
>>> "Bullet-4 of section 9:
>>> I'm pretty sure an interop spec should not be specifying
>> what fields a
>>> service-provider should populate their CDRs with?"
>>>
>>> Ernst Horvath wrote:
>>> "Section 9.1, bullet 4. This seems to relate to the
>> interface between Sip
>>> proxy server (on the SP side) and the SIP application server. I
>>> believe this interface is outside the scope of this document."
>>>
>>> Recommended Disposition: Remove all references to
>> population of CDR data
>>> from the specification.
>>>
>>>
>> --------------------------------------------------------------
>> --------------
>>>
>> --------------------------------------------------------------
>> --------------
>>> ------------------
>>>
>>> Requirement for STUN Support on the Firewall
>>>
>>> Hadriel Kaplan wrote:
>>> "The diagram and text discuss a STUN server as an optional,
>> non-mandatory
>>> element, yet the first paragraph of this section says the
>> diagram outlines
>>> the minimal set of elements required to support the spec.
>>>
>>> The diagram also has a dotted line to enterprise IP Phones,
>> presumably for
>>> their use to learn and open pinholes for publicly routable media
>>> address/ports.  However the rest of the document does not
>> distinguish
>>> between IP Phones and a PBX, but rather treats them as one
>> logical system
>>> -
>>> in fact that's specifically called out in the definitions
>> section for IP
>>> PBX
>>> and IP Phones.  Further, section 8 suggests service
>> provider firewalls be
>>> STUN friendly, yet at no time does it say that service providers are
>>> recommended to use STUN, nor is that communication path in
>> the diagram.
>>>
>>> In essence, it is simply one example method, as enum was in
>> section 10 for
>>> number location.  It should be up to the Enterprise how
>> they want to learn
>>> public addresses to use.  All you care about for interop
>> purposes is that
>>> the addresses presented to the service provider and vice-versa are
>>> publicly
>>> reachable ones.
>>>
>>> Given that, and given that the SIP message details inherent
>> in actually
>>> having IP Phones off an enterprise proxy/pbx are not really
>> addressed in
>>> this document, I recommend you remove the STUN server from
>> the diagram and
>>> section 5 standards list."
>>>
>>> Hadriel Kaplan wrote:
>>> "I still find it odd for an SP-to-Ent interop spec to tell
>> an enterprise
>>> that they SHOULD do something on their firewalls, when that
>> something is
>>> only
>>> needed if they choose to fix something a certain way, and
>> the way in which
>>> the fix it is up to them entirely and has no bearing on
>> interoperability
>>> and
>>> is not defined in the spec itself.
>>>
>>> It's like saying "your firewalls SHOULD support being a
>> DHCP server",
>>> because after all the SIP PBX and phones need IP Addresses
>> and DHCP is a
>>> way
>>> to get them, and some firewalls can be one.
>>>
>>> Especially when you define the STUN server to be in the
>> DMZ, whereas it
>>> could be implemented inside the firewall itself, or on the
>> public side of
>>> a
>>> firewall.  A DMZ is not on the public side of a firewall -
>> and it may not
>>> even be public addresses.  I'm not clear how STUN would
>> even work in a
>>> traditional DMZ.  Sending packets from inside to a DMZ box, if even
>>> allowed,
>>> would not open any holes in the firewall to the public
>> internet and would
>>> not provide you with the same public address/port for such."
>>>
>>>
>>> Janne Magnusson wrote:
>>> "A STUN friendly firewall must be a full cone NAT firewall
>> and that are
>>> not
>>> common in enterprise environments as the security is much better
>>> with a symmetric NAT firewall.
>>>
>>> The STUN friendly firewall requirement is only valid if
>> STUN is used, in
>>> other cases should the enterprise be free to choose firewall as they
>>> like. In most cases will an enterprise want to keep the
>> existing firewall
>>> and requirements like the suggested will hamper enterprises
>>> willingness to implement SIP PBX technology.
>>>
>>> I suggest that the last paragraph is removed. It is a pretty obvious
>>> requirement if you choose to implement a STUN solution that
>> all network
>>> elements must be STUN friendly."
>>>
>>> Recommended Disposition: Remove the requirement for the
>> firewall to be
>>> STUN-friendly.
>>>
>>>
>> --------------------------------------------------------------
>> --------------
>>>
>> --------------------------------------------------------------
>> --------------
>>> ------------------
>>>
>>> Requirement for Outbound Proxy Configuration on the SIP
>> Application Server
>>>
>>> Ernst Horvath wrote:
>>> "In the 2nd paragraph of 6.1 and 3rd paragraph of 6.2, it
>> is mandated that
>>> an FQDN is configurable for an outbound proxy. Why is it not left
>>> as an internal matter how the proxy is addressed inside its
>> own domain,
>>> e.g.
>>> by configuring its IP address?"
>>>
>>> Hadriel Kaplan wrote:
>>> "Like Ernst, I do not understand why an interop spec is
>> mandating internal
>>> routing mechanisms in the service provider's network.
>> Calls that are
>>> routed
>>> for termination from the SP's SAS to its SPS may be done
>> through numerous
>>> means, one of which may be FQDN-based.  It will not impact
>> interop between
>>> the SP and Enterprise how this is done."
>>>
>>> Recommended Disposition: Remove the requirement from the
>> specification.
>>>
>>>
>> --------------------------------------------------------------
>> --------------
>>>
>> --------------------------------------------------------------
>> --------------
>>> ------------------
>>>
>>>
>>>
>>>
>>> ________________________________________
>>> From: techwg-bounces at sipforum.org
>> [mailto:techwg-bounces at sipforum.org] On
>>> Behalf Of Chris Sibley
>>> Sent: Friday, March 03, 2006 11:47 AM
>>> To: SIP Forum Tech WG
>>> Subject: [SIPForum-techwg] IP PBX / SP Interop Draft
>> Version 5 "preview"
>>> andnext steps...
>>>
>>> IP PBX / SP Interop WG team members,
>>> I have completed making all discussed changes from the 1/27
>> - 2/26 comment
>>> period. I have also completed making many of the smaller
>> changes requested
>>> from the 2/27 - 3/2 comment period (the full list of
>> changes made can be
>>> found at the end of this message).
>>> A "preview" of the current working text is available for
>> your review at
>>> the
>>> following URL:
>>>
>> http://data.memberclicks.com/bbattach/128012/preview--sf-draft
> -twg-IP_PBX_SP
>>> _Interop-sibley-v5--preview.pdf
>>> As I indicated yesterday, I have compiled a "master list"
>> of contributor
>>> comments from the 2/27 - 3/2 time period. From this list, I
>> have extracted
>>> the set of issues that more than one person commented on.
>>> As a next step I would like to see if we can get to a quick
>> consensus on
>>> these "top" issues so that I can go ahead and make the
>> necessary changes
>>> to
>>> the working draft.
>>> I will be sending out a separate email in a bit that
>> contains this list of
>>> issues, the applicable comments made by each of the
>> contributors, and my
>>> recommendation for how to proceed on each. If you would,
>> please take the
>>> time to give the recommendation for each issue a quick "yea
>> or nay" vote
>>> so
>>> that I can quickly gauge the group's overall consensus on
>> these particular
>>> issues.
>>> Finally, after this voting round is done, I'll send out a
>> consolidated
>>> list
>>> of the remaining items from the "master list" that still require
>>> discussion
>>> and we can try to hammer those issues out.
>>> Thanks!
>>> --Chris
>>> ----------------
>>> Draft Version 5 (preview release) changes
>>>
>>> Section 1, Introduction
>>> * Added statement to clarify that the primary service
>> intended for use by
>>> the spec is audio-based PSTN call origination/termination
>>> * Added references to ITU-T Recommendations in addition to IETF RFCs
>>> * Added following statement to 3rd paragraph: "Note that
>> this document
>>> does
>>> not preclude or discourage the negotiation of additional
>> functionality."
>>> * 3rd paragraph: s/This SIP Forum recommendation is proposed to help
>>> address
>>> the issue./This SIP Forum document aims to address this issue./
>>> * 3rd paragraph: s/for predictable interoperability between/for a
>>> predictable interoperable scenario between/
>>>
>>> Section 3, Definitions
>>> * Updated reference architecture drawing to show use of
>> STUN between PBX
>>> and
>>> STUN server (in addition to IP phones)
>>> * Broke out the reference architecture drawing and the
>> definitions into
>>> separate sections
>>> * Added definition for Application Layer Gateway
>>> * s/the minimal/common/
>>>
>>> Section 4, Key Assumptions and Limitations of Scope
>>> * Added statement to clarify that the primary service
>> intended for use by
>>> the spec is audio-based PSTN call origination/termination
>>> * Modified item #6: s/911 issues/calling issues, for
>> example routing to
>>> national emergency numbers such as 911, 112, 999, or 000, /
>>>
>>> Section 5, Standards Support
>>> * Added RFC 2782 as MANADATORY requirement for the SPS
>>> * Changed column title 'RFC #' to 'Standard ID'
>>> * Legend: s/(Receive only)/(at minimum to Receive)/
>>>
>>> Section 6.1, (Locating SIP Servers) Enterprise Requirements
>>> * Spelled out FQDN.
>>> * 4th paragraph: changed AOR references to URI
>>> * Changed wording in last paragraph from "register one or
>> more AORs" to
>>> "register a contact URI against one or more AORs".
>>> * s/operate/ensure the existence of/
>>>
>>> Section 6.2, (Locating SIP Servers) Service Provider Requirements
>>> * s/to update the SAS's default IP address for the PBX/to
>> update a DNS
>>> entry
>>> associated with the PBX in a DNS zone managed by the
>> Service Provider./
>>>
>>> Section 7, Signaling Security
>>> * Updated text to require the use of canonical hostnames by
>> the SPS in the
>>> 'Via:' and/or 'Route:' SIP header fields.
>>> * 5th paragraph: s/matches the server's host name or SIP
>> URI/matches the
>>> host portion of the target URI/
>>>
>>> Section 8, Firewall and NAT Traversal
>>> * Removed requirement that symmetric NATs must not be in the
>>> communications,
>>> and that SIP ALGs should be disabled.
>>> * Modified text to reflect the fact that the specification does not
>>> exclude
>>> the use of any particular NAT traversal method (e.g. static
>> config, SBC,
>>> SIP-aware firewall.)
>>> * Added clarification that IP addresses contained with SIP
>> message bodies
>>> as
>>> well as headers must be publicly routable addresses.
>>> * Added requirements for SIP Intermediaries
>>>
>>> Section 9.1, Authentication of the Enterprise by the
>> Service Provider
>>> * Minor text change ("The username supplied..." -> "The
>> authentication
>>> username supplied...")
>>> * Added requirement to challenge the REGISTER request (in
>> addition to
>>> INVITES)
>>>
>>> Section 10, Enterprise PSTN Identities
>>> * Changed references of Address of Record / AOR to URI.
>>>
>>> Section 11, Enterprise URI Formatting and Addressing Rules
>>> * Added statement that both open and closed numbering plans must be
>>> supported.
>>> * Added guidance for formatting the Request-URI field
>>>
>>> Section 11.1, (Enterprise URI Formatting and Addressing
>> Rules) 'From:'
>>> Field
>>> * Clarified the text to indicate that Option 1 is the
>> preferred method.
>>>
>>> Section 11.2, (Enterprise URI Formatting and Addressing
>> Rules) 'To:' Field
>>> -
>>> PSTN Destinations
>>> * Corrected URI examples in 11.2.1 and 11.2.2 (added
>> international prefix
>>> symbol and ;user=phone tag where applicable)
>>>
>>> Section 11.3, (Enterprise URI Formatting and Addressing
>> Rules) 'To:' Field
>>> -
>>> Emergency Services Destinations
>>> *  s/ALI/emergency location information/
>>>
>>> Section 12, Service Provider URI Formatting and Addressing Rules
>>> * Added guidance for formatting the Request-URI field
>>>
>>> Section 12.1, (Service Provider URI Formatting and Addressing Rules)
>>> 'From:'
>>> Field
>>> * Added second option for anonymous URI format (to make
>> compatible with
>>> Identity: header)
>>>
>>> Section 12.1.1, (Service Provider URI Formatting and
>> Addressing Rules)
>>> ('From:' Field)  Option 1: Utilizing the 'From:' and
>>> 'P-Asserted-Identity:'
>>> SIP Header Fields
>>> * 3rd paragraph: s/"Trust Domain"/"Trust Domain", as
>> defined in RFC 3325/
>>>
>>> Section 13, Quality of Service Considerations
>>> * Removed unnecessary statement indicating that the SP and
>> Enterprise must
>>> agree on settings if the recommended values are not used.
>>>
>>> Section 14.2, CODEC Support and Media Transport
>>> * 2nd paragraph: s/terminates RTP traffic MUST/terminates
>> RTP traffic over
>>> UDP MUST/
>>>
>>> Section 14.3, Transport of DTMF Tones
>>> * Clarified that TGs must support RFC 2833 with any codec
>>>
>>> Section 14.4, Echo Cancellation
>>> * Clarified that some of the requirements only apply to devices that
>>> supports fax and/or modem transmissions.
>>>
>>> Section 14.5, Fax and Modem Calls
>>> * Clarified that some of the requirements only apply to devices that
>>> supports fax and/or modem transmissions.
>>> * 2nd paragraph: s/SIP RE-INVITE method/SIP reINVITE request/
>>> * 2nd paragraph, appended to end: " or SIP UPDATE request
>> as described in
>>> RFC 3311 [13]."
>>>
>>> Section 16, References
>>> * Added ITU-T Recommendation T.38 to the list of references
>> and tagged the
>>> text as applicable
>>>
>>> Section 17, Contributors and Contact Information
>>> * Updated contributor contact information
>>> * Changed 'Email:' to 'mailto:' in contributor contact
>> information section
>>>
>>> Miscellaneous
>>> * Minor wording / grammar fixes
>>> * Replaced all occurrences of "calling name information"
>> with "display
>>> name
>>> information"
>>> * Replaced all occurrences of AOR and address of record with "URI"
>>> * Changed all references of "CODEC" to "codec"
>>>  << File: ATT00592.txt >>
>>>
>>>
>>> _______________________________________________
>>> techwg mailing list
>>> Send mail to: techwg at sipforum.org
>>> Unsubscribe or edit options at:
>>> http://sipforum.org/mailman/listinfo/techwg
>>>
>>
>> _______________________________________________
>> techwg mailing list
>> Send mail to: techwg at sipforum.org
>> Unsubscribe or edit options at:
>> http://sipforum.org/mailman/listinfo/techwg
>>